Вопрос к программистам на C , Исходники ядра Linux

Ну, понеслись по кочкам.

Цитата the_Shadow @ 20.07.06, 13:10

http://www.eventhelix.com/RealtimeMantra/b...Performance.htm

Comparing C++ and C (Classes and Methods)
...
Перейду сразу к выводам этой статьи:

Цитата

C++ Method Invocation
All C++ methods when translated to C end up with an additional parameter. This might appear to be a big performance overhead. In reality however, the code in C will also have to access the common data structure via an array index or some other mechanism.

Вроде бы логично, если бы не одно "но". Если функция на С предназначена для работы с конкретным элементом, должен быть механизм передачи информации об этом элементе в метод. Но тогда чем это отличается от передачи тхис?

Цитата

Object Construction
Whenever an object is constructed, C++ will invoke the constructor. Sometimes this might be an addition overhead. This overhead can be reduced by defining the constructor inline. In most cases however, the constructor is actually replacing a routine that would have been used to initialize the data structures in a conventional C program.

If a program declares a lot of global objects, object construction can be a big overhead at program startup. C++ invokes constructors for all global objects before main() is called

Все, вроде бы, замечательно. И автор вроде бы даже написал все правильно. Но он, видимо, невнимательно читал стандарт (раздел 12.1, пункт 5). А в стандарте говорится, что конструктор вызывается только для тех объектов, для которых он либо определен, либо (в силу тех или иных обстоятельств) требуется нетривиальная инициализация объекта. А к структурам в стиле С это не имеет никакого отношения. По этому фразы "will invoke the constructor" должна читаться как миниму "could invoke the constructor".

Цитата

Object Destruction
As you can see from the C code, whenever an object goes out of scope or is explicitly deleted, C++ invokes the destructor for the object. This overhead can be reduced by only defining destructors when they are really needed (i.e. some action is required when object is deleted). Inline destructors can also be used to reduce the overhead.

О каком оверхеде идет речь то? Или в С не принято освобождать ресурсы после использования? И очевидно, что деструктор определяется (и вызывается) только в том случае, если в этом есть необходимость. Т. е. если деструктор тривиальный - то его вызов не производится (как и в случае с конструктором).

Едем дальше.

Цитата the_Shadow @ 20.07.06, 13:10

http://www.eventhelix.com/RealtimeMantra/b...erformance2.htm

Comparing C++ and C (Inheritance and Virtual Functions)
Видимо, автор не совсем в курсе, что в С++ конструкторы и деструкторы не занимаются распределением памяти... - это по коду. Второй момент - совершенно дикая реализация таблицы виртуальных методов. Они бы хоть в код, генерируемый midl'ом заглянули, что ли...
Теперь так же по пунктам выводов.

Цитата

Object Construction
Inheritance does increase the object construction overhead, as constructors for all the parent classes in the class hierarchy are invoked. There is the additional overhead of setting up vtable in the constructor.

Очевидно. Конечно. Если конструкторы не тривиальные. Но ведь и в С требуется инициализация сложных структур. Это мы оверхедом не считаем? Второй момент (по поводу инициализации таблицы указателей на виртуальные методы). Те реализации виртуальных методов, которые я видел на С (ближайший пример - в этом топике), предполагают гораздо больший оверхед. Ибо если в С++ при создании объекта инициализируется один указатель, то в С - всякий раз вся таблица.

Цитата

Object Destruction
Inheritance does increase the object destruction overhead, as destructors for all the parent classes in the class hierarchy are invoked. There is the additional overhead of setting up vtable in the destructor. Virtual destructors also increase the overhead of object destruction.

Опять же - деинициализация ресурсов в С мы рассматривать не будем... Это не оверхед... Это раз. Второе - посмотрел бы я на быструю реалиазцию в С механизма, аналогичного (по функционалу) с виртуальными деструкторами.

Цитата

Memory Overhead
Using plain inheritance has no memory overhead. Inheritance with virtual functions however does introduce the following memory overhead:

* A vtable array pointer is added to all classes that use virtual functions.
* Global vtable arrays are declared for every call with virtual functions (this should be a very small overhead).

Не будем упоминать о том, что выше предложенная альтернатива на switch/case'е влечет либо оверхед по генерируемому коду на каждую функцию, либо оверхед на таблицу переходов (если кейс большой).

Flex, ну помилуй... Экий ты, право, привередливый... Все у тебя ни фига не знают... :D:D:D

Добавлено 20.07.06, 20:40
Давай продолжим по-позжее? А то лень... Чесслово... Добродушен больно...

Цитата the_Shadow @ 20.07.06, 20:39

Flex, ну помилуй... Экий ты, право, привередливый... Все у тебя ни фига не знают... :D:D

Позволь мне покритиковать предложенную тобой аргументацию. Меня ведь тоже могут раздражать написанные с умным видом статьи, изобилующе неточностями.

Цитата Flex Ferrum @ 20.07.06, 20:42

Позволь мне покритиковать предложенную тобой аргументацию. Меня тоже могут раздражать написанные с умным видом статьи, изобилующе неточностями.

Ну, ладно... Уговорил. Ты -- давай, критикуй, а потом ужо я... Яду поднаберу, а то на Астю всё хорошенько излил...
Кстати, будь ласка -- подкорректируй ссылочки, для наглядности. А то в первой у тебя бардачокссс...

Сообщение отредактировано: the_Shadow - 20.07.06, 20:44

Цитата Flex Ferrum @ 20.07.06, 20:36

Ибо если в С++ при создании объекта инициализируется один указатель, то в С - всякий раз вся таблица.

Т.е vtbl шарится между объектами одного класса?

Цитата the_Shadow @ 20.07.06, 20:29

С обошёл это ограничение. Да. В основе С лежит в итоге именно ассемблер.

Обосонвание покажи, плз. Что под этим подразумевается? Только то, что в реализации gcc только С транслируется непосредственно в ассемблер? Так это, положим, особенности конкретной реализации. Т. е. это не является аргументом к обозначенному тезису, т. к. если мы говорим о языке С, то трансляция напрямую в ассемблер должна быть зафиксирована в стандарте.

Цитата the_Shadow @ 20.07.06, 20:29

Здесь все вспомнили про стандарты POSIX, которые позволяют говорить о "совместимости на уровне исходных кодов" при условии чёткого соблюдения требований POSIX, которые накладывают ряд ограничений. И что мне нужно было бы для переноса того же приложения на асме? Как минимум -- подкорректировать исходный код, причём, в ряде случаев -- переписать его от нуля. Здорово!

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи. В стандарте С POSIX упоминается единожды - в списке библиографии. И то, видимо, из за того, что CRTL пересекается с множеством методов, определяемых POSIX. Я могу с таким же успехом взять ассемблер, или любой другой компилируемый язык и использовать в нем методы, описанные в POSIX.

Добавлено 20.07.06, 20:50

Цитата e-yes @ 20.07.06, 20:47

Т.е vtbl шарится между объектами одного класса?

Конечно. А смысл делать иначе?

Цитата Flex Ferrum @ 20.07.06, 20:49

Конечно. А смысл делать иначе?

Ну дык тогда получается оверхед не на инициализации, а на использовании: obj->vtbl->method ?

Это при вызове не из методов этого же класса...

Сообщение отредактировано: e-yes - 20.07.06, 20:53

Цитата e-yes @ 20.07.06, 20:52

Ну дык тогда получается оверхед не на инициализации, а на использовании: obj->vtbl->method ?

Оверхеда - один mov. С другой стороны, если хранить таблицу непосредственно в объекте, то получается гораздо более жиный оверхед по памяти. Ты представь себе, как объекты в таком случае распухают!

Добавлено 20.07.06, 20:55

Цитата e-yes @ 20.07.06, 20:52

Это при вызове не из методов этого же класса...

Поправка - при неквалифицированном вызове методов (т. е. когда имя метода не квалифицировано явно).

Добавлено 20.07.06, 21:06
А вот эта ссылка:

Цитата the_Shadow @ 20.07.06, 13:10

И отсель -> http://unthought.net/c++/c_vs_c++.html

мне понравилась...

Цитата Flex Ferrum @ 20.07.06, 20:54

Оверхеда - один mov.

У меня почему-то два насчиталось.

ЗЫ. А лучше всего три, а то и пять звездочек. С утра сяду пересчитывать.

Цитата Flex Ferrum @ 20.07.06, 20:49

Обосонвание покажи, плз. Что под этим подразумевается? Только то, что в реализации gcc только С транслируется непосредственно в ассемблер? Так это, положим, особенности конкретной реализации. Т. е. это не является аргументом к обозначенному тезису, т. к. если мы говорим о языке С, то трансляция напрямую в ассемблер должна быть зафиксирована в стандарте.

А не будешь ли ты столь любезен проверить положение вещей в столь любимом тобой M$ DevStudio? Вот удивишься-то...
Не обязательно в стандарте, вообще говоря... На момент создания С стандарт на него не было. А вот асм -- был. И не один, как говорил уже. Так что, без стандарта реализовано.

Цитата Flex Ferrum @ 20.07.06, 20:49

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи. В стандарте С POSIX упоминается единожды - в списке библиографии. И то, видимо, из за того, что CRTL пересекается с множеством методов, определяемых POSIX. Я могу с таким же успехом взять ассемблер, или любой другой компилируемый язык и использовать в нем методы, описанные в POSIX.

Flex, извини. Всё ясно...
Читай:
http://www.schweikhardt.net/identifiers.html
http://www.gnu.org/software/libc/ с цитатой:

Цитата

The GNU C library is primarily designed to be a portable and high performance C library.

It follows all relevant standards (ISO C 99, POSIX.1c, POSIX.1j, POSIX.1d, Unix98, Single Unix Specification). It is also internationalized and has one of the most complete internationalization interfaces known.

http://www.kuzbass.ru/docs/sus2/xrat/contents.html, оттуда же -- http://www.kuzbass.ru/docs/sus2/xrat/xbd_chap01.html#tag_01_01_01_01

Либо забери свои слова обратно, либо спор прекращён. На таких условияхи при таких "знаниях", извини, но лично я не спорю, т.к. это -- не спор, а потеря времени.

Добавлено 20.07.06, 21:14
Кстати, для e-yes'а замечу, что утверждение POSIX != Linux чтоль же кхммм... "справедливо", как и POSIX != FreeBSD... :D:D:D

Цитата the_Shadow @ 20.07.06, 21:06

Либо забери свои слова обратно, либо спор прекращён. На таких условияхи при таких "знаниях", извини, но лично я не спорю, т.к. это -- не спор, а потеря времени.

Прежде чем так говорить, ты объясни своими словами - что я сказал не так? Есть POSIX - Portable Operation System Interface. Есть ISO C с его C Runtime Library. А из этого следует одна простая вещь: то, что для платформы реализован C с его CRTL еще не значит, что платформа - POSIX-совместима. Или ты возьмешься утверждать, что то, что для DJGPP реализована glibc (в определенном объеме) говорит о том, что DOS - это POSIX-совместимая операционная система? И еще, покажи мне в реализации glibc под DOS такие замечательные методы, как fork, pthread_create, и прочие функции, присутствующие в POSIX.

А потому на мои знания прошу не наезжать неаргументированно. Ссылок и я могу накидать. А потому по пунктам, и своими словами - в чем я ошибся, и в чем я показал свою некомпетентность?

Добавлено 20.07.06, 21:22
Я ошибся в том, что POSIX и ISO C - это два разных стандарта?
Я ошибся в том, что POSIX - это стандарт на интерфейс, а C - это инструментарий для работы с этим интерфейсом?
Я ошибся в том, что POSIX и CRTL в некоторой мере пересекаются?
Я ошибся в том, что из кода на ассемблере я не могу сделать вызов метода, определенного в POSIX?

Цитата Flex Ferrum @ 20.07.06, 21:15

А из этого следует одна простая вещь: то, что для платформы реализован C с его CRTL еще не значит, что платформа - POSIX-совместима.

Телега впереди лошади? Оригинально...
Вообще говоря, даже M$ _С_ является POSIX-совместимым компилятором, т.к. не важно как сделано, но поддержка POSIX есть и там. Разочарую тебя. Более того! "Поодержка POSIX-совместимости" есть обязательное условие для систем, применяемых в США (Госструктуры и Пентагон).

А теперь по пунктам:

Цитата

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи.

Всё здорово. Но сам по себе С основан на POSIX 1.x ("x" -- по причине того, что комитет меняет "номер версии"). Стандарт ISO 1003.1 описывает тот же POSIX 1.x, но на уровне международных организаций. Стандарт ANSI находится по уровню стандартов "чуть ниже", т.к. это не международный, а внутри-американский институт стандартизации. Хотя, ими принимается POSIX/ISO как основа, но они разрабатывают внутринациональные вещи.

Сравнение "компьютер и клавиатура к нему" просто не катит.

Цитата

В стандарте С POSIX упоминается единожды - в списке библиографии

Мне просто показалось или это действительно не так?

Цитата

Я могу с таким же успехом взять ассемблер, или любой другой компилируемый язык и использовать в нем методы, описанные в POSIX.

Кхммм... Думаю, не получится, т.к. POSIX 1.x описывает вполне определённые вещи и эти вещи не асм и не какой-либо другой язык. Это С. Просто С.

Цитата the_Shadow @ 20.07.06, 21:34

Вообще говоря, даже M$ _С_ является POSIX-совместимым компилятором, т.к. не важно как сделано, но поддержка POSIX есть и там.

Да не является он POSIX-совместимым компилятором. В нем даже не весь набор CRTL-ных методов поддерживатся, и код, написанный чисто на MS C в общем не портабельный без #ifdef'ов и #define'ов. Еще раз для тех, кто в танке, разберем аббревиатуру POSIXl:
Portable Operation System Interface. Т. е. (по русски) портируемый интерфейс операционной системы. Ну и вот объясни мне, как система может быть POSIX-совместима, если в ней нет даже fork'а? И еще (по поводу лошади и телеги). Объясни мне такую фразу:

Цитата

Previous revisions of POSIX.1 built upon the ISO C standard by reference only.

Если я правильн ее понимаю, то предыдущие реализации POSIX элементарно ссылались на стандарт С. Да это и логично, ибо:

Цитата

Q9. What is the history of the IEEE POSIX 1003.1 System Application Interface (C API) ?

Historically, POSIX 1003.1 has been the base standard upon which the POSIX family of standards has been built. In keeping with its original focus on the UNIX system, it is aimed at interactive timesharing computing environments.

The first edition of IEEE Std 1003.1 was published in 1988. Subsequent editions were published in 1990, 1996 and 2001. The 1990 edition was a revision to the 1988 edition and became the stable base standard onto which further amendments were added. The 1990 edition was also approved as an international standard, ISO/IEC 9945-1:1990.

The 1996 edition added the IEEE Std 1003.1b-1993, IEEE Std 1003.1c-1995, and 1003.1i-1995 amendments to the base standard, keeping the stable core text unchanged. The 1996 edition of IEEE Std 1003.1 was also approved as an international standard, ISO/IEC 9945-1:1996.

In 1998 the first real-time profile standard, IEEE Std 1003.13-1998 was published, enabling POSIX to address embedded real-time applications and smaller footprint devices.

In 1999 the decision was taken to commence the first major revision to the core base standard in ten years, including a merger with the 1003.2 standards for Shell and Utilities which had been a separate standard up to this point . It was agreed that this work be undertaken by the Austin Group. As part of this decision the PASC decided to cease rolling amendments to the base standard after completion of IEEE Stds 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, and 1003.2b. These projects were rolled into the 2001 edition of IEEE Std 1003.1. It was decided to convert other projects in progress to standalone documents.

Взято отсюда: POSIX® 1003.1 Frequently Asked Questions (FAQ Version 1.12)
Т. е. сначала появился С (в 1972-ом). А потом из части его стандартной библиотеки вырос POSIX (в 1988-ом). Тем самым я считаю вопрос с тем, где тут курица, а где яйцо - решенным.

Цитата the_Shadow @ 20.07.06, 21:34

Мне просто показалось или это действительно не так?

Поиск по файлу iso9899-c99.pdf (Programming languages — C) аббревиатуры POSIX выдал только одну ссылку:

Цитата

16. ISO/IEC 9945−2:1993, Information technology — Portable Operating System
Interface (POSIX) — Part 2: Shell and Utilities.

Группы цифр 1003.1 вообще не найдено. Если у тебя находит больше - цитаты в студию.

Цитата the_Shadow @ 20.07.06, 21:34

Думаю, не получится, т.к. POSIX 1.x описывает вполне определённые вещи и эти вещи не асм и не какой-либо другой язык. Это С. Просто С.

Т. е. вот этот код:

        .type   main, @function
main:
.LFB14:
        pushl   %ebp
.LCFI0:
        movl    %esp, %ebp
.LCFI1:
        subl    $8, %esp
.LCFI2:
        andl    $-16, %esp
        subl    $24, %esp
        pushl   $20
        pushl   $.LC0
.LCFI3:
        call    printf
        popl    %eax
        popl    %edx
        pushl   $20
        pushl   $.LC0
        call    printf
        xorl    %eax, %eax
        leave
        ret

не откомпилируется по определению? Ибо это asm, а POSIX - это С... Сам сможешь проверить? И не ты ли несколько странц назад с жаром показывал, как лихо ты ассемблерный текст превращаешь в испольняемые файлы?

Цитата Flex Ferrum @ 20.07.06, 22:11

Да не является он POSIX-совместимым компилятором. В нем даже не весь набор CRTL-ных методов поддерживатся, и код, написанный чисто на MS C в общем не портабельный без #ifdef'ов и #define'ов. Еще раз для тех, кто в танке, разберем аббревиатуру POSIXl:

Пля... Ну я тихо куею уже... Какой примерный идиотизм, а?
Итак, есть 4 уровня соответствия POSIX, да будет тебе известно!!!
И, как, мне интересно, удовлетворить в самой цинде вот этому документу -> http://www.microsoft.com/technet/interopmigration/unix/sfu/sfuposix.mspx но при этом, для разработки не пользоваться именно M$ C -- открой тайну "золотого ключика", а?
Что, пля, #define и #ifdef не определены в стандарте? С каких пор это так?

Ну, учи мат. часть (RTFM!):
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/UCMGch04.asp
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnucmg/html/UCMGch02.asp
Итак, ты, в отличие от самой M$, утверждаешь, что их M$ C -- не POSIX-compat.? А в M$ об этом знают?

Цитата Flex Ferrum @ 20.07.06, 22:11

И не ты ли несколько странц назад с жаром показывал, как лихо ты ассемблерный текст превращаешь в испольняемые файлы?

Ты можешь точно так же. В M$ DevStudio есть сходные ключи. Однако, мать его, дело не в этом. Есть стандарт. Он явно описывает нечто. С, если быть точным. И там нет описания того, что я могу, а чего не могу. Там даже нет описания того, чего я хочу, а чего -- нет. Но вот почему-то стандартные средства языка С там описаны.

Цитата Flex Ferrum @ 20.07.06, 22:11

Взято отсюда: POSIX® 1003.1 Frequently Asked Questions (FAQ Version 1.12)
Т. е. сначала появился С (в 1972-ом). А потом из части его стандартной библиотеки вырос POSIX (в 1988-ом). Тем самым я считаю вопрос с тем, где тут курица, а где яйцо - решенным.

А мне не совсем ясно как из этого проскакивает аналогия -- "компа и клавиатуры"? Откуда она следует? И откуда следует что это -- слабосвязанные вещи, вообще-то?
Или, брякнуть -- брякнул, а вот чего брякнул сам понял с трудом? Мне НЕ интересна история языка С (уверяю тебя, я с ней знаком). Я ХОЧУ ПОЛУЧИТЬ ОТВЕТ НА ОДИН ПРОСТОЙ ВОПРОС -- ОТКУДА ТАКИЕ СМЕЛЫЕ АНАЛОГИИ? О том, что С и POSIX:

Цитата

Не дурно было бы заметить, что POSIX и C это, гм, примерно то же самое, как компьютер целиком и клавиатура к нему. Т. е. не сравниваемые вещи.

Добавлено 20.07.06, 23:17
Впрочем, надоело. На хрен. К терапевту.

Цитата the_Shadow @ 20.07.06, 23:05

Пля... Ну я тихо куею уже... Какой примерный идиотизм, а?
Итак, есть 4 уровня соответствия POSIX, да будет тебе известно!!!
И, как, мне интересно, удовлетворить в самой цинде вот этому документу -> http://www.microsoft.com/technet/interopmi...u/sfuposix.mspx но при этом, для разработки не пользоваться именно M$ C -- открой тайну "золотого ключика", а?
Что, пля, #define и #ifdef не определены в стандарте? С каких пор это так?

А вот лучше ты мне эту тайну открой. А также покажи мне в поставке компилятора от мелкомягких загловочный файл unistd.h.
Hint: в поставке VC 7.1 его точно нет. Сто пудов. Как обстоят дела в 8.0 - ХЗ, ибо не имею оного.
А из приведенных по твоей ссылке примеров явно видно, что для компиляции используется все тот же gcc. Т. е. винду можно заставить быть POSIX-совместимой. Но в стандартную поставку это не входит (иначе я не понимаю - что такое INTERIX), и компиляторы от мелкомягких с POSIX явно не дружат, а точнее - не в полной мере соответствуют все тому же ISO 9899.

Цитата the_Shadow @ 20.07.06, 23:05

Есть стандарт. Он явно описывает нечто. С, если быть точным. И там нет описания того, что я могу, а чего не могу. Там даже нет описания того, чего я хочу, а чего -- нет. Но вот почему-то стандартные средства языка С там описаны.

Ты для начала сам для себя определись - что и какой стандрат описывает. Что описывает стандарт IEEE 1003.1x/ISO IEC 9945−2:1993, и что - ISO 9899. Hint: первый упомянутый мною стандарт язык С точно не описывает.
И не поленись - залесь в стандарт С, и поищи там ссылки на POSIX. И не забывай волшебное заклинание: "Гугл любит меня".

Цитата the_Shadow @ 20.07.06, 23:05

А мне не совсем ясно как из этого проскакивает аналогия -- "компа и клавиатуры"? Откуда она следует? И откуда следует что это -- слабосвязанные вещи, вообще-то?

Да оттуда и следует. Комп - то, чем можно управлять, клавиатура - то, с помощью чего управляют. POSIX - набор интерфейсов, которые можно дергать. С - средство (одно из нескольких), с помощью которого эти интерфейсы можно подергать. Все еще не понятно? Интерфейс не может быть языком. А язык - интерфейсом. У них разные задачи.

Добавлено 20.07.06, 23:22

Цитата the_Shadow @ 20.07.06, 23:05

Впрочем, надоело. На хрен. К терапевту.

Во во. Все смешалось в доме Облонских. Языки, интерфейсы, операционки...