![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
singalenКогда-то давно потерял этот текст, кажется, 2000-го года. Чтобы не потерялся, запишу сюда.
Автор, увы, неизвестен.
История программных революций от Microsoft, вкратце:
Сначала были Windows API и DLL Hell. Революцией №1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием "по месту", при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции "System File Protection", исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили "COM" или "Active" или "X" или "+" - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про "Windows DNA" (почему не DINA) и "Windows Washboard", и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как "doughnut (пончик по-нашему)", но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Автор, увы, неизвестен.
История программных революций от Microsoft, вкратце:
Сначала были Windows API и DLL Hell. Революцией №1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они! Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием "по месту", при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.
Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).
Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции "System File Protection", исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие. Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили "COM" или "Active" или "X" или "+" - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про "Windows DNA" (почему не DINA) и "Windows Washboard", и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.
К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как "doughnut (пончик по-нашему)", но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.
В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
31/7/07 13:49 (UTC)Самое обидное - когда то тратил время на баги в OCX...
(no subject)
31/7/07 13:51 (UTC)И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама...
Априорит
5/8/07 23:09 (UTC)Re: Априорит
12/8/07 13:07 (UTC)Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея. Если в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы. Тебе придётся нетривиалными путями искать, как обойти чужой глюк... и дай Бог, чтобы только один в одной версии компонента.
То же относится к подсчёту ссылок, исключая пинки C++.
Re: Априорит
17/8/07 10:24 (UTC)2) Ничего, что половина винды работает на COM? Ты наверное просто не совсем в теме.
3) В .NET-е тоже любой модуль может кинуть исключение, которое возможно не будет перехвачено и весь процесс рухнет. Или не так? И сам .NET фреймворк не на С++ ли написан?
(no subject)
18/8/07 20:13 (UTC)2. Я в теме. Я прекрасно понимаю, что именно поэтому эта половина винды так тормозит. А вторая половина без первой, увы, не поедет.
Если ты, мой любезный аноним, настолько в теме, то тебе известно первое правило distributed computing по Фаулеру? Если нет, то найди его в PoEA и подумай.
3. Принципиально не так. Исключение можно перехватить; и сделать это крайне легко. Если же чужой код срёт в твою память или не отпускает твои ссылки - ты с этим не сделаешь НИЧЕГО. Точка. Я доступно излагаю?
Популярность С++ - отдельная тема. Для меня очевидно, что есть языки более простые и более высокого уровня, и более пригодные к программмированию, чем, скажем, C++ и Java в момент их создания. Нет, это не моя отмазка их не изучать: я знаю их хорошо, но оцениваю без поросячьего восторга.
(no subject)
13/2/09 13:58 (UTC)т.е. выход - не юзать вообще чужие библиотеки?
(no subject)
13/2/09 14:41 (UTC)(no subject)
13/2/09 15:08 (UTC)"И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама..."
ты сам по понимаешь что написал?
"Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея." тогда вообще не используй никакие DLL библиотеки сторонних производителей... так как COM (inproc server) это так же dll с выставленной наружу vtbl... от dll слабо отличается с точки зрения нагадить в чужую память
"и в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы"
да... да, в конечных продуктах, а вот если они появляются в компонентных - это уже руки крюки.. суть в том, что компоненты обычно не такие уж и большие и все указатели там нормально можно отследить, если их нормально (boost::shared_ptr, boost::weak_ptr) юзать... в большом проекте с кучей ламеров это конечно на порядок сложнее
"У внепроцессного сервера своя проблема - производительность"
оно то и предназначение у них децл другое
"2. Я в теме. Я прекрасно понимаю, что именно поэтому эта половина винды так тормозит. А вторая половина без первой, увы, не поедет." бред как он есть..
еще раз: по большей части COM - это dll с выставленным vtbl, выставь просто свои функции и почти COM
"опулярность С++ - отдельная тема. Для меня очевидно, что есть языки более простые и более высокого уровня, и более пригодные к программмированию, чем, скажем, C++ и Java в момент их создания"
это спор вечен, но то, что нет более выразительного языка чем С++- факт :)
(no subject)
13/2/09 15:53 (UTC)Не пишите в мой журнал больше, пожалуйста.
(no subject)
13/2/09 16:01 (UTC)(no subject)
13/2/09 18:15 (UTC)(no subject)
13/2/09 18:16 (UTC)(no subject)
13/2/09 18:23 (UTC)Это неправда.
(no subject)
13/2/09 18:37 (UTC)"И слава Богу - если несколько разных объектов разных производителей вместе считают ссылки на один объект, и могут гадить в адресном пространстве друг друга - мама..."
ты сам по понимаешь что написал?
не совсем культурная форма, конечно, но тут я попытался объяснить, что то, что кто-то считает чью-то ссылки вовсе не означает, что гадят память, ибо с таким же успехом можно предположить что память гадят CStringT, _bstr_t, shared_ptr, shared_array, auto_ptr и так далее... они тоже считают ссылки... inproc COM сервер мало чем отличается от dll, которая экспортирует функции.
"Повторяю, разрешать чужому коду работать в твоём адресном пространстве - плохая идея." тогда вообще не используй никакие DLL библиотеки сторонних производителей... так как COM (inproc server) это так же dll с выставленной наружу vtbl... от dll слабо отличается с точки зрения нагадить в чужую память
тут я попытался объснить, что следуя этой идее, т.е. запрещать чужому коду лазить в собственное пространство, нужно вообще не использовать сторонних библиотек (dll), да и обычных типа MFC тоже (по хорошему). а это является полностью impossible
"и в КАКОЙ-ЛИБО версии нём где-то есть ошибки работы с указателями — а в C++ и unmanaged code вообще это практически неизбежно — то у тебя большие проблемы"
да... да, в конечных продуктах, а вот если они появляются в компонентных - это уже руки крюки.. суть в том, что компоненты обычно не такие уж и большие и все указатели там нормально можно отследить, если их нормально (boost::shared_ptr, boost::weak_ptr) юзать... в большом проекте с кучей ламеров это конечно на порядок сложнее
тут я попытался объяснить, что идиома RAII (shared_ptr, auto_ptr и так далее) позволяет для небольших проектов избежать вообще проблем с указателями... для больших неудается, так как чем больше проект тем больше людей которые только думают, что знают цепп... а в очень больших проектах - такие ошибки просто есть... но они уже лежат на другом логическом уровне, чем просто неверная работа с указателями
ну и так далее...
если вам все еще было непонятно о чем речь = не понятны отдельные тезисы или их связь с вашим комментом, то можно было задать вопрос
(no subject)
14/2/09 10:51 (UTC)Дважды говорите нонсенсы.
Первый - когда говорите, что задали вопрос. Вы об этом только подумали. Телепаты в отпуске, помните?
Второй - что из замечания "сделайте это культурно" следует, что мне непонятна техническая сторона вопроса. Правильным выводом было бы - понять, что в таком тоне я разговаривать не буду.
Человек, знающий хоть что-то о культуре дискуссии, допустил бы как гипотезу, что собеседник может понимать что-то, чего не понимаешь сам. Для этого надо, правда, умерить своё эго. Сложная задача, но большинство с ней справляется.
Теперь прошу вас сделать одну из двух вещей: перечитать свои слова и извиниться, после чего мы можем перейти к обсуждению технической части. Можно в четверг за пивом, если вы ещё в Днепре и не стесняетесь показать лицо.
Или таки-прекратить сюда писать.
(no subject)
14/2/09 11:05 (UTC)(no subject)
14/2/09 11:08 (UTC)Прощайте.
(no subject)
30/8/07 19:22 (UTC)Новые, модные и громкие тухнологии применяются просто потому, что могут применяться. В результате список применяемых технологий разрастается до десятка элементов, из которых штук семь уже выведены мекрасовтом из моды, объявлены устаревшими, замороженными, положенными на сохранение или просто заметенными под кровать.
В одном легаси-проекте применялись скриптлеты(!) (COM-объекты на языках WSH, в частности, JScript). Там же применялись ASP-странички на JScripte (неужели не понятно, что JScript - это была вынужденная политическая уступка мекрасовта, и что кое-какая функциональность куда проще и удобнее доступна через VBScript ? - мекрасовту ведь нужен вендор-лок-ин, а не кроссплатформенность какая-то). Ну и да, юзались также свои ISAPI-DLLки для установки модулей в IIS. Ну и как же обойтись без своих COM-объектов на C++. Ах да, ещё нужна кучка сторед-процедур под MS SQL. А вот MFC аффторам, наоборот, не понравился, и они написали свою уникальную систему обёрток над Win32шными гуишными контролами. Умные ведь, а ум не должен зазря без дела пропадать :>
Результат - проект вызывает стойкое желание отложить его в сторонку и переписать с нуля несколько попроще. При этом особенно избегая хвататься за тухнологии, навязываемые мекрасовтом в качестве сегодняшнего писка моды и явно рискующие оказаться под кроватью через год.
Я тоже не слишком понимаю анонимного гражданина, видящего в способности овладеть COMом признак силы. "Бутерброд с маслом каждый съесть сможет, а ты вот попробуй полкило г. слопать - слабО ?" :>
Если такая сила есть, возникает очень сильное искушение отказаться от применения ума :>
(no subject)
30/8/07 19:57 (UTC)(frozen) (no subject)
13/2/09 14:01 (UTC)(frozen) (no subject)
13/2/09 19:53 (UTC)(frozen) (no subject)
13/2/09 22:44 (UTC)__asm int 3 спасет мир...
а вообще изначально iis под дебуг грузишь, а в dll ставишь бряку... по моему достаточно удобно....я там в комментах выше уже писал, что COM inproc server по сути обычная dllка...
(frozen) (no subject)
14/2/09 06:00 (UTC)Самое трудное - это управлять сложностью. Чтоб стремительно растущая по сложности система не путалась в собственных ногах. И вот у microsoftа (да и не у них одних) это получается не слишком хорошо. Хотя именно они прилагают значительные усилия, ведут исследования и разработки и кое-чего в этом деле таки добиваются. Но COM я бы таким достижением не назвал. Для самого microsoftа - возможно. Но для наружных девелоперов - сомнительно. Слишком много требуется скиллзов. Слишком мало выгоды. Слишком легко применить неправильно.
Вообще, весь этот хелл образуется из-за неправильного разделения системы на подсистемы и организации взаимодействия между ними. Windows давно уже сложнее, чем mainframовские системы с виртуальными машинами, а многие замашки у неё остаются по-прежнему DOSовскими. Всё это легаси создаёт кучу насилия, оверхеда и блоата то там, то сям. Особенно легко с этим столкнуться при написании своих приложений. И главное ж, никто это радикально рефакторить не будет. Microsoft пишет свои системы, чтоб деньги зарабатывать, а не чтоб девелоперов удовлетворять. Дешевле маркетингом девелоперский мосск заморочить.
(frozen) (no subject)
14/2/09 09:16 (UTC)в том то и дело, что если рассматривать inproc server, то от обычной dllки до COM ход примерно такой:
-выставляем функции
-выставляем еще одну функцию которая описывает все функции, что есть в dll
-упаковываем все это дело в класс и выставляем наружу vtbl фабрики классов...
все... COM готов... конечно можно еще вспомнить, что для apartment нужно чтобы COM среда окно создала, маршрутила туда вызовы... но это не создает проблем...
я согласен с тем, что она досточно сложная... все проблемы идут от тупых программеров, которые не понимают, что однажды выпущенный интерфейс уже менять нельзя... но они меняют, и получаем dll hell. получаем, что разные версии объектов имеют разный интерфейс под одним IID... и все... изящность модели (по меркам того времени) сошла на нет...
"Самое трудное - это управлять сложностью. Чтоб стремительно растущая по сложности система не путалась в собственных ногах. И вот у microsoftа (да и не у них одних) это получается не слишком хорошо. Хотя именно они прилагают значительные усилия, ведут исследования и разработки и кое-чего в этом деле таки добиваются. Но COM я бы таким достижением не назвал. "
согласен со всем, кроме последнего пункта... самая большая заслуга COM - это распостранить модель интерфейсного программирования из сорсов в бинарники. это был ключевой момент, который был огромных достижением и который есть и сейчас в C# в гораздо более удобной форме.
"Вообще, весь этот хелл образуется из-за неправильного разделения системы на подсистемы и организации взаимодействия между ними. Windows давно уже сложнее, чем mainframовские системы с виртуальными машинами, а многие замашки у неё остаются по-прежнему DOSовскими. Всё это легаси создаёт кучу насилия, оверхеда и блоата то там, то сям. Особенно легко с этим столкнуться при написании своих приложений. И главное ж, никто это радикально рефакторить не будет. "
согласен
"Microsoft пишет свои системы, чтоб деньги зарабатывать, а не чтоб девелоперов удовлетворять. Дешевле маркетингом девелоперский мосск заморочить"
тоже согласен, но отчасти... если не удовлетворять нужды девов то и бабла то не будет... потому что помимо мелкомягких много других пронырлевых ребят.. и это мы видим и так, например, ихняя ORM EntityFramework уже проигрывает всяким XPO и NHebirnate... так что пусть стараются, а нам будет счастье :)
естественно +много к мысли о том, что в погоне за баблом мы часто видим сырые продукты... это огорчает :(((
(frozen) (no subject)
14/2/09 10:02 (UTC)Согласен, что в .Nete всё намного красивее. Но там ведь managed-код. Больше информации для линковки в рантайме. Больше информации о том месте, где твоя софтина споткнулась и почему. Нет висячих указателей и повреждения памяти. Первоначально разговор был именно о классическом, традиционном, unmanaged C++ в смысле Страуструпа и Microsoftа до придумывания ими .Neta. На базе которого решили наворотить первоначальный COM. Что создало слишком много добавочных причин, чтоб в большинстве типичных простых случаев считать такой COM излишеством не просто нехорошим, а даже вредным.
И да, есть независимые от Microsoftа разработки и инструменты, которые по удобству и полезности превосходят то, что они сами предоставляют. С этим тоже приходится жить :>
(frozen) (no subject)
14/2/09 10:42 (UTC)в том то и дело, что COM уже находится на другом идиоматическом уровне, чем dll и экспортируемые функции...
это как процедурное программирование и объектно-ориентируемое... вроде бы в целом одно и тоже, да не совсем :)
(frozen) (no subject)
14/2/09 10:54 (UTC)Если смотреть с более высокого идиоматического уровня, то конечно, чёрное может восприниматься белым, а белое - наоборот, зелёным. Но не проще ли перейти сразу на managed .Net ? Кажется, microsoft уже довёл его до зрелости и в ближайшем будущем не собирается заметать под кровать.
Не говоря уж о том, что альтернативные средства типа Явы, Питона и пр. существовали задолго до.
(frozen) (no subject)
14/2/09 11:00 (UTC)а можете пример привести, оч интересно... т.е. интересны примеры, где конкретные реализации противоречат стандарту.
"Высокий уровень языка, богатые функциональные и выразительные возможности с одной стороны - и отсутствие автоматического управления памятью и рантаймовой интроспекции с другой стороны. Это причина возникновения ада при массовом и не всегда высококвалифицированном применении C++ в его традиционном виде. И дальше - это причина возникновения этих "технологий для облегчения жизни", для каждой из которых средние и нижние программеры всё равно найдут способ неправильного использования."
согласен, что есть, то есть
"Но не проще ли перейти сразу на managed .Net ?"
для некоторых задач плюсы, для некоторых .net :)
(frozen) (no subject)
14/2/09 11:08 (UTC)можно и много других примеров найти...
но суть не в этом, думаю, что по большинству из обсуждаемых вопросов мы таки думаем одно и тоже
(frozen) (no subject)
14/2/09 11:10 (UTC)(frozen) (no subject)
14/2/09 10:55 (UTC)(frozen) (no subject)
14/2/09 11:06 (UTC)(no subject)
31/7/07 16:41 (UTC)(no subject)
31/7/07 22:06 (UTC)Еще забыли про .local-изоляцию, которая тоже боролась с DLL Hell.
(no subject)
1/8/07 07:19 (UTC)За дополнение спасибо :)
Прощальный ответ для анонимного визарда :
14/2/09 11:31 (UTC)Под противоречиями я подразумевал то, что спецификация языка C++ поднимает его, с одной стороны, на слишком высокий уровень, а с другой стороны, оставляет слишком много свободы и ручной работы на нижнем (управление памятью, интроспекция и пр.).
Кстати, ещё один пинок в сторону COMа - тебе приходилось когда-нибудь писАть COM-объекты на какой-нибудь другой реализации C++, кроме Microsoft Visual ?
И второе. Насчёт memcached. Это, если приглядеться, довольно простой сетевой сервис типа proxy, внутри у которого довольно простой конечный автомат. Такое нетрудно и на C написать, не то что на C++. Все объекты аккуратно оттреканы, со всеми чётко ясно, кто где лежит, кто на кого ссылается и когда кого выбрасывать, чтоб никого не обидеть. И нужна высокая производительность. Так что выбор C++ вполне понятен.
К тому же, в memcached не используется COM, и это можно только похвалить как разумный и сознательный инженерный выбор на начальных стадиях проекта :>