...или В поисках "Идеальной Библиотеки"

В до-христианскую эпоху MS-DOS велосипедистом становился практически каждый программист, неустанно преумножающий собственный набор "самых лучших/удобных/быстрых" функций, предназначенных для решения "рутинных" задач. Нередко оказывалось, что два человека, отделенных друг от друга лишь несколькими столами, увлеченно решают одну и ту же задачу — причем "раз и навсегда". Сколько почти неотличимых друг от друга векторов, стеков и списков было создано подрагивающими от возбуждения пальцами! — но какой всепоглощающий аромат романтики витал над этим...

С массовым вторжением Windows на компьютеры пользователей (и практически одновременным появлением на широкой публике первых компиляторов C++) велотрек обрел новые горизонты — появилась возможность "лучше/удобнее/быстрее" оборачивать HWND, HDC, HINSTANCE, etc. Кроме того, нужно было последний "раз и навсегда" переписать те же векторы, стеки и списки — теперь уже с использованием функций управления памятью, предоставляемых Windows API.

Однако начиная именно с этого времени, производители средств разработки стали склонять программистов к собственно езде вместо увлекательного вытачивания спиц и шестеренок филигранной работы. Появились первые версии MFC и OWL, причем, что забавно, одним из главных аргументов МС в ту пору была "скорость выполнения кода, практически не уступающая приложениям, написанным на pure C" — о сокращении объема и упорядочении исходных текстов речь шла уже во вторую очередь.

Карандашом на полях. Мне было бы очень интересно узнать, кто пустил миф о том, что "программы на C++ медленнее, чем программы на C". Нет, формально я понимаю, что тот же виртуальный вызов будет выполняться дольше (на несколько тактов) просто в силу большего количества инструкций — но я не ощущал этой разницы даже на 286-х.

Довольно быстро "оформился" новый must-have skill, которым многие на тот момент не обладали — умение доверять "сторонним" библиотекам. Если CRT еще воспринималась как нечто непреложное (хотя находились "тарзаны", которые переписывали и ее — сам таким был), то все, что "сверху" вызывало априорные подозрения в некачественности и ненадежности. "Зачем ковыряться в чужих исходниках, когда я сам могу написать лучше?" — вот он, тот самый вопрос, который денно и нощно отравлял не одну мятежную душу. Тем не меннее, процесс набирал обороты — не в последнюю очередь благодаря тому, что за хорошую езду платили лучше, чем за "самую лучшую" шестеренку.

Карандашом на полях. Как "художнику" мне обидно, как "игроку" — понятно, как "охотнику" — важна добыча, а не красивая поза при выстреле.

Очень серьезный удар по велосипедистам нанес Комитет, узаконивший в 1998-м году STL как часть языка. К сожалению (или все-таки к счастью?) Окна несколько смягчили его: стандартные (теперь уже без кавычек) контейнеры оказались (что естественно) "далеки от народа" — то есть, от Windows API. MFC, ставшая стандартом де-факто для разработки Windows-приложений, содержала собственный набор, который, с одной стороны, уже стал привычным, а с другой — мог практически без всякой головной боли использоваться с прямыми API-шными вызовами. Посмотрим на простой пример:

CString strExeName;

::GetModuleFileName(AfxGetInstanceHandle(), strExeName.GetBuffer(_MAX_PATH), _MAX_PATH);
strExeName.ReleaseBuffer();

К сожалению, написание аналогичного кода с использованием std::string потребует промежуточной переменной.

Вторая (не менее естественная) проблема STL для Windows-разработчиков — невозможность (без дополнительных ухищрений) использовать стандартные потоки ввода/вывода для чтения/записи файлов в кодировке Unicode (один из способов решения этой проблемы рассматривается в статье Upgrading an STL-based application to use Unicode).

В результате, начавший было ощутимо сужаться велотрек снова вырос до размеров вселенной и оказался усеян всякого рода гибридами, "примиряющими" тем или иным образом Windows API, MFC и C++(STL). Масла в огонь добавило и появление WTL, на ура воспринятой многочисленными велосипедистами, которым была не по нраву "монстроидальность" и "неповоротливость"("негибкость") MFC — началось "портирование" тонн MFC-шного кода в WTL, доходящее порой до абсурда (я имею ввиду попытку переноса на WTL архитектуры document/view, которая как раз и является одним из краеугольных камней "монолитности" MFC). В свою очередь, MFC-разработчики не остались в стороне — и "научились" использовать WTL-классы в своих проектах (см. статью Mix up WTL with MFC).

Казалось, что появление .NET Framework'а, в котором "есть все", позволит сосредоточиться исключительно на вращении педалей и удержании руля — ан нет, кому-то тотчас же не хватило полюбившихся пуще жизни шаблонов STL и boost'а. Мгновением позже пытливые умы решили пристегнуть невизуальную часть framework'а к уже отлаженным MFC-приложениям... действительно, почему бы и нет? — ведь это как минимум интересно.

Что-то подсказывает мне, что и 2-й framework с его generic'ами все еще не позволит нам "просто ехать"... may be, next time?.. когда мы утратим это безумное, нерациональное, но такое человеческое "я могу лучше".

"Воистину, тщеславие — мой самый любимый из грехов... он так фундаментален..." (с) "Адвокат дьявола"

Несколько замечаний.

SDB>Карандашом на полях. Мне было бы очень интересно узнать, кто пустил миф о том, что "программы на C++ медленнее, чем программы на C". Нет, формально я понимаю, что тот же виртуальный вызов будет выполняться дольше (на несколько тактов) просто в силу большего количества инструкций — но я не ощущал этой разницы даже на 286-х.

В стародавние времена, когда компиляторы C++ были весьма сырыми, это было действительно так. Но не столько из за самого C++, а из за спонтанно возникшей моды на полиморфизм везде и всюду. А так же на тенденцию к попыткам объять необъятное — казалось, что C++ этому способствует. В результате классы становились настолько толстыми и неуклюжими, что действительно возникали значительные накладные расходы. Это во-первых. Во-вторых, слабая оптимизация. Как раз на 286-х мы сделали простеший класс для комплексной арифметики. Все в соответствии с классическими канонами. Так вот, сложные выражения, переписанные один-в-один с Фортрана, работали раз в 10 медленнее, чем на самом Фортнане. Чисто из за накладных расходов на копирование. При этом, если то же самое выражение разложить на простую вещественную арифметику (застрелиться можно), то скорость выравнивалась. Спрашивется, кому он нужен такой язык, если даже комплексная арифметика на нем толком не идет
В третьих, программы на C++ были действительно медленнее, чем на C по той простой причине, что C заставляет тщательнее прорабатывать детали в силу своей более хакерской направленности и атмосферы.

Что же касается виртуальных вызовов, то это все зависит от области применения. ..."но я не ощущал этой разницы даже на 286-х" — это не значит, что ее нет. Просто не было таких задач, где она была бы заметна.

Современный же C++, с его метапрограммированием, как раз позволяет значительно лучше оптимизировать по скорости, чем старый C. Типичный пример — CRT qsort, в которой выполняются миллиарды обратных вызовов функции сравнения. Для сортировки целых чисел это становиься весьма критичным и может замедлить работу в несколько раз по сравнению с вариантом с прямыми сравнениями (извиняюсь за тавтологию). Именно поэтому, для наиболее критичных случаев, я писал свой велосипед в виде узкоспециализированной сортировки, без каких либо вызовов. Теперь у нас есть std::sort(), в которой никаких дополнительных вызовов может и не быть (но если хочется — будут).

SDB>Очень серьезный удар по велосипедистам нанес Комитет, узаконивший в 1998-м году STL как часть языка. К сожалению (или все-таки к счастью?) Окна несколько смягчили его: стандартные (теперь уже без кавычек) контейнеры оказались (что естественно) "далеки от народа" — то есть, от Windows API. MFC, ставшая стандартом де-факто для разработки Windows-приложений, содержала собственный набор, который, с одной стороны, уже стал привычным, а с другой — мог практически без всякой головной боли использоваться с прямыми API-шными вызовами.

Вот именно, что MFC — это не просто библиотека, а библиотека, заточена на конкретный низкоуровневый API. Заточенная плохо, в силу плохой совместимости низкоуровневого API и C++ в общем и целом.

SDB>Посмотрим на простой пример:

SDB>CString strExeName;

SDB>::GetModuleFileName(AfxGetInstanceHandle(), strExeName.GetBuffer(_MAX_PATH), _MAX_PATH);
SDB>strExeName.ReleaseBuffer();

SDB>К сожалению, написание аналогичного кода с использованием std::string потребует промежуточной переменной.

Ну это не аргумент. На самом деле, это лишь полумера и незначительная автоматизация. Взамен дополнительного буфера возникает необходимость вызывать какую-то невнятную ReleaseBuffer() и это все портит. Это как раз иллюстрирует проблему несовместимости C++ и низкоуровневого API — добавлена некая "примочка" к классу, вроде как стало лучше, но все равно как-то коряво. То же самое:

char buf[_MAX_PATH];
::GetModuleFileName(AfxGetInstanceHandle(), buf, _MAX_PATH);

std::string strExeName = buf;

Те же самые три строки. Но да, дополнительный буфер взамен необходимости соблюдения некого "протокола" (ведь GetBuffer/ReleaseBuffer — это уже stateful protocol).

Гораздо более серьезная проблема совместимости C++ с API — это семантика обратных вызовов без указания объекта-владельца. То самое пресловутое — как мне привязать объект класса к WindowProc. Вот уж где приходится огород городить иногда.

Кроме Windows & MFC и C++ & STL есть принципиально другие (объектно-ориентированные) операционные системы написанные на принципиально других (объектно-ориентированных) языках. Любителям велосипедного спорта еще есть где оторваться!

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

SDB>В до-христианскую эпоху MS-DOS велосипедистом становился практически каждый программист, неустанно преумножающий собственный набор "самых лучших/удобных/быстрых" функций, предназначенных для решения "рутинных" задач. Нередко оказывалось, что два человека, отделенных друг от друга лишь несколькими столами, увлеченно решают одну и ту же задачу — причем "раз и навсегда". Сколько почти неотличимых друг от друга векторов, стеков и списков было создано подрагивающими от возбуждения пальцами! — но какой всепоглощающий аромат романтики витал над этим...
Хе-хе. Проблема была не в MS-DOS. Тогда была такая штука, как Turbo Vision(практически стандарт) и куча менее известных библиотек. Много велосипедов распространялись через фидо.

SDB>С массовым вторжением Windows на компьютеры пользователей (и практически одновременным появлением на широкой публике первых компиляторов C++) велотрек обрел новые горизонты — появилась возможность "лучше/удобнее/быстрее" оборачивать HWND, HDC, HINSTANCE, etc. Кроме того, нужно было последний "раз и навсегда" переписать те же векторы, стеки и списки — теперь уже с использованием функций управления памятью, предоставляемых Windows API.
Это не есть правильно. Причина появления ясности, что велосипед — является велосипедом (а не мопедом, или самокатом) был появление и распространения Internet. То бишь средства коммуникации между разработчиками.

SDB>Карандашом на полях. Мне было бы очень интересно узнать, кто пустил миф о том, что "программы на C++ медленнее, чем программы на C". Нет, формально я понимаю, что тот же виртуальный вызов будет выполняться дольше (на несколько тактов) просто в силу большего количества инструкций — но я не ощущал этой разницы даже на 286-х.
Ага, медленее. Так и до сих пор виртуальный метод работает медленнее чем статический.


SDB>Что-то подсказывает мне, что и 2-й framework с его generic'ами все еще не позволит нам "просто ехать"... may be, next time?.. когда мы утратим это безумное, нерациональное, но такое человеческое "я могу лучше".
Можно ехать и с 1-ым framework (если не иметь ввиду именно C++). И вполне быстро. Вопрос не в этом. А нужна ли абсолютно стандартная библиотека для всех случаев?
В отношении STL (да и MFC тоже) могу сказать, что было достаточно случаев когда приходилось выцеплять ее из кода, и писать классы самостоятельно. Торможение аллокации и деаллокации, все таки никто не отменял. Поэтому, да здраствуют велосипеды с колесами предназначенными для конкретного типа дорог.

С уважением, Gleb.

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

MS>Вот именно, что MFC — это не просто библиотека, а библиотека, заточена на конкретный низкоуровневый API. Заточенная плохо, в силу плохой совместимости низкоуровневого API и C++ в общем и целом.

MS>Гораздо более серьезная проблема совместимости C++ с API — это семантика обратных вызовов без указания объекта-владельца. То самое пресловутое — как мне привязать объект класса к WindowProc. Вот уж где приходится огород городить иногда.

1) Про колбеки.
В WndProc передаётся хэндл окна, а по нему получить ассоциированные пользовательские данные... есть по меньшей мере 3 способа, из которых 2 — чисто винапишные.
— завести в программе таблицу: хэнл — объект
— GetWindowLong(GWL_USERDATA) (правда, с некоторым риском, что это поле использует кто-то ещё)
— GetProp()
В принципе, решив эту задачу в общем виде один раз (например, воспользовавшись готовой библиотекой надстройки), можно к ней не возвращаться.

2) Про совместимость.
Низкоуровневый фреймворк проектируется так, чтобы его можно было использовать с минимальными надстройками со стороны клиента. (Представьте себе, если ради вызова MessageBox придётся писать собственный DlgProc, а то и WndProc).
Поэтому С++ные надстройки — это, в первую очередь, прокси к уже имеющимся деталькам.
Это значит, что в программе одновременно живут пары (хорошо, если пары) объектов — в подвале и в надстройке. Те же окна — одно в GUI, доступное по HWND, а второе CWnd / TWindow и т.п.
Кроме того, если надстройка не заточена под конкретный подвал (например, кроссплатформенная — Zinc, или просто "так удобнее" — VCL), то она вынуждена повторять реализацию структуры подвала — и опять же, необязательно один в один.
Пример перед глазами:
MFC дружит с WinAPI — и навигация по окнам (CWnd::GetNext(), CWnd::GetParent()...) использует апишные функции.
А Zinc не дружит ни с кем — в результате каждый оконный объект держит коллекцию своих дочерних объектов. В том числе — неклиентских (шапка, рамка, скроллбары, кнопки мин/макс...). И вынужден отслеживать соответствие собственной модели с платформой.
Гарантии целостности такой системы — высечены мечом... по песку.
И это не заслуга именно С++ — подобная засада заложена в любой попытке сделать адаптер к чему-то достаточно навороченному.

К>Гарантии целостности такой системы — высечены мечом... по песку.
К>И это не заслуга именно С++ — подобная засада заложена в любой попытке сделать адаптер к чему-то достаточно навороченному.

Зато все на виду ! Все что не работает можно исправить , этим ксатти во многом велосипеды и привлекают. Для починки крутого мотоцикла с пломюой нужна мастерская с мастерами. А починить велосипед легче , там деталей меньше и устройствоо понятнее.

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

К>Пример перед глазами:
К>MFC дружит с WinAPI — и навигация по окнам (CWnd::GetNext(), CWnd::GetParent()...) использует апишные функции.
К>А Zinc не дружит ни с кем — в результате каждый оконный объект держит коллекцию своих дочерних объектов. В том числе — неклиентских (шапка, рамка, скроллбары, кнопки мин/макс...). И вынужден отслеживать соответствие собственной модели с платформой.
К>Гарантии целостности такой системы — высечены мечом... по песку.
К>И это не заслуга именно С++ — подобная засада заложена в любой попытке сделать адаптер к чему-то достаточно навороченному.
Если честно, то по-моему, эта засада от лени. В том смысле, что аккуратно написанный адаптер не будет содержать параллельную функциональность. Адаптер окна, к примеру, должен быть устроен так, чтобы при перечислении дочерних объектов он выдавал не дубликаты детей, а адаптеров к настоящим детям. В частности, енумерирование дочерних окон поверх win32 должно пользоваться функциями Win32, а не ползать по собственному списку, который еще и надо синхронизовать с оригиналом.

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

S>Если честно, то по-моему, эта засада от лени. В том смысле, что аккуратно написанный адаптер не будет содержать параллельную функциональность. Адаптер окна, к примеру, должен быть устроен так, чтобы при перечислении дочерних объектов он выдавал не дубликаты детей, а адаптеров к настоящим детям. В частности, енумерирование дочерних окон поверх win32 должно пользоваться функциями Win32, а не ползать по собственному списку, который еще и надо синхронизовать с оригиналом.
Лень, не лень, но. Все замечательно, пока не появляются визуальные объекты не имеющего HWND. Вот тогда, самое веселье с навигацией и сообщениями и начинается.

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:
GZ>Лень, не лень, но. Все замечательно, пока не появляются визуальные объекты не имеющего HWND. Вот тогда, самое веселье с навигацией и сообщениями и начинается.
Ну... Вопрос отктрытый. С точки зрения теории кристалла, все достигается при помощи интерфейсов. Ну то есть базовая модель окна ничего про нижележащий слой не знает. Интерфейсы предоставляют полезную с точки зрения модели информацию. А вот под винду адаптер окна реализует помимо IWindow еще и IWin32Window. И для некоторых окон под виндой свойство IWindow.HScrollbar отдает объект, реализующий IWin32Window помимо IScrollBar.
Тогда при желании пользователь может попытаться откастить скролл к IWin32Window, получить у него Handle и тогда уже сделать что-то специфичное.

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

SDB>Что-то подсказывает мне, что и 2-й framework с его generic'ами все еще не позволит нам "просто ехать"... may be, next time?.. когда мы утратим это безумное, нерациональное, но такое человеческое "я могу лучше".

SDB>"Воистину, тщеславие — мой самый любимый из грехов... он так фундаментален..." (с) "Адвокат дьявола"

Наверное немного не в тему, но, имхо, любой велосипед -- это не сложившийся мейнстрим.

Кроме того, поскольку любой мейнстрим всегда кого-то почему-то не устраивает, то велосипеды будут изобретать. И кем-то некоторые и велосипедов будут востребованны. И преобразованны в мейнстрим.

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

S>Здравствуйте, GlebZ, Вы писали:
GZ>>Лень, не лень, но. Все замечательно, пока не появляются визуальные объекты не имеющего HWND. Вот тогда, самое веселье с навигацией и сообщениями и начинается.
S>Ну... Вопрос отктрытый. С точки зрения теории кристалла, все достигается при помощи интерфейсов. Ну то есть базовая модель окна ничего про нижележащий слой не знает. Интерфейсы предоставляют полезную с точки зрения модели информацию. А вот под винду адаптер окна реализует помимо IWindow еще и IWin32Window. И для некоторых окон под виндой свойство IWindow.HScrollbar отдает объект, реализующий IWin32Window помимо IScrollBar.
S>Тогда при желании пользователь может попытаться откастить скролл к IWin32Window, получить у него Handle и тогда уже сделать что-то специфичное.

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

Получается, что экземпляр объекта (или интерфейса) в надстройке соответствует не одному объекту базиса, а от нуля до бог знает скольки объектов сразу.
Пересоздавать объекты надстройки по мере надобности не всегда возможно: некоторые из них имеют состояние (не выводимое из состояния базиса). Создать-прибить прокси-объект означает потерять состояние.
В общем, темна вода в облацех

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

К>1) Про колбеки.
К>В WndProc передаётся хэндл окна, а по нему получить ассоциированные пользовательские данные... есть по меньшей мере 3 способа, из которых 2 — чисто винапишные.
К>- завести в программе таблицу: хэнл — объект
К>- GetWindowLong(GWL_USERDATA) (правда, с некоторым риском, что это поле использует кто-то ещё)
К>- GetProp()
К>В принципе, решив эту задачу в общем виде один раз (например, воспользовавшись готовой библиотекой надстройки), можно к ней не возвращаться.

Знаю. Это я привел лишь как навязший в зубах пример. Я говорил о том, что C++ так или иначе способствует использованию объектной парадигмы. А системные API (не обязательно WinAPI) разрабатывались в старинном процедурном стиле. Взять, например, тот же signal() из POSIX. Или виндовую SetTimer(NULL,...), или те же qsort(), bsearch() — хоть это и не OS API, но смысл тот же, а именно — нет никакого способа передать туда this, чтобы вызовы были привязаны не просто к некой функции, а к функции с объектом, то есть, c this. Но проблема глубже. Даже если у нас и есть такой штатный механизм (как в BerkleyDB, например), все равно на C++ налагаются ограничения. Что произойдет, если внутри функции обратного вызова произойдет C++ное исключение? В каких-то частных случаях можно расчитывать, что все будет в порядке. Но общего гарантированного механизма нет и быть не может, поскольку нельзя расчитывать, на то, что все это пройдет через все кишки OS.

И ноги здесь растут именно из этого притиворечия — старого процедурного стиля OS API и некой новой парадигмы, о которой этот "старый стиль" ничего не знает.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Кроме Windows & MFC и C++ & STL есть принципиально другие (объектно-ориентированные) операционные системы написанные на принципиально других (объектно-ориентированных) языках. Любителям велосипедного спорта еще есть где оторваться!

Спрашивается: Причём здесь Оберон?

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

[...]
К>Кроме того, если надстройка не заточена под конкретный подвал (например, кроссплатформенная — Zinc, или просто "так удобнее" — VCL), то она вынуждена повторять реализацию структуры подвала — и опять же, необязательно один в один.
[...]

А в чем засада в VCL? Я так понимаю, что VCL — обертка (прокси, в терминологии темы), а никак не надстройка над pure API. Поэтому ее использование если и имеет какой-то процент накладных расходов, то, в настоящее время, некритичный. ПМСМ. Поправьте ламера, если неправ.

PS: за "почти" оффтоп — большой пардон.

Здравствуйте, DevXarT, Вы писали:
DXT>А в чем засада в VCL? Я так понимаю, что VCL — обертка (прокси, в терминологии темы), а никак не надстройка над pure API.
Неверно ты понимаешь.

UTSL %Program Files%\Borland\Delphi\x.0\source\vcl\*.*

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

OM>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Кроме Windows & MFC и C++ & STL есть принципиально другие (объектно-ориентированные) операционные системы написанные на принципиально других (объектно-ориентированных) языках. Любителям велосипедного спорта еще есть где оторваться!

OM> Спрашивается: Причём здесь Оберон?

Ни при чём Жаль, что BeOS загнулась...

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

SDB>Что-то подсказывает мне, что и 2-й framework с его generic'ами все еще не позволит нам "просто ехать"... may be, next time?.. когда мы утратим это безумное, нерациональное, но такое человеческое "я могу лучше".

как насчет этой статьи?
http://www.joelonsoftware.com/articles/fog0000000069.html

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

Д>как насчет этой статьи?
Д>http://www.joelonsoftware.com/articles/fog0000000069.html

Pre Scriptum: будучи категорическим противником привнесения удаффкомовской "эстетики" на RSDN, с трудом удержался от шаловливого ответа "слишком много букаф, ниасилил" — вот они, извилины мышленья... наверно, Motorhead действует...

Статью прочел с интересом, спасибо за ссылку. Я тексты Джоэля почитываю периодически, но этот как-то пропустил ко стыду своему.

Надеюсь, что Вы не считаете меня плагиатором — потому как, во-первых, я эту статью раньше не читал, а во-вторых — мы с ним смотрим на несколько разные вещи с несколько разных сторон. Он в данном контексте "физик", а я — "лирик". Он прагматично говорит о пагубности принципа "я могу лучше", а я — "сострадательно" рассуждаю об истории его возникновения и развития. Кроме того, создание велосипедов и переписывание с нуля code-base давно существующего и продаваемого продукта — это все-таки несколько разные вещи, правда?

Что мне понравилось безоговорочно:

It's harder to read code than to write it.

И вот это (просто блеск!):

Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive.

Замечательный аргумент в пользу того, "Почему я до сих пор пишу на MFC

Автор: SchweinDeBurg
Дата: 11.12.04

".

Post Scriptum: корневой пост был своего рода сублимацией... мне опять захотелось написать свою "идеальную библиотеку"...

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

MS>Несколько замечаний.

Благодарю, выслушиваю со вниманием.

MS>В третьих, программы на C++ были действительно медленнее, чем на C по той простой причине, что C заставляет тщательнее прорабатывать детали в силу своей более хакерской направленности и атмосферы.

Гх-м-м... задумался... а мне всегда казалось, что плюсы заставляют "тщательнее прорабатывать детали" — потому что цена ошибки в ОО-дизайне существенно выше.

MS>Вот именно, что MFC — это не просто библиотека, а библиотека, заточена на конкретный низкоуровневый API. Заточенная плохо, в силу плохой совместимости низкоуровневого API и C++ в общем и целом.
MS>Те же самые три строки. Но да, дополнительный буфер взамен необходимости соблюдения некого "протокола" (ведь GetBuffer/ReleaseBuffer — это уже stateful protocol).

ИМХО здесь мы приходим к очень популярному вопросу: "что важнее — академическая красота библиотеки или ее реюзабельность/эффективность?" Я ставлю на второе... особенно на реюзабельность.

MS>То самое пресловутое — как мне привязать объект класса к WindowProc. Вот уж где приходится огород городить иногда.

Согласен с выделенным. Но "всегда есть выбор" — мы можем либо пойти штатными путями (WM_CREATE/WM_NCCREATE + lParam), либо воспользоваться хаками (а-ля ATL'ные thunk'и), упрятанными глубоко "внутрь". Это все то же "что важнее..." Ответ каждый дает сам.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Кроме Windows & MFC и C++ & STL есть принципиально другие (объектно-ориентированные) операционные системы написанные на принципиально других (объектно-ориентированных) языках. Любителям велосипедного спорта еще есть где оторваться!

Сергей, "патриотизм — религия бешеных" (с) Вальтер Скотт. Я искренне считаю Паскаль (и П-подобные языки) идеальной стартовой площадкой для обучения программированию — но промышленные разработки надо вести на чем-то менее "экзотичном". Опираясь на свой небогатый 10-летний опыт промышленного программирования, я бы предложил "цепочку" (Object) Pascal -> C/C++ -> C#/Java. Первое прививает ОО, второе — учит деталям, третье — помогает сосредоточиться на цели.

P.S.
А я все равно на плюсах буду писать — потому что люблю!