Visual C++ и окно ClassView , как-то можно улучшить?

[volod]

Проблема в следующем:
когда я начинал разрабатывать приложение, все было шоколадно - несколько стандартных классов, удобный просмотр, поиск через class view и все. Но постепенно размер программы растет, создаются новые классы. Сейчас вот надо закодить окно настроек с вкладками - а это еще 5-6 дополнительных классов, ассоциированных с окнами. Плюс пришлось подключить исходники SQLite-библиотеки базы данных, и количество классов выросло до такого размера, что навигация по ним затруднена.

Вопрос. В Visual Studio как-то можно сгруппировать классы? Чтобы в окне class view было нечто вроде дерева с раскрывающимися узлами, а не их одноуровневое перечисление. Ну или как-нибудь по другому... например, часть классов скрыть. Я видел опции сортировки для этого окна, но для моих задач они не подходят... Например, очень хочу удалить из этого окна (или запихнуть в отдельную группу) все классы подключенных исходников от SQLite, код которых мне в принципе нафиг не нужен (т.к исходники разработчиков редактировать не собираюсь), но сортировка такой возможности не дает.

Сообщение отредактировано: volod - 25.01.11, 16:00

[ElcnU]

Можно сделать статическую библиотеку, например, для sqlite. она соответственно будет отдельным проектом, подключенным к текущему.
Можно объединить классы в группу посредством пространств имен (namespace)...

[volod]

EclU, а чуть подробнее про статическую библиотеку? Когда я создавал приложение, я выставил галку "Use MFC as static library", но чувствую ты о другом сейчас говоришь....

[ElcnU]

добавь к текущему солюшену новый проект win32->static library

в этот проект перебрось нужные классы
затем подключи в главном проекте заголовочные фаилы из статической библиотеки
саму библиотеку можно подключить либо

#pragma comment(lib,"путь к .lib, который появится после компиляции статической библиотеки")

либо в свойствах главного проекта
linker->input->Additional Dependencies

[volod]

Решил вновь поднять тему, т.к. ее актуальность для меня не исчезла, а инструкции ElcnU не помогли. Что я делал: создал пустой проект (солюшен) на базе диалогового окна, добавил туда проект статической библиотеки, и к этому dll-проекту прицепил исходники SQLite. Ну и в главный проект добавил:

#include "..\\t02\\sqlite3.h"
#pragma comment(lib,"..\\debug\\t02.lib")

В результате: проект с dll компилируется нормально, а главный проект, как я понял, ругается на какие-то повторные определения функций в lib-ах. Как бороться с этой бедой, не знаю .

1>msvcrtd.lib(ti_inst.obj) : error LNK2005: "private: __thiscall type_info::type_info(class type_info const &)" (??0type_info@@AAE@ABV0@@Z) already defined in libcmtd.lib(typinfo.obj)
1>msvcrtd.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __thiscall type_info::operator=(class type_info const &)" (??4type_info@@AAEAAV0@ABV0@@Z) already defined in libcmtd.lib(typinfo.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: _strncmp already defined in libcmtd.lib(strncmp.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: __localtime64_s already defined in libcmtd.lib(loctim64.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: _malloc already defined in libcmtd.lib(dbgheap.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: _free already defined in libcmtd.lib(dbgheap.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: _realloc already defined in libcmtd.lib(dbgheap.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: _memmove already defined in libcmtd.lib(memmove.obj)
1>msvcrtd.lib(MSVCR80D.dll) : error LNK2005: _atoi already defined in libcmtd.lib(atox.obj)
1>libcmtd.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrtd.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>C:\Documents and Settings\vurri\Мои документы\Visual Studio 2005\Projects\t01\Debug\t01.exe : fatal error LNK1169: one or more multiply defined symbols found
1>Build log was saved at "file://c:\Documents and Settings\vurri\Мои документы\Visual Studio 2005\Projects\t01\t01\Debug\BuildLog.htm"
1>t01 - 10 error(s), 1 warning(s)
========== Rebuild All: 1 succeeded, 1 failed, 0 skipped ==========

На всякий случай выкладываю проект, на котором вылезли эти ошибки. Может, кто-нибудь потестит и подскажет где закрался косяк: http://files.mail.ru/PK1C2V

Сообщение отредактировано: volod - 13.02.11, 09:24

[Kray74]

1. Тебе ElcnU говорил о статической библиотеке, откуда ты dll взял?
2. Оба проекта должны испольовать одинаковые версии CRT (свойства проекта -> C/C++ -> Code generation -> Runtime library)

И строку

#pragma comment(lib,"..\\debug\\t02.lib")

лучше переписать так

#ifdef _DEBUG
#pragma comment(lib,"..\\debug\\t02.lib")
#else
#pragma comment(lib,"..\\release\\t02.lib")
#endif

[volod]

Замечания принимаю . Конечно, создается не dll, а lib-файл. После правки Runtime library наконец-то все заработало. ElcnU, Kray74 - большое спасибо! Тему пока не закрываю, есть еще вопрос.. задам чуть позже, сперва надо проверить код, чтобы исключить собственные ошибки.

[volod]

Вроде подготовился.. Короче, как я писал в самом начале, у меня в программе должно быть окно настроек, которое само по себе представляет довольно сложный объект с пятью вкладками. Логично выделить его в отдельный проект внутри солюшена. Это окно я достаточно долго разрабатывал в виде отдельного exe-проекта, которой потом хотел через тупое копировать/вставить скинуть в общую кучу классов главного проекта. Поскольку дело по разделению солюшена на проекты сдвинулось с мертвой точки, я теперь хочу интегрировать его в солюшен в виде отдельного проекта, и при этом этот проект (окно настроек) надо преобразовать в статическую библиотеку. Что я сделал:

- добавил существующий проект в решение
- в свойствах проекта изменил General -> Configuration Type -> "Application (.exe)" на "Static Library (.lib)"
- C/C++ -> Code generation -> Runtime library -> Везде Multi-threaded Debug (/MTd)

В основной проект добавил:

#include "..\\t02\\sqlite3.h"
#include "..\\t03\\test3Dlg.h"
#pragma comment(lib,"..\\debug\\t02.lib")           //либа SQLite
#pragma comment(lib,"..\\debug\\test3.lib")         //либа окна настроек

В итоге вывалились ошибки:

1>test3.lib(test3Dlg.obj) : error LNK2005: "public: __thiscall CAboutDlg::CAboutDlg(void)" (??0CAboutDlg@@QAE@XZ) already defined in t01Dlg.obj
1>test3.lib(test3Dlg.obj) : error LNK2005: "protected: virtual void __thiscall CAboutDlg::DoDataExchange(class CDataExchange *)" (?DoDataExchange@CAboutDlg@@MAEXPAVCDataExchange@@@Z) already defined in t01Dlg.obj
1>test3.lib(test3Dlg.obj) : error LNK2005: "protected: virtual struct AFX_MSGMAP const * __thiscall CAboutDlg::GetMessageMap(void)const " (?GetMessageMap@CAboutDlg@@MBEPBUAFX_MSGMAP@@XZ) already defined in t01Dlg.obj
1>test3.lib(test3Dlg.obj) : error LNK2005: "protected: static struct AFX_MSGMAP const * __stdcall CAboutDlg::GetThisMessageMap(void)" (?GetThisMessageMap@CAboutDlg@@KGPBUAFX_MSGMAP@@XZ) already defined in t01Dlg.obj
1>C:\Documents and Settings\vurri\Мои документы\Visual Studio 2005\Projects\t01\Debug\t01.exe : fatal error LNK1169: one or more multiply defined symbols found

Как я понял, это потому, что ранее окно настроек представляло из себя exe-файл и в нем остался ресурс CAboutDlg. Но почему на это ругается (не компилируется) основной проект, ведь CAboutDlg расположен в другом классе? Как можно избавиться от ошибки без удаления этого ресурса (т.к. позже это информационное окно я тоже хотел задействовать)?

И второй вопрос. Как организовать взаимодействие между разными проектами. А именно, в основном проекте у меня есть глобальная переменная, которая представляет из себя структуру со всеми настройками программы. Мне надо, чтобы при вызове окна настроек по DoModal() в OnInitDialog этого окна я как-то получил доступ к этой глобальной структуре (но определенной в другом проекте), прочитал значения ее полей и инициализировал ими создаваемое окно настроек. Конечно, можно извернуться и инициализировать значения объекта окна перед вызовом DoModal, но здесь мне принципиально нужно понять, как создаются переменные, область видимости которых - это все проекты в пределах солюшена. Тем более что все-равно в итоге все эти проекты будут собраны в один exe-шник....

Сообщение отредактировано: volod - 13.02.11, 13:37

[ElcnU]

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

по поводу 2го вопроса
можно сделать отдельный каталог, в котором будут располагаться .h с описанием глобальных структур данных/интерфейсов и эти .h будут подключать все дополнительные проекты

[volod]

Насчет общего h-файла - что-то я сглупил.... Ведь использую эти заголовки с extern-альными объявлениями переменных между классами, а подняться чуть выше и использовать их между проектами не догадался

Насчет CAboutDlg - ты прав, ElcnU, я его не удалил. Но не удалил специально, т.к. хотел использовать этот класс и в главном окне, и в окне настроек. И думал, что область видимости этих двух классов не перекрывается.. ведь когда я подключаю h-файл окна настроек, он не содержит ссылок на этот класс (весь код CAboutDlg по дефолту генерируется в cpp-файле). Каким-же тогда образом возникает конфликт? И как его обойти?... или в солюшене не должно быть классов с одинаковым названием, даже если они лежат по разным проектам?

[volod]

ElcnU был на форуме, но почему-то не ответил ... Ладно, задам тогда еще один вопрос - наверное последний в этой теме. Я засомневался в следующем: и основной проект, и проект окна настроек построены на основе mfc. Оба этих проекта я делал со статической компоновкой mfc-библиотеки.. Не значит ли это, что внутри итогового exe-шника, полученного после компляции солюшена, будет лежать двойной объем кода – ведь сперва mfc-библиотека будет статически прилинкована к статической библиотеке проекта окна настроек, а затем – уже повторно, при компиляции основного проекта солюшена. Или компилятор умнее и этого не допустит? Ну и по предыдущему вопросу тоже хотелось-бы услышать мнение профессионала

Сообщение отредактировано: volod - 13.02.11, 18:24

[mitrich]

Цитата volod @ 13.02.11, 18:23

Не значит ли это, что внутри итогового exe-шника, полученного после компляции солюшена, будет лежать двойной объем кода

Нет, т.к. при сборке статической библиотеки MFC к ней прилинкована не будет. Она будет прилинкована в момент сборки .exe вместе со статической библиотекой.
По CAboutDlg: ты уверен, что его реализация (а не интерфейс) только в одном месте присутствует? Может пропустил чего?