Совместное использование *.сpp файлов и *.c, Не компилируются совместно файлы Си и Си++ Опции

[kolobochishe]

Вот такая ошибка при вызове функции написанной в *.cpp файле из *.с файла

Linking
Error[Li005]: no definition for "plot_spectrum" [referenced from C:\ÐÀÁÎÒÀ\ÐÀÇÐÀÁÎÒÊÈ\ÏÐÎÅÊÒÛ\ÄÐÀÊÎÍ\Ðåãèñòðàòîðû\Ïðîøèâêà\
LPC3250 GUI_RTOS\arm\PowerPac\BoardSupport\NXP\LPC3250\Output\LPC3250\Debug_SDRAM\Obj\DRAGON_BS1_GUI.o]
Error while running Linker

Функция объявлена в соответствующем *.h файле. Он подключен везде, где требуется.

[MrYuran]

В хедерах си-шных модулей надо вставить скобки

Код

#ifdef __cplusplus
BEGIN_EXTERN_C
#endif
...
#ifdef __cplusplus
END_EXTERN_C
#endif

, где

Код

#define BEGIN_EXTERN_C           extern "C" {
#define END_EXTERN_C             }

Компилировать и линковать в режиме "плюсов"

[sergeeff]

Проще прямо написать

Код

#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif

Сообщение отредактировал IgorKossak - Jun 9 2011, 07:51

[kolobochishe]

В хедерах си-шных модулей надо вставить скобки

Код

#ifdef __cplusplus
BEGIN_EXTERN_C
#endif
...
#ifdef __cplusplus
END_EXTERN_C
#endif

, где

Код

#define BEGIN_EXTERN_C           extern "C" {
#define END_EXTERN_C             }

Компилировать и линковать в режиме "плюсов"

Компилится. Только не в хэдерах си-шных модулей, а в хэдере си++ модуля. У меня только так заработало.

[mdmitry]

Компилится. Только не в хэдерах си-шных модулей, а в хэдере си++ модуля. У меня только так заработало.

Можно ставить с любых заголовочных файлах, которые включаются в проект для с и cpp.

[inventor]

Можно ставить с любых заголовочных файлах, которые включаются в проект для с и cpp.

в принципе если извратица то можно из сишной программы вызывать с++ модули.
у вас проблема в том, что С++ делает такую хрень как name mangling.
то есть при линковке имена ваших функций становятся такими что их сишный линкер
не может понять.
решение которое вам подсказали вверху заставляет линкер не искажать имя функции.
но если вы попробуете предложить несколько функций с одинаковым названием-перегруженные,
то опять получите ошибку.

[sergeeff]

в принципе если извратица то можно из сишной программы вызывать с++ модули.

Если вы можете компилировать с++ модули (компилятор позволяет), то никто не мешает сказать ему, чтобы для компиляции .с модулей тоже вызывался С++ компилятор. На худой случай, просто переименовать *.с в *.срр.

[zltigo]

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

С и С++ два разных языка - сколь-нибудь объемный и что-то делающий исходник на 'C' (не "Hello World!" ) плюсовым компилятором не откомпилится. Потребуются правки. В большей частью мелкие, но местами и принципиально все меняющие.

[sergeeff]

С и С++ два разных языка - сколь-нибудь объемный и что-то делающий исходник на 'C' (не "Hello World!" ) плюсовым компилятором не откомпилится. Потребуются правки. В большей частью мелкие, но местами и принципиально все меняющие.

Хоть один пример.

[zltigo]

Хоть один пример.

Берете свой проект, компилите плюсовым. Получаете примеры

[Сергей Борщ]

Хоть один пример.

Область видимости констант, неявное приведение void * к любому указателю в С. Это так, навскидку.

[Danis]

Хоть один пример.

для С++ NULL не типизирован явно, как в Си, так что приходиться делать так:

/* Define NULL pointer value */
#ifndef NULL
#ifdef __cplusplus
#define NULL 0
#else
#define NULL ((void *)0)
#endif
#endif

[zltigo]

Область видимости констант, неявное приведение void * к любому указателю в С. Это так, навскидку.

Декларация и инициализация стуктур и константных объектов, тип литералов типа 'abcd', объявления типов в sizеof, , функции с переменным количеством аргументов, еще некоторые до сих пор не польззуются прототипами функций и C а не C99,..... В общем лучше попробовать компильнуть
Вообще-то в С++ стандарте, помнится, было целое приложение посвященное проблемам несовместимости.

P.S.
Да. Посмотрел - Annex C Compability. Единственно, что там явно не C99. Да и многие 'С' компиляторы будут на некоторые конструкции хоть не ошибки, но warnings выдавать.

[dxp]

Область видимости констант, неявное приведение void * к любому указателю в С. Это так, навскидку.

Ещё работа с перечислимыми типами.

[sonycman]

А наоборот может быть - ошибка при вызове из си++ файла функции, объявленной в простом си исходнике?

Ошибка такая же - Li005 - линкер не может найти определение функции...

[sergeeff]

А наоборот может быть - ошибка при вызове из си++ файла функции, объявленной в простом си исходнике?

Ошибка такая же - Li005 - линкер не может найти определение функции...

Вы хоть эту ветку читаете? Про extern "C"?

[sonycman]

Вы хоть эту ветку читаете? Про extern "C"?

А вы хоть читаете, о чём я спрашиваю?
Одно дело, когда обычный си модуль не может найти си++ функцию, имя которой, по понятным причинам, видоизменено.
Но когда наоборот - си++ модуль в упор не видит обычную си функцию?

В этом случае ведь name mangling не работает?

Ошибка уходит, когда принудительно включаю компиляцию си файлов в режиме си++.

[AHTOXA]

Но когда наоборот - си++ модуль в упор не видит обычную си функцию?

Именно для этого случая и нужно в заголовочных файлах от си функций писать extern "C". Иначе C++ ожидает функции с замангленными именами.

[sonycman]

Именно для этого случая и нужно в заголовочных файлах от си функций писать extern "C". Иначе C++ ожидает функции с замангленными именами.

Понятно. Значит, всегда, когда плюсы имееют дело с ассемблерными или обычными сишными модулями (или наоборот) необходимо юзать этот костыль.
Спасибо

[sergeeff]

Понятно. Значит, всегда, когда плюсы имееют дело с ассемблерными или обычными сишными модулями (или наоборот) необходимо юзать этот костыль.
Спасибо

А это вовсе не костыль, а возможность из С++ использовать С/ASM модули. Вам эта возможность не нравится?

[sonycman]

А это вовсе не костыль, а возможность из С++ использовать С/ASM модули. Вам эта возможность не нравится?

Я об этом знал, но считал, что это работает только в сторону от си++ к си.
Не думал, что плюсы будут манглить даже обычную сишную функцию, подключенную через хидер

[dxp]

Я об этом знал, но считал, что это работает только в сторону от си++ к си.
Не думал, что плюсы будут манглить даже обычную сишную функцию, подключенную через хидер

Если компиляете в С++ режиме, то все функции будут кодироваться по-плюсатому. Ведь в плюсах обычное дело та же перегрузка имён функций, и как компилятор должен догадаться, какие функции у вас имеют С-связывание, а какие С++ связывание. Для этого и введена спецификация связывания extern "<Lang>", где <Lang> - отличный от С++ язык (там не обязательно должен быть С, хотя этот вариант встречается в подавляющем большинстве случаев).

[XVR]

Не думал, что плюсы будут манглить даже обычную сишную функцию, подключенную через хидер

А откуда С++ знать, что это 'обычная С функция'? Для этого extern "C" и предназначен

[sonycman]

Если компиляете в С++ режиме, то все функции будут кодироваться по-плюсатому. Ведь в плюсах обычное дело та же перегрузка имён функций, и как компилятор должен догадаться, какие функции у вас имеют С-связывание, а какие С++ связывание. Для этого и введена спецификация связывания extern "<Lang>", где <Lang> - отличный от С++ язык (там не обязательно должен быть С, хотя этот вариант встречается в подавляющем большинстве случаев).

Спасибо.
Интересно, а какие ещё есть идентификаторы <Lang>?

А откуда С++ знать, что это 'обычная С функция'? Для этого extern "C" и предназначен

Так тело-то этой функции - в обычном .c файле!
Компилер что, манглит сразу имя функции по её объявлению в хидере, не заглядывая даже в определение?
Вот шустрый какой!

[XVR]

Так тело-то этой функции - в обычном .c файле!

А как компилятор в процессе компиляции файла А узнает о теле функции в файле Б? Он же их отдельно компилирует

Компилер что, манглит сразу имя функции по её объявлению в хидере, не заглядывая даже в определение?

Разумеется. Тело функции его не интересует (его вообще может не быть)

[sonycman]

Разумеется. Тело функции его не интересует (его вообще может не быть)

Понятно, теперь буду знать. Спасибо!

[dxp]

Интересно, а какие ещё есть идентификаторы <Lang>?

Мне попадалось FORTRAN.

[zltigo]

Мне попадалось FORTRAN.

И PASCAL

[inventor]

Кстати, никогда не делайте программы для DSP и контроллеров на С++
выгоды которые вы получите весят меньше чем недостатки и косяки
которые вы встретите и не сможете устранить.
То есть делайте свои программы исключительно на C
а не С++.
Безо всяких "extern C"/
Все таки язык С++ был разработан совсем для других целей.
Ну там базы данных писать и что-то подобное большое.
В качестве системного языка он не подходит.
По моему скромному мнению.
Хотя находятся герои которые для QNX что-то на С++ ваяют.

Сообщение отредактировал inventor - Jun 22 2011, 10:53

[dxp]

Кстати, никогда не делайте программы для DSP и контроллеров на С++

Вам сюда.

[inventor]

Вам сюда.

Для меня достаточно просто посмотреть на код С++ в асме-
что он там плодит, чтобы больше так никогда не делать.
Все это красиво получается в исходниках, но не в работе.

[AHTOXA]

Все таки язык С++ был разработан совсем для других целей.
Ну там базы данных писать и что-то подобное большое.
В качестве системного языка он не подходит.
По моему скромному мнению.
Хотя находятся герои которые для QNX что-то на С++ ваяют.

Вот сразу видно - пришёл человек знающий, глубоко разбирающийся в предмете. Всё чётко разложил по полочкам, разоблачил мифы, расписал недостатки, прямо и без обиняков. Теперь мы будем знать, какая кака этот C++. Спасибо вам, уважаемый inventor!

[dxp]

Для меня достаточно просто посмотреть на код С++ в асме-
что он там плодит, чтобы больше так никогда не делать.
Все это красиво получается в исходниках, но не в работе.

Заинтриговали. И что же он там такое плодит? Можно пример?

[zltigo]

Заинтриговали. И что же он там такое плодит?

А, полагаю, все как обычно, например, то, что видит человек сумевший написать 100 команд (условно) на ASM, при виде листинга С/C++ программы хотя-бы на десяток килобайт. А видит он количество команд выходящее за рамки его разумения, вот и все . Занавес. Однажды я наблюдал шоковое состояние когда считающемуся достаточно опытным ASM писателю предъявил вместо его программы на ASM, которая,
1) была размером под 8K;
2) генерировала иногда в ответ не такой, сигнал, какой хотел заказчик;
3) не тянула генерацию оного сигнала выше 12KHz (заказчик уже соглашался ставить другой контроллер ).
Сишную, писанную за воскресенье, на пару килобайт меньше, правильно работающую, и к тому-же успевающую где-то под 40KHz работать.
Он думал, а может и сейчас так думает, что его просто дурят прокручивая ему на экране LeCroy какую-то обманку . Поскольку доподлинно знал, что С есть гуано , поскольку тоже что-то вроде "просто посмотреть на код С++ в асме что он там плодит,"

[XVR]

Для меня достаточно просто посмотреть на код С++ в асме-
что он там плодит, чтобы больше так никогда не делать.

Угу, видели видели. Начинается с воплей 'какое С/С++ гуано', а заканчивается открытием, что у С/С++ компиляторов оказывается есть разные уровни оптимизации и дебаггерные режимы

[inventor]

Угу, видели видели. Начинается с воплей 'какое С/С++ гуано', а заканчивается открытием, что у С/С++ компиляторов оказывается есть разные уровни оптимизации и дебаггерные режимы

код написанный на С++
исполняется дольше кода написанного на С или на asm
хоть ты усрись с оптимизацией

[MrYuran]

код написанный на С++
исполняется дольше кода написанного на С или на asm
хоть ты усрись с оптимизацией

Да и на здоровье.
Ну вот какая, к примеру, разница, находится процессор в IDLE 99% или 98,9% времени?
То же самое в большинстве случаев можно сказать и про объём.

[dxp]

код написанный на С++
исполняется дольше кода написанного на С или на asm
хоть ты усрись с оптимизацией

Это такой закон природы или что? Пример покажите?

[inventor]

Это такой закон природы или что? Пример покажите?

Нет.
Это объективная реальность
Сейчас нет под рукой примера, завтра что-нибудь нарою.

[XVR]

код написанный на С++
исполняется дольше кода написанного на С или на asm

Угу, угу. Вспоминается (с баша вроде) -

- Вот, моя программа в 10 раз меньше, в 3 раза быстрее и памяти жрет в 5 раз меньше, чем твоя!
- Зато моя работает, а твоя нет.

Желаю успехов в написании программ на ассемблере, ну к примеру, для Itanium'а

хоть ты усрись с оптимизацией

Это с опытом обычно проходит

[sergeeff]

Уж сколько понаписано про преждевременную оптимизацию, а воз и ныне там. При программировании на С++, после некоторого периода времени по его освоению и написания собственного прикладного инструментария (библиотек необходимых классов), голова освобождается от необходимости "борьбы с мелочами". Занимаешься собственно решением поставленной задачи, а не поиском какого-нибудь побочного эффекта из-за преобразования указателя к (void *).

Думается уважаемый inventor долго нам будет пример искать.

[zltigo]

Уж сколько понаписано

глупостей

про преждевременную оптимизацию, а ....

Не все правда глупости, но 95% процентов воспринимают подобные речи о "преждевременности" таким образом, что в результате делают глупости .

А причем тут преждевременная оптимизация вообще-то???

[inventor]

глупостей

Не все правда глупости, но 95% процентов воспринимают подобные речи о "преждевременности" таким образом, что в результате делают глупости .

А причем тут преждевременная оптимизация вообще-то???

Не было времени сегодня искать пример,
щас попробую его описать.
Процессор работает на чатоте 14 Мгц
обменивается с другим процом на частоте 1Мгц.
На асме около 70 строк кода обработчика прерывания.
На С примерно в два раза больше.
Программа на С работает на пределе.
Но не сбоит.
Даже не представляю как это будет работать на С++.
Да...вся программа умещается во внутренней памяти DSP.

[sergeeff]

глупостей

Не все правда глупости, но 95% процентов воспринимают подобные речи о "преждевременности" таким образом, что в результате делают глупости .

А причем тут преждевременная оптимизация вообще-то???

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

[zltigo]

А что, вопли про громоздкий код С++ по сравнению с С не есть пример "преждевременной оптимизации"?
....
По моему - типичный пример

После этого я совсем перестал понимать смысл вкладываемый Вами в словосочетания "преждевременная оптимизация".
Ну да ладно, переживу.

[sergeeff]

После этого я совсем перестал понимать смысл вкладываемый Вами в словосочетания "преждевременная оптимизация".
Ну да ладно, переживу.

По-моему, вполне понятно о чем идет речь. Заявляется (голословно), что С++ язык медленный, а С и, уж конечно, ASM, намного быстрее. Посему, задача изначально проектируется не на С++. Ровно про это писал Александреску со-товарищи, а именно, сначала сделайте работоспособное решение, а потом, изучайте узкие места и их оптимизируете. Вроде я "мастерам" не противоречу, говоря о "преждевременной оптимизации"-

[zltigo]

Ровно про это писал Александреску со-товарищи, а именно, сначала сделайте работоспособное решение, а потом, изучайте узкие места и их оптимизируете.

Вы опять с этим Александреску с его обобщенно-шаблонно-абстрактным программированием .
Нам такие товарищи эмбеддерам совсем НЕ товарищи. Думать о построении системы и узких местах нужно СРАЗУ, а не потом рассматривая что такое выросло и как "оптимизировать" сие ЗАПЛАТКАМИ. Все узкие места должны быть ИЗВЕСТНЫ на этапе проектирования, и сделаны ОЦЕНКИ критичности этих мест до того, как будет написана левой ногой кучи кода.

[sergeeff]

Вы опять с этим Александреску с его обобщенно-шаблонно-абстрактным программированием .
Нам такие товарищи эмбеддерам совсем НЕ товарищи. Думать о построении системы и узких местах нужно СРАЗУ, а не потом рассматривая что такое выросло и как "оптимизировать" сие ЗАПЛАТКАМИ. Все узкие места должны быть ИЗВЕСТНЫ на этапе проектирования, и сделаны ОЦЕНКИ критичности этих мест до того, как будет написана левой ногой кучи кода.

Ну ладно. Александреску нам не авторитет. Мне тоже не все его мысли и рецепты нравятся, хотя встречаются и очень изящные решения. Посмотрим с другой стороны. Имеем в начале работы процессор, компилятор и стандартную библиотеку. Начинаем работать? Начинаем. Прикидываем все, где чего и как по-лучше написать. Сделали. И вдруг (или не вдруг) натыкаемся на то, что стандартная memcpy полная г...о (на форуме мы это неоднократно обсуждали), а мы ее пользуем в хвост и в гриву. Затем выясняется, что и memset такая же. А потом понимаем, что вся куча написана через жо...у. Мы про это тоже СРАЗУ должны были знать на начальном этапе проектирования? Откуда? Нам фирма-изготовитель компилятора "любезно" рассказала?

Вы всегда можете предсказать какой именно алгоритм сортировки окажется самым быстрым на вашем конкретном типе данных? Ой ли.

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

Резюме (мое личное, может и неправильное) - невозможно все заранее предусмотреть (кое что можно), хотя бы из-за ограниченности собственных временнЫх возможностей и сил. Проект всегда итерационен (почти).

[Dog Pawlowa]

Проект всегда итерационен (почти).

Не могу согласиться.
Практически во всех проектах можно безболезненно заложить ресурсов в два раза больше, чем требуется при первоначальной оценке.
При некотором отличном от нуля опыте этого вполне хватает, чтобы изменения ТЗ и особенности функционирования семейства контроллеров и/или библиотек уложились в резерв.

[inventor]

Сделали. И вдруг (или не вдруг) натыкаемся на то, что стандартная memcpy полная г...о (на форуме мы это неоднократно обсуждали), а мы ее пользуем в хвост и в гриву. Затем выясняется, что и memset такая же. А потом понимаем, что вся куча написана через жо...у. Мы про это тоже СРАЗУ должны были знать на начальном этапе проектирования? Откуда? Нам фирма-изготовитель компилятора "любезно" рассказала?

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

[zltigo]

Имеем в начале работы процессор, компилятор и стандартную библиотеку.

Забыли главное - голову на плечах и опыт отличный от нуля. Без этих двух вещей получаем воинствуещего ламера inventor .

Проект всегда итерационен (почти).

Подход а-ля Александреску характерен для научных работ - давайте на бумаге/модели получим, хоть какой-то результат и потом подумаем, что дальше делать. У инженеров в сложных случаях тоже есть понятие НИОКР, но это именно заранее запланированный этап.

Именно так и есть, обычно все библиотеки САМ перекопилируешь-выкидывая оттуда
все ненужное и исправляя ихние ошибки.

[sergeeff]

Забыли главное - голову на плечах и опыт отличный от нуля.

Это само собой подразумевалось. Однако, при переходе на новый процессор+компилятор всегда есть определенная доля неизведанности, понимание которой приходит не СРАЗУ, а по мере работы над проектом.

Потом, мне кажется, спор возник из-за наличия двух принципиально различных типов проектов. Первые, по типу обучения в вузе "зазубрил/сдал/забыл", а вторые - большие проекты, пишущиеся и развивающиеся годами. Коллеги работают в разных типах проектов, отсюда и разное видение проблем.

[zltigo]

Однако, при переходе на новый процессор+компилятор всегда есть определенная доля неизведанности, понимание которой приходит не СРАЗУ, а по мере работы над проектом.

На новый процессор - для этого существуют отладочные платы - купил, попробовал, в том числе и принципиально узки места по железу/софту, осознал...
С компиляторами все еще проще - они достаточно все одинаково хороши и обычно кроссплатформенны, посему, как правило, компилятор уже достаточно знаком.
Исключения встречаются, но они скорее всего уже именно исключения, если необходимо вдруг наконец-то заставить работать что-то старое неведомо кем сделанное. И тогда имеем какой-нибудь достаточно ущербный контроллер и такой-же замерший в прошлом компилятор. Я в прошлом году дважды с таким сталкивался - PIC16 + Hi-Tech C компилятор и M8C + ImageCraft. Это дополнительно создает некоторые хлопоты. Но это был такой прыжок в прошлое. Нехарактерный.

Потом, мне кажется, спор возник из-за наличия двух принципиально различных типов проектов.

Категорически нет. Проблема просто у уровне знаний - ниже плинтуса, или выше.

[sergeeff]

Категорически нет. Проблема просто у уровне знаний - ниже плинтуса, или выше.

Согласитесь,что проект <4Kb и проект >1Mb несколько отличаются. И технологии при их реализации тоже.

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

[MrYuran]

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

Да, но не надо переживать о нескольких лишних байтах/циклах там, где это совершенно некритично.
Некоторые в ужасе хватаются за голову, видя в контроллерном проекте float.
Ну а что такого? Если скорость всех расчётов на порядки выше, чем скорость поступления сэмплов с АЦП.
Вот это видимо и имелось в виду.
Не надо пытаться заоптимизировать всё до смерти без насущной необходимости.
Иметь представление об узких местах и проектировать с их учётом - надо.

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

Вот нашёл, цитата из книги:

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

[dxp]

Не было времени сегодня искать пример,
щас попробую его описать.
Процессор работает на чатоте 14 Мгц
обменивается с другим процом на частоте 1Мгц.
На асме около 70 строк кода обработчика прерывания.
На С примерно в два раза больше.
Программа на С работает на пределе.
Но не сбоит.
Даже не представляю как это будет работать на С++.
Да...вся программа умещается во внутренней памяти DSP.

И где тут пример? Привели какие-то общие фразы, дескать, тут быстрее, тут медленее, а С++ тут вообще в пролёте. Где аргументы? Где доказательства? Реальный пример давайте. Например, вот написали протокол обмена по UART на С++, оказалось в два раза медленнее, чем на С. Вот и давайте оба варианта (на С и на С++) в студию. Это будет пример, который можно обсуждать.

Вы опять с этим Александреску с его обобщенно-шаблонно-абстрактным программированием .
Нам такие товарищи эмбеддерам совсем НЕ товарищи.

Подход а-ля Александреску характерен для научных работ - давайте на бумаге/модели получим, хоть какой-то результат и потом подумаем, что дальше делать. У инженеров в сложных случаях тоже есть понятие НИОКР, но это именно заранее запланированный этап.

Насчёт Александреску вынужден не согласиться. У него показаны приёмы, как сделать написание кода более удобным и безопасным. Это, конечно, требует труда вникать (например, списки типов я так до конца и не вкурил - хоть и интересно, но актуальности пока нет и не предвидится, хотя имею в виду). Но у него помимо "тяжёлых" вещей вроде разработки на основе стратегий, немало просто полезных фишек вроде "распознавания конвертируемости и наследования на этапе компиляции". Конечно, подобные приёмы возникли от недостатка соответствующих средств в самом языке, но само решение очень красиво и, главное, в отличие от typeof(), выполняется на этапе компиляции. Или его менеджер памяти, который оптимизирован (скорость и компактность) для работы небольшими (десятки байт) объектами. Для AVR, конечно, не пойдёт, но на каком-нить АРМе уже вполне может оказаться кстати.

Вообще, Александреску представляет очень интересный взгляд на хорошо известные штатные языковые средства, и взгляд этот у него очень нестандартен. Даже если не подсаживаться на эти приёмы, поизучать (даже просто прочитать на разок) оказывается очень нелишним. Достойное чтиво и неплохая разминка для мозгов.

[MrYuran]

Даже если не подсаживаться на эти приёмы, поизучать (даже просто прочитать на разок) оказывается очень нелишним. Достойное чтиво и неплохая разминка для мозгов.

Согласен, хотя я пока ниасилил. Выглядит как книга магических заклинаний: завораживает, но ничего не понятно! Остаётся пользоваться готовыми рецептами, самому готовить ещё учиться и ещё два раза.

[zltigo]

Насчёт Александреску вынужден не согласиться......

Я не об этом - он реально занимается решением ДРУГИХ задач и выхватывать из его книг какие-то слова, например, о вреде преждевременной оптимизации и поминать их всуе, как минимум, не корректно.

Вот нашёл, цитата из книги:

Золотые слова - подпишусь под каждым. Только вот К ЖУТЧАЙШЕМУ моему сожалению толпы эмбеддерщиков об оптимизации на верхних уровнях думают с трудом . Зато по рассуждать о том что на десяти командах они на АSM обгонят компилятор это всегда готовы . А услышав слова о вреде преждевременной оптимизации поснимают галочки где-нибудь в IDE и скажут, что Александреску с Макконнелом так велят .
Умение оптимизировать на верхних уровнях определяется в том числе и инструментальными средствами которые человек освоил. Одно дело, когда человек пошел от сохи железа и постиг программирование в кодах (на самом деле он считает, что пишет, на ASM, но реально это настолько минималистичное использование даже ASM, что это практически кодирование ). Другое, когда уже понимает и имеет успешный опыт, например, в C++. Это другие горизонты, другое понимание и другие возможности.

[dxp]

Согласен, хотя я пока ниасилил. Выглядит как книга магических заклинаний: завораживает, но ничего не понятно! Остаётся пользоваться готовыми рецептами, самому готовить ещё учиться и ещё два раза.

Мне тоже не всё понятно было (пока её только на разок прошёл), но кое-что уже в кассу. Например, подсмотрел приём, который он там реализует для стратегий:

Код

template<typename T> class A : public T { ... };

Т.е. шаблон, позволяющий генерировать реализацию с выбором базы для неё. Простая, в общем-то, штука, но как-то само в голову не пришло. Эту вещь реально поюзал.

Или реализация класса Conversion (п.2.7). Довольно простое и изящное решение на основе свойств оператора sizeof(). Пока применить не пришлось, но имею в виду. Очень нравится незамутнённый нестандартный взгляд на привычные, уже набившие оскомину вещи. Что ни говори, а Александреску молодец, и каждый при желании может там найти для себя что-то полезное и интересное.

[ar__systems]

код написанный на С++
исполняется дольше кода написанного на С или на asm
хоть ты усрись с оптимизацией

Блин ну ладно еще асм с с сравнивать, это еще как бы куда ни шло, хотя с оговоркой - кто писал си и кто писал асм. Но С++ с С противопоставлять - вы понимаете что что С++ принципиально не отличается от С?