Сообщение при линковке
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in libcpmtd.lib(newop.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmtd.lib(newaop.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in LIBCMTD.lib(delete2.obj)
.\Debug/parser.exe : fatal error LNK1169: one or more multiply defined symbols found
Использую VS2003, консольное приложение, конфигурации debug и release
Пересоздай проект.
Не помогает
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z) already defined in libcpmtd.lib(newop.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete(void *)" (??3@YAXPAX@Z) already defined in LIBCMTD.lib(dbgdel.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void * __cdecl operator new[](unsigned int)" (??_U@YAPAXI@Z) already defined in libcpmtd.lib(newaop.obj)
nafxcwd.lib(afxmem.obj) : error LNK2005: "void __cdecl operator delete[](void *)" (??_V@YAXPAX@Z) already defined in LIBCMTD.lib(delete2.obj)
.\Debug/parser.exe : fatal error LNK1169: one or more multiply defined symbols found
Что-то многопоточное делаешь судя по libcmtd.lib Если так, то /NODEFAULTLIB должен тебя спасти.
Что-то многопоточное делаешь судя по libcmtd.lib Если так, то /NODEFAULTLIB должен тебя спасти.
Да нет, обычное приложение.
Странно, но проблема исчезла при включении файла <afxwin.h> в один из файлов проекта.
Вообще-то я хотел все сделать на STL и часть файлов в проекте вообще не требовали <afxwin.h>, другая часть работала через MFC.
Так вот, при линковке проекта, в котором ВООБЩЕ не используется MFC все линковалось.
При добавлении файлов, требующих MFC, возникала эта ошибка и приходилось в файлы, написанные на STL, добавлять <afxwin.h>.
В чем дело - непонятно.
В STL использовал <exception> и <string>
Да нет, обычное приложение.
Странно, но проблема исчезла при включении файла <afxwin.h> в один из файлов проекта.
Вообще-то я хотел все сделать на STL и часть файлов в проекте вообще не требовали <afxwin.h>, другая часть работала через MFC.
Так вот, при линковке проекта, в котором ВООБЩЕ не используется MFC все линковалось.
При добавлении файлов, требующих MFC, возникала эта ошибка и приходилось в файлы, написанные на STL, добавлять <afxwin.h>.
В чем дело - непонятно.
В STL использовал <exception> и <string>
Похоже MFC переопределяет оператор new и delete, STL делает то же самое и происходит конфликт.
Так вот, при линковке проекта, в котором ВООБЩЕ не используется MFC все линковалось.
При добавлении файлов, требующих MFC, возникала эта ошибка и приходилось в файлы, написанные на STL, добавлять <afxwin.h>.
Ну дык естессно - пытался винигрет написать и удивлялся почему без половины компонентов не получается :)
Ну дык естессно - пытался винигрет написать и удивлялся почему без половины компонентов не получается :)
Что значит винегрет?
Я переписываю приложение с MFC на STL. Естественно, при тестировании разные части приложения накладываются...
И потом я не уверен, что все можно написать на STL. Например, известен кому-либо способ вывода двумерной научной графики на STL? Я знаю только способ через GDI (соответственно MFC). Или вывода окна приложения.
И потом приложение все-таки линкуется при подключении <afxwin.h>.
А значит STL и MFC уживаются. если что-то реализовано лучше в одной библиотеки, чем в другой, можно ли их совмещать?
Попытался создать консольное приложение на Си++ без использования MFC, ATL, только STL, но при линковке выдается след. сообщение
Попробуй поиграться с ключами компиляции /MT, /MLd и т.п.
Попробуй поиграться с ключами компиляции /MT, /MLd и т.п.
Не помогает.
Кстати, заметил тут еще одну деталь. Если использовать перегрузку new, которую дает MFC, то в окне при отладке будет сообщено об ошибке освобождения ОЗУ (например, когда программист забыл удалить выделенный объем ОЗУ).
Если перегрузку new делает STL, этого не происходит. Т.е. в этом случае уловить ошибку не удастся при отладке.
Т.е. что-то реализовано лучше в MFC, что-то в STL.
Есть ли возможность использовать сразу несколько библиотек?
Т.е. интерфейс делать в MFC, а внутреннюю архитектуру - с использованием STL?
Обработка исключ. ситуаций - особый вопрос. Думаю и эту часть лучше делать с использованием STL.
Но в остальном ты чегото нетого делаеш. Как это ты собрался перенести мфц в консоль? Рисовать будеш менюшки, а-ля TurboVision?? Во первых стл нормально работает с с мфц, а ошибки у тебя из-за частичного исключения мфц из проекта. Короче винигрет, как сказал pacific_7. Во вторых чтоб рисовать придется юзать или апи или мфц, что почти одно и тоже, в стл нету графичиских средств.
Так что ты куда переписывать собрался - ниче непонятно.
Скорее всего в каждый файл нужно включить "stdafx.h" - прекомпилер хедер.
По сути это тоже самое что и включение afx.h. Проблема описана в MS Knowledge Base.
Но в остальном ты чегото нетого делаеш. Как это ты собрался перенести мфц в консоль? Рисовать будеш менюшки, а-ля TurboVision?? Во первых стл нормально работает с с мфц, а ошибки у тебя из-за частичного исключения мфц из проекта. Короче винигрет, как сказал pacific_7. Во вторых чтоб рисовать придется юзать или апи или мфц, что почти одно и тоже, в стл нету графичиских средств.
Так что ты куда переписывать собрался - ниче непонятно.
Переписывать собственные структуры, которые реализовал, не зная STL. Вернее заменить их на стандартизированные и документированные классы, которые входят в STL. stack, list уже есть и городить что-то свое не имеет смысла.
Сейчас меня интересует класс, которые бы позволял хранить имена переменных и быстро их находить.
Перенести мфц в консоль не собираюсь - конечно же не об этом речь. А вот то, что STL уживается с MFC нужно было сказать сразу. Чтобы не возникало вопроса в том, какой выбрать класс - CString или string. Выбор последнего очевиден - это стандартизированный класс. CString как и сама MFC уходит.