Можно ли от избавиться от stdafx.h?
От: McSeem2 США http://www.antigrain.com
Дата: 22.09.02 02:56
Оценка:
Проблема проста. Я включаю в свой MFC-проект некие левые .cpp файлы (свои или чужие — не важно), в которых используюся операторы new/delete. Так вот, не линкуется зараза! Не линкуется только со static MFC и говорит о дублировании символов. Очевидно, MFC использует какие-то свои new/delete, которые конфликтуют с new/delete из CRT. Но я не хочу использовать DLL и делать свой release зависимым от mfcXXXX.dll. Я так же не хочу включать stdafx.h в эти cpp-файлы — я могу это сделать в своих файлах, но в конце концов, если я использую что-то чужое, пришедшее, скажем, из Linux, но абсолютно системо-независимое, то все равно проблема остается. Просто не хорошо это — трогать чужой код. Можно включить опцию линкера "Force output", но результат как-то не внушает доверия — об этом же и предупреждения будут. Можно сделать один .cpp файл, включающий stdafx.h и затем — все остальные "левые" .cpp файлы. Это работает, но, согласитесь, выглядит совершенно по-уродски — где идея о раздельной компиляции? Так чего же я хочу? Очень простого — возможности слинковать с MFC другие .cpp файлы, написанные в полном соответствии с индустриальным стандартом C++ без их модификации, а просто включив в проект. Пример здесь: http://www.antigrain.com/customrenderer.zip
Не знаю, может есть каклй-нибудь #define, как в ATL: ATL_MIN_CRT, включение которого приводит примерно к тем же проблемам, за счет уменьшения объема бинарного кода. Нет ли какого аналогичного в MFC, но наоборот, типа #define ПОДРУЖИТЬ_MFC_И_CRT — и настало щщастье .
В общем,
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.