Компилятор: Visual Studio .NET 2003 (Framework v1.1)
ОС: Microsoft Windows XP Pro SP1
====================================================

Здравствуйте,

1 наконец созрел для настоящего проэкта Вот только теперь рё-
брышком встал вопрос: я пишу на С++, лучше писать с использо-
ванием MFC или просто так, API-шками?

2 насколько я понял, есть "локальные" классы и методы (MFC) и
"глобальные" (API). Такой вопрос: а к каким из них относится
Framework?

3 судя по тому что писал Стивен Прата в книге "Язык программи-
рования С++", неиспользуемые классы/функции просто не компи-
лируются в окончательный продукт. Отсюда вывод: т.к. exe-шники
из 240 Кб лихо ZIP'ятся в 125 Кб (MFC, когда я использую не
больше 2-3 классов), то я упускаю какую-то опцию или что-то
вроди этого, подскажите пожалуйста...

Заранее спасибо.

Здравствуйте, RealSQUALL, Вы писали:

RSQ>1 наконец созрел для настоящего проэкта Вот только теперь рё-
RSQ> брышком встал вопрос: я пишу на С++, лучше писать с использо-
RSQ> ванием MFC или просто так, API-шками?

Для начала — уточним, что API — это application programming interface, то есть интерфейс прикладных программ "вообще".
На жаргоне этим словом чаще всего обозначают Windows API, или WinAPI.
Ну это я так, к букве прикопался.
Кстати говоря, VC обеспечивает, помимо WinAPI, ещё и POSIX (частично).

Настоящий проект нужно делать с использованием хорошего фреймворка — "магазина велосипедов" , даже не магазина, а супермаркета и велотрека.
MFC, хотя и не самая лучшая библиотека, но в паре с VC — неплохой выбор. (Отчасти потому, что с другими фреймворками на VC работать труднее).

RSQ>2 насколько я понял, есть "локальные" классы и методы (MFC) и
RSQ> "глобальные" (API). Такой вопрос: а к каким из них относится
RSQ> Framework?

WinAPI — это набор не классов и методов, а просто функций. Да и другие API — часто тоже. Это позволяет писать прикладные программы на разных языках, в том числе низкого уровня, и не привязываться к объектной модели того или иного языка.
Помимо "базового", у Windows есть множество API построенных на OLE/COM/DCOM. Например, DirectX, Shell, Scripting.

Фреймворк — это надстройка над API, обеспечивающая среду, удобную для программиста. Например, MFC не только определяет классы для работы с окнами, объектами ядра и графики — но ещё и создаёт среду их существования (внутренние структуры данных), а также интегрируется в инструмент разработки — VisualStudio.

RSQ>3 судя по тому что писал Стивен Прата в книге "Язык программи-
RSQ> рования С++", неиспользуемые классы/функции просто не компи-
RSQ> лируются в окончательный продукт. Отсюда вывод: т.к. exe-шники
RSQ> из 240 Кб лихо ZIP'ятся в 125 Кб (MFC, когда я использую не
RSQ> больше 2-3 классов), то я упускаю какую-то опцию или что-то
RSQ> вроди этого, подскажите пожалуйста...

Куда деваются неиспользуемые классы и функции — это сильно зависит от того, как была собрана библиотека.
Если каждая экспортируемая функция, переменная, таблица виртуальных методов помещена в отдельный объектный файл — то линковщик при сборке программы оставит только то, что попрошено.
Если в одном объектном файле (полученном из компилируемого исходного файла) много экспортируемых функций — то достаточно использовать любую из них, чтобы в собранной программе оказались все.
Наконец, если библиотека собрана как DLL, то программа будет грузить её целиком; в файле программы будет лишь таблица импорта.

Исполняемые программы неплохо сжимаются, но не из-за MFC или чего-то другого. Результат компиляции ассемблерного текста (если, конечно, не приложить специальных усилий против архиватора) тоже сожмётся.
Конечно, чем больше сторонних библиотек использует программа, тем больше размер таблиц импорта и таблиц перемещений в файле .exe, что играет на руку архиватору.

Кодт wrote:

> Куда деваются неиспользуемые классы и функции — это сильно зависит от того, как была собрана библиотека.
> Если каждая экспортируемая функция, переменная, таблица виртуальных методов помещена в отдельный объектный файл — то линковщик при сборке программы оставит только то, что попрошено.
> Если в одном объектном файле (полученном из компилируемого исходного файла) много экспортируемых функций — то достаточно использовать любую из них, чтобы в собранной программе оказались все.

В общем случае это не так.

По-умолчанию, только в отладочном режиме не устраняются неиспользуемые ф-ции (опция линкера OPT:REF).

P.S. Кроме того, при включенной опции OPT:ICF (включена в релизе по-умолчанию), линкер "сворачивает" бинарно идентичные ф-ции, что, в частности, предотвращает code bloat, появляющийся при инстанциации одного и того же шаблона разными типами (т.е. vector<int> будет использовать то же самый код, что и vector<long>).

--
Maxim Yegorushkin

Здравствуйте, MaximE, Вы писали:

ME>По-умолчанию, только в отладочном режиме не устраняются неиспользуемые ф-ции (опция линкера OPT:REF).

Добавлю, что для использования OPT:REF нужно еще применить ключ компилятора /Gy (Enable Function-Level Linking).

Здравствуйте, RealSQUALL, Вы писали:

RSQ>1 наконец созрел для настоящего проэкта Вот только теперь рё-
RSQ> брышком встал вопрос: я пишу на С++, лучше писать с использо-
RSQ> ванием MFC или просто так, API-шками?

Я сейчас делаю то же самое, поэтому могу посоветовать только одно — использовать только самую новую VS с новым MFC (мне сейчас приходится использовать VS 6, и от ее глюков уже достаточно устал)... И использовать по-возможности очень осторожно MFC — я для надежности ко многим WinAPI-функциям просто написал wrapper-ы с использованием STL-их типов, а от MFC-х функций и классов отказался. Также не забудьте про другие библиотеки — типа того же boost-а. А от MFC в моем проекте только остался каркас обработки сообщений. Также могу посоветовать приглядется к другим GUI-библиотекам, скажем мои коллеги вполне успешно используют QT для разработки.

Здравствуйте, RealSQUALL, Вы писали:

Есть более страшное слово — WTL

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Здравствуйте, MaximE, Вы писали:

ME>>По-умолчанию, только в отладочном режиме не устраняются неиспользуемые ф-ции (опция линкера OPT:REF).

SDB>Добавлю, что для использования OPT:REF нужно еще применить ключ компилятора /Gy (Enable Function-Level Linking).

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

Хммм... насколько я понял:
— MFC входит в Framework
— MFC нужен только для понта, а не для серьёзных проектов
— ниже уровня (или на уровне) WinAPI ничего нет

Здравствуйте, RealSQUALL, Вы писали:

RSQ> — MFC входит в Framework
MFC — это и есть framework ("каркас" для разработки приложений). Такой же, как wxWindows, Qt, WTL, etc. К .NET Framework никакого отношения не имеет.

RSQ> — MFC нужен только для понта, а не для серьёзных проектов
ИМХО — бред. Прошу прощения за резкость, конечно. Система интернет-трейдинга — это серьезный проект в Вашем понимании?

RSQ> — ниже уровня (или на уровне) WinAPI ничего нет
Да.

RSQ> — MFC нужен только для понта, а не для серьёзных проектов

Вот как раз понтов в MFC никаких нет — вышла она из моды Но проекты делать можно.

Здравствуйте, SchweinDeBurg, Вы писали:

SDB>Система интернет-трейдинга
Если честно, не задумывался о таком, но идею насчёт MFC понял...

Здравствуйте, Nuald, Вы писали:

N>Я сейчас делаю то же самое, поэтому могу посоветовать только одно — использовать только самую новую VS с новым MFC (мне сейчас приходится использовать VS 6, и от ее глюков уже достаточно устал)... И использовать по-возможности очень осторожно MFC — я для надежности ко многим WinAPI-функциям просто написал wrapper-ы с использованием STL-их типов, а от MFC-х функций и классов отказался. Также не забудьте про другие библиотеки — типа того же boost-а. А от MFC в моем проекте только остался каркас обработки сообщений. Также могу посоветовать приглядется к другим GUI-библиотекам, скажем мои коллеги вполне успешно используют QT для разработки.

Подключать к проекту MFC и при этом практически ее не использовать — это мне сильно напоминает известный анекдот "Как я обманул кондуктора — взял билет и не поехал"

Здравствуйте, Odi$$ey, Вы писали:

...

OE>Подключать к проекту MFC и при этом практически ее не использовать — это мне сильно напоминает известный анекдот "Как я обманул кондуктора — взял билет и не поехал"

Но использовать CArray точно не стоит. Как было приятно обнаружить следующую строчку в CArray<>::SetSize :

        // copy new data from old
        memcpy(pNewData, m_pData, m_nSize * sizeof(TYPE));

вот так просто, "copy new data from old". Действительно, к чему вызывать конструкторы/деструкторы, только время тратить.

Здравствуйте, RealSQUALL, Вы писали:

RSQ> — ниже уровня (или на уровне) WinAPI ничего нет

В принципе, можно все делать и на уровне WinAPI — ничего страшного в этом нет. Это конечно будет непросто, но не так уж и сложно. Но когда вы будете делать даже простейший скролл-бар на WinAPI, то вы поймете, что такое настоящий геморрой — у нас для этого понадобилось не меньше 100-200 строчек кода (прокрутка окна, изменение самой позиции скроллбара, обеспечение захвата мышкой, обработка плавных и быстрых скачков, работа со скроллером мыши)
Так что можете посмотреть Рихтера "Программирование Windows 2000 для профессионалов" (или что-то в этом роде), посмотреть на примеры кодов, которые он там приводит, и сами приходите к нужному выводу.

А>Но использовать CArray точно не стоит. Как было приятно обнаружить следующую строчку в CArray<>::SetSize :
А>

А>        // copy new data from old
А>        memcpy(pNewData, m_pData, m_nSize * sizeof(TYPE));
А>

А>вот так просто, "copy new data from old". Действительно, к чему вызывать конструкторы/деструкторы, только время тратить.

В CArray есть, конечно, недостатки (например возврат объекта вместо ссылки на него), но IMHO не стоит считать разработчиков идиотами до такой степени.