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

В до-христианскую эпоху 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.
А я все равно на плюсах буду писать — потому что люблю!

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

GZ>Хе-хе. Проблема была не в MS-DOS. Тогда была такая штука, как Turbo Vision(практически стандарт) и куча менее известных библиотек. Много велосипедов распространялись через фидо.

Я использовал слово "MS-DOS" исключительно в хронологических целях.

GZ>Ага, медленее. Так и до сих пор виртуальный метод работает медленнее чем статический.

Угу, на пару-тройку тактов камня.

GZ>А нужна ли абсолютно стандартная библиотека для всех случаев?

Нужна. Но невозможна.

GZ>да здраствуют велосипеды с колесами предназначенными для конкретного типа дорог.

Угу... но хотелось бы по-нашему, по-сишному обойтись typedef'ом нового типа дороги.

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

С неменьшим, "Schwein — потому что свинья, а DeBurg — чтобы звучало благородно" (с) автор ника.

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

E>любой велосипед -- это не сложившийся мейнстрим.

Не-а, велосипед — это попытка в мэйнстриме уплыть "быстрее, дальше, лучше".

SchweinDeBurg,

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

Нам удавы не нужны. Черпаем цитаты из классики кинематографа: "Слишком много нот"

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

ПК>Нам удавы не нужны.

Тебе хорошо "оттуда" говорить, а у нас что ни день — либо "выпей йаду", либо "жжош".

ПК>Черпаем цитаты из классики кинематографа: "Слишком много нот"

Сорьки за серость — а это откуда именно? Я, вроде как, "наше старое кино" очень люблю, а такой фразы не припоминаю.

SchweinDeBurg,

> ПК> Нам удавы не нужны.
>
> Тебе хорошо "оттуда" говорить, а у нас что ни день — либо "выпей йаду", либо "жжош".



> ПК> Черпаем цитаты из классики кинематографа: "Слишком много нот"
>
> Сорьки за серость — а это откуда именно? Я, вроде как, "наше старое кино" очень люблю, а такой фразы не припоминаю.

Это известный анекдот о Фердинанде и Моцарте. В кинематографе присутствует, например, в "Амадеусе" Милоша Формана.

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

ПК>Это известный анекдот о Фердинанде и Моцарте. В кинематографе присутствует, например, в "Амадеусе" Милоша Формана.

ОК, завтра (то есть, уже сегодня) попробую купить и засмотреть.

[весенне-шаловливый оффтоп]
А там Металлику будут играть?
[/весенне-шаловливый оффтоп]

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

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

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

С другой стороны, нередко возня с "гнилым" кодом или бинарными компонентами пожирает времени в разы больше, чем заняла бы разработка своего собственного функционала

Да и рефакторинг — тоже далеко не панацея. Нередко бывает проще и быстрее сделать для продукта новый "скелет" с нуля, а потом понемногу прикрутить к нему части функционала от старого продукта — своего рода компромиссный вариант между полным переписыванием и рефакторингом.

Есть еще и вот эта статья:
http://www.joelonsoftware.com/articles/fog0000000007.html
Написание своего собственного компилятора для разработки единичного продукта — это конечно круто

Так что.... решить — какой код использовать, а где нужно сделать свой велосипед — тоже немаловажная часть управления проектом. Вот только без магического шара и бубна здесь очень трудно обойтись

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

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

E>>любой велосипед -- это не сложившийся мейнстрим.

SDB>Не-а, велосипед — это попытка в мэйнстриме уплыть "быстрее, дальше, лучше".

Симпатичная точка зрения, но я ее не разделяю. Когда Денис Ричи и Кен Томпсон в недрах ATT в тихоря делали Unix разве они были в мейнстриме? Или проект Oak внутри Sun (если мне не отшибает память, именно из него выросла Java) был частью мейнстрима? Или Тим Бернс Ли разрабатывал HTML и основы Web как часть мейнстрима? Имхо, все это были удавшиеся велосипеды. А сколько было неудавшихся...

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

Д>Написание своего собственного компилятора для разработки единичного продукта — это конечно круто

а вдобавок можно еще и операционку написать , претенденты уже есть: OLGA (Oberon Language Goes Airborne) компилятор для процессора StrongARM + система реального времени. И все это для единичного продукта — софтина управляющая беспилотным вертолетом.

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

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

Тяжела и неказаста, жизнь у UNIX-программиста.

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

СГ>а вдобавок можно еще и операционку написать , претенденты уже есть: OLGA (Oberon Language Goes Airborne) компилятор для процессора StrongARM + система реального времени. И все это для единичного продукта — софтина управляющая беспилотным вертолетом.

Иногда это дает плюсы. И конечно, очень подогревает самооценку Но все равно, это — тупиковый путь.

СГ> OLGA (Oberon Language Goes Airborne)

P. S.

На сайте info21 выложено его описание:

http://www.inr.ac.ru/~info21/pdf/Oberon-SA-Report285.pdf

(всего 7 страниц)

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

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

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

E>>>любой велосипед -- это не сложившийся мейнстрим.

SDB>>Не-а, велосипед — это попытка в мэйнстриме уплыть "быстрее, дальше, лучше".

E>Симпатичная точка зрения, но я ее не разделяю. Когда Денис Ричи и Кен Томпсон в недрах ATT в тихоря делали Unix разве они были в мейнстриме? Или проект Oak внутри Sun (если мне не отшибает память, именно из него выросла Java) был частью мейнстрима? Или Тим Бернс Ли разрабатывал HTML и основы Web как часть мейнстрима? Имхо, все это были удавшиеся велосипеды. А сколько было неудавшихся...


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

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

OM>Мне кажется, что главное не то, изобретают ли велосипед или же следуют мейнстриму, а то, делается ли это продуманно и осознанно или же это бездумное действо. По-моему мейнстримщики, которые пытаются использовать свой инструментарий там, где он явно не работает, ничем не лучше тех, кто ваяет велосипед по любому поводу. В обоих случаях результат получится явно не тот, что должен был бы...

Имхо, здесь все не так просто. Не помню у кого из классиков (кажется у Страуструпа) прочитал хорошую мысль о том, что если кто-то сделал удачную программу, то пользователи начную ее применять даже так, как автор и не предполагал. Видимо, человеку свойственно сводить к минимуму количество различных факторов, не любим мы многофакторных задач (можно вспомнить хотя бы, как в школе системы уравнений с двумя неизвестными учат сводить к уравнению с одной переменной и т.д.).

А уж если речь заходит об универсальных языках или платформах (C++, Java, .Net/C#), то тут есть вообще очень большой соблазн применять один и тот же инструмент для решения всех задач. Каюсь, сам грешен в том, чтобы все писать на C++. И в моем случае дело прежде всего в том, что я не могу знать все. Вот C++ я знаю достаточно хорошо, чтобы комфортно на нем работать, не страдать от memory-leak-ов, повисших указателей, выходы за пределы массивов и т.д. Для того, чтобы в достаточно хорошей степени освоить Java мне потребуются значительные затраты времени. Причем не столько на сам язык, сколько на технологии вокруг него. А если к этому добавить еще и .NET/C#, то времени нужно еще больше. Но кроме изучения нового приходится заниматься текущими задачами. Которые так же могут требовать изучения больших объемов информации, причем, как правило, за короткий срок. Да и сам C++ не стоит на месте. Чтобы быть в курсе современных течений вокруг шаблонов и метапрограммирования так же требуются усилия.

В результате получается, что мне проще решать большинство задач именно на C++, даже если где-то как-то кому-то он что-то проигрывает. Ну потрачу я несколько лишних дней на отладку. Зато могу выиграть на сопровождении (т.к. все в одном стиле и подходе). Или в том, что мой код в мое отсутствие спокойно сможет доработать другой участник команды, знающий С++. А я, в свою очередь, смогу сопровождать любой другой код на C++, если все задачи решаются только на C++. И нет зоопарка из C++/Java/C#/Delphi/Perl/PHP фрагментиков, программок и подсистемок.

Если заменить в вышесказанном C++ на Java или C#, то, имхо, все останется актуальным. Если сложилась команда, каждый член которой в достаточной степени владеет одним и тем же инструментом, и только этот инструмент используется, то затраты на сопровождение/развитие сильно сокращаются (во многом благодоря взаимозаменяемости членов команды).

Именно отсюда и желание применять направо и налево то, что хорошо знаешь (а лучше когда в совершенстве владеешь). И только когда оказывается, что процесс как-то туго идет, начинают оглядываться по сторонам и искать альтернативы (опять собственный опыт). А вот если достойных альтернатив нет, то здесь есть шанс для велосипедов и велосипедиков. Например, XML-RPC вместо SOAP или PHP вместо JSP (хотя примеры, возможно не самые удачные).

DWinLib — A minimal Windows API wrapper

A minimal Windows API wrapper with simplified child control handling, a flicker-free docking window framework and some extra goodies.

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

Полностью согласен.
И готов подписаться под каждым словом.
Правда отмечу, что C++ — плохой пример. До сих пор это был единственный язык (не считая более простого C или пока слишком нового и малораспространённого D), который охватывал практически ВЕСЬ спектр задач по программированию. Особенно, если принять во внимание возможность использования встроенного ассеблера. Причём, что интересно, для большинства областей по отдельности существует множество других языков, более эффективных в данной конкретной области. Но такой выскоой средней эффективности (т.е. эффективности не только в этой, но и в остальных областях), как C++ не один другой язык не имеет. Это залог долголетия и процветания C++ и его развития.
Команда, в совершенстве знающая C++ в настоящее время в состоянии эффекктивно решить практически любую задачу. Хотя во многих областях она решит её медленее и с большими затратами, чем это сделает команда в совершенстве владеющая более эффективным для данных областей инструментарием. Например вполне очевидно, что, как правило, бизнес-софт эффективнее писать на Java или C#, чем на C++. Но так же очевидно, что расчёты лучше делать на C++, а то и на C.
Но не это главное. Главное же — в том, что для настоящих профи именно естественные ограничения по времени и ресурсам являются причиной, мешающей осваивать новые инструменты, что вы и упомянули. Если же фактором, которые ограничивает освоение или примение технологий или иснтрументов становится религиозная догма — будь то изобретение велосипедов или же наоборот — следование mainstream — то такого человека врядли можно считать профи. И именно в силу тех искуственных ограничений, которые он сам накладывает на своё развитие.

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

OM>Если же фактором, которые ограничивает освоение или примение технологий или иснтрументов становится религиозная догма — будь то изобретение велосипедов или же наоборот — следование mainstream — то такого человека врядли можно считать профи.

В отношении Java у меня до сих пор религиозное (воинственно религиозное если быть точным) неприятие. Был у меня короткий период программирования на Java -- сбежал обратно в C++ при первой же возможности. Теперь всячески противлюсь попыткам навязывания мне Java, причем во многом по субъективным причинам. Так что профи меня уже считать нельзя

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

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

OM>>Если же фактором, которые ограничивает освоение или примение технологий или иснтрументов становится религиозная догма — будь то изобретение велосипедов или же наоборот — следование mainstream — то такого человека врядли можно считать профи.

E>В отношении Java у меня до сих пор религиозное (воинственно религиозное если быть точным) неприятие. Был у меня короткий период программирования на Java -- сбежал обратно в C++ при первой же возможности. Теперь всячески противлюсь попыткам навязывания мне Java, причем во многом по субъективным причинам. Так что профи меня уже считать нельзя

Аналогично... Самое смешное в том, что несмотря на инстинктивное неприятие Java, мне приходится заниматься именно им...
А по сути совершенно верно, у большинства людей есть какие то предпочтения или антипатии, основанные на совершенно субъективных факторах. Взять того же Vlad'а, с его фанатическим отстаиванием C#, даже тогда, когда это уже смешно. Потому в своё время говорили, что принятие новых идей в науке — это 25-30 лет. Т.е. столько, сколько нужно для того, что бы молодое поколение вытеснило старое. Думаю тоже самое мы наблюдаем и в программировании. Однако среди общей массы всегда выделялись люди способные к вдумчивому и спокойному восприятию новых идей, а так же те, кто способен продвинуть идею до её практического воплощения. И если идея удачна, воплощение эффективно, а потребность в тех выгодах, что она даёт есть у многих — эта идея становится mainstream.
Однако, поскольку задача очень многофакторная и многое вообще предусмотреть сложно, то сказать, что станет mainstream, а что нет — весьма затруднительно.
Легче сказать что уж наверняка является велосипедом.

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

OM>Взять того же Vlad'а, с его фанатическим отстаиванием C#, даже тогда, когда это уже смешно.

Зря ты это сказал...

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

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

OM>>Взять того же Vlad'а, с его фанатическим отстаиванием C#, даже тогда, когда это уже смешно.

E>Зря ты это сказал...
E>

Несанкционированный вызов кадавра пятого уровня?

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

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

Угу. на вот тебе ишшо:
http://rsdn.ru/Forum/Message.aspx?mid=1171775&only=1

Автор: c-smile
Дата: 15.05.05

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

OM> или пока слишком нового и малораспространённого D

поезд давно уже ушел... он так и останется новым и малораспространенным, постепенно становясь старым и малораспространенным

OM> который охватывал практически ВЕСЬ спектр задач по программированию. Особенно, если принять во внимание возможность использования встроенного ассеблера. Причём, что интересно, для большинства областей по отдельности существует множество других языков, более эффективных в данной конкретной области. Но такой выскоой средней эффективности (т.е. эффективности не только в этой, но и в остальных областях), как C++ не один другой язык не имеет. Это залог долголетия и процветания C++ и его развития.

Если средство решает все виды задач одинаково хорошо — на самом деле это значит, что оно решает все виды задач одинаково плохо .

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

Д>Если средство решает все виды задач одинаково хорошо — на самом деле это значит, что оно решает все виды задач одинаково плохо .

Только из нескольких подобных средств — некоторые решают задачи в среднем лучше...