В до-христианскую эпоху 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?.. когда мы утратим это безумное, нерациональное, но такое человеческое "я могу лучше".
"Воистину, тщеславие — мой самый любимый из грехов... он так фундаментален..." (с) "Адвокат дьявола"
[ posted via RSDN@Home 1.1.4 beta 6 r433, accompanied by Brian Setzer — When The Bells Don't Chime (Banjo Mix) ]
