Comments 47
COM объект – это C++ класс, созданный по правилам COM
Вот с этой ошибки все и начинается. С нежелания и возможно неумения просто открыть и почитать родную документацию. Хотя бы главную страницу, где написано, что такое данная технология, и зачем она.
COM — это Component Object Model, и если открыть первую же страницу в поиске по этому сочетанию, то там написано:
a platform-independent, distributed, object-oriented system for creating binary software components that can interact.
То есть, это модель компонентов софта, платформо независимая (не то чтобы у них это получилось, но попытки реализации под линукс вроде бы были), распределенная (DCOM), и тут нет ни слова про C++, потому что компоненты эти предполагалось сразу (и можно до сих пор) писать почти на чем угодно. То есть скажем на Perl хотите? Можно и на нем.
И ровно из всего этого уже логично вытекает все остальное — что есть правила, которые общие для всех языков реализации, и которые можно реализовать на разных языках, поэтому есть отдельный язык описания API, поэтому есть реестр классов, чтобы скриптовые языки типа VB Script могли делать как-то так:
Set objXL = CreateObject("Excel.Application")
и работать с функциональностью Excel, который внутри состоит из множества COM компонентов.
Ну и другие реализации конечно были. Больше всего пожалуй COM похожа на SOM от IBM, которая лежала в основе OS/2, и благополучно почила вместе с ней. А IDL например — вполне в духе CORBA.
COM объект – это C++ класс
Поперхнулся и дальше не читал. Ничего, что по мнению создателей "COM is independent of implementation language"?
Действительно я не сталкивался с разработкой СОМ объектов на чем нибудь кроме С++. Я писал DirectShow фильтры. Чесно говоря несколько лет прошло прежде чем я обратил внимание что там используется СОМ в каком то виде.
Я прошу вас прочитать все таки дальше, я надеюсь что то интересное все таки получится найти.
Извините что заставил поперхнуться :), но дальше читайте все таки с осторожностью, я надеюсь найдется причина поперхнуться не по поводу ошибки.
Ух ты! Давненько не слышал чтобы это кому-либо было нужно, разве что для поддержки легаси. А действительно на этом еще кто-то серьезно разрабатывает? мне казалось что разработка под виндоус уже почти уехала на C#, а что-то низкоуровневое можно и на Win32 API заделать.
Как известно, все новое это хорошо забытое старое. Это не разработка уехала, это разработчики улетели в облака.
Т.е. вы на полном серьезе предлагаете вернуться к этому ужасу регистрации COM объектов в реестре, полуавтоматическому управлению памятью, вместо удобного автоматического, предлагаемого .NET, ко всей этой возне с заголовочными файлами и файлами реализации, к более сложному синтаксису C++, по сравнению с C# ну и так далее. Очень напоминает луддитов, которые боролись с неизбежным :)
Вам не предлогаю, а тем кому надо работать с DirectX, например, без этого не обойтись.
Если вы не в курсе не вся работа сосредоточена в облаках, некоторым все также приходится работать на разных уровнях приближения к земле, а земля как известно больше чем на треть состоит из железа.
Я вроде ни слова не сказал про облака - вы сами придумали это. Я лично имел ввиду классические Windows приложения. Вы их очень легко можете писать с использованием того же WinForms (весьма тонкая обертка над Win32 API) ну или WPF (немного более толстая), разницу в скорости, на более, менее нормальном железе вы не увидите, зато увидите разницу в скорости разработки. Это раз.
Далее, если уж очень хочется низкоуровщины, - можно и без COM, используя Win32 API, ну а совсем если хотите bleeding edge - можно использовать тот же Rust (за который Microsoft в целом и Марк Руссинович в частности очень сильно топят), тем более что есть вполне сносный крейт для этого (https://crates.io/crates/windows). Вы получите и современный язык, без кучи тараканов, и отсутствие сборки мусора, за что вы сильно переживаете. Это два
про облака - это мне так показалось - это да.
WPF вроде как обертка не над Win32 API, а над DirectX-м.
По поводу: хочется низкоуровщины, это вроде как вы немного передергиваете, ее никогда не хочется, с ней приходится иметь дело. Если вы нашли способ работать не вспоминая про низкоуровневые проблемы, ну хорошо. Но ведь кто то эту низкоуровщину вам обеспечивает, а у вас это звучит так что это какая то грязная работа недостойная светлых разработчиков.
Сборка мусора меня ни в каком виде не беспокоит, меня беспокоит что обсуждение сводится только к обсуждению ее наличия.
И тараконов можно развести на любом языке, это не от языка зависит, а от того кто на нем пишет, я так думаю.
удобного автоматического, предлагаемого .NET
Это там, где момент уничтожения объекта в общем случае предсказать невозможно, а вместо полноценного RAII костыль в виде IDisposable? Спасибо, конечно, но... Мягко говоря, это не всем подходит.
IDisposable.Dispose() это, по сути, и есть "уничтожение объекта". А GC это всего лишь уплотнение кучи. Можно сказать, что такого как "освобождение памяти" в .NET просто нет - куча просто уплотняется и все.
Ага, только вот это именно что нисколько не удобный и отнюдь не автоматический костыль, сделанный с расчётом на то, что "конечный пользователь" класса, реализующего IDisposable, не забудет обернуть его в using.
А GC это всего лишь уплотнение кучи
Это далеко не всегда так. Куча уплотняется лишь при сборке мусора второго поколения, при этом останавливаются все рабочие потоки. В нулевом и первом поколении никакого уплотнения нет. Далее, куча больших объектов (более 85000 байт) или LOH вообще не трогается (это слишком накладно двигать такие объекты), а учитывая что наверно 99% в ней это массивы и другие коллекции (мне сложно представить себе обычный объект такого размера), со временем, при длительно работающем процессе, который выделяет много подобных объектов, становящихся затем мусором - легко можно получить неслабую такую фрагментацию этой кучи и как следствие постоянный рост рабочего набора процесса. В общем, не так все радужно и с автоматическим мусоровозом.
Это там, где момент уничтожения объекта в общем случае предсказать невозможно
А это и не нужно для чисто managed объектов
а вместо полноценного RAII костыль в виде
IDisposable
этот паттерн придуман не для этого, а для освобождения особо ценных ресурсов, количество которых ограничено (открытые сокеты, файлы, соединения с БД и т.д.), которые неплохо бы освобождать сразу после использования. Для всего остального есть GC.
Мягко говоря, это не всем подходит.
Да, это совсем не нужно использовать для освобождения классических managed ресурсов, да и невозможно это с этим паттерном в принципе.
Детальнее о работе с памятью стоит прочитать книгу К. Кокосы, она вроде так и называется, - управление памятью в .NET, и есть очень неплохой русский перевод.
Прочтение откроет вам глаза на то как ДЕЙСТВИТЕЛЬНО все работает
этот паттерн придуман не для этого
Для чего "этого"? Этот паттерн придуман, чтобы имитировать в C# RAII из нормальных языков (так же как и try-with-resources в Java), но, как водится, не без колхоза, причем до появления using нужно было вообще писать try/finally блок для IDisposable вручную (собственно, using и есть синтаксических сахар для такого блока).
Прочтение откроет вам глаза на то как ДЕЙСТВИТЕЛЬНО все работает
Спасибо, я в курсе, как ДЕЙСТВИТЕЛЬНО все работает.
Откуда такая агрессия?
ричем до появления
usingнужно было вообще писатьtry/finallyблок дляIDisposableвручную
using был с самого начала https://www.ecma-international.org/wp-content/uploads/ECMA-334_1st_edition_december_2001.pdf страница 200 (в pdf файле страница 214). Потрудились бы для начала стандарт почитать, прежде чем писать такую ересь - перехожу на ваши методы разговора, уж простите
Откуда такая агрессия?
Какая агрессия?
using был с самого начала
Да, действительно, using statement был доступен в C# с самой первой его версии, это у меня видимо история его появления как-то пересеклась в голове с историейtry-with-resourcesиз Java, который служит аналогичным целям является аналогичным костылем, но появился лишь в Java 7.
причем до появления using нужно было вообще писать try/finally блок для IDisposable вручную
Ого... Это когда такое было-то??? Оно там с самой первой версии - погуглите ECMA-334 от 2001 года. Эксперты дотнета, блин. Фейспалм.
.NET много где использует COM - оно никуда не делось. Нам дали толстоватую обертку над многими вещами и кое кто теперь думает, что COM отмер
"много где" - а можно перечислить хотя бы 3-5 "где"?
это даже я вам скажу: вроде как и Excel и Word никуда не делись, и DirectShow вроде никто не отменил, все это все также связано с СОМ спецификацией, все это доступно из .NET
так же как какой нибудь 17, 22, 25 С++ стандарт не отменяет самый исходный С++ стандарт, так же и СОМ спецификацию никто не отменяет, она все также лежит в основе практически всех технологий на Windows.
Идея то была хорошая, а вот реализация уж больно запутанная. Наверное следствие того, что тогда все делалось на весьма низкоуровневом С++.
В СОМ была, к сожалению, такая изначально порочная и, как показало дальнейшее развитие, тупиковая вещь, как управление памятью с помощью подсчета ссылок.
Интересно чего же в ней тупикового? То что она работает уже 25 лет и всегда будет работать? То что она позволяет собственную, абсолютно контролируемую, стратегию управления памятью реализовать?
Подсчет ссылок хорош когда у тебя простая ситуация. Когда же у тебя целый граф связанных объектов с циклами, то это превращается в настоящий ад (а особый ад это когда все это еще распределено под DCOM).
и, как показало дальнейшее развитие, тупиковая вещь, как управление памятью с помощью подсчета ссылок
Хм, а как же Rust с его Rc (и потокобезопасным Arc)? Это ведь тоже умный указатель со счетчиком ссылок. Все таки не такая и тупиковая вещь, как может показаться
С чего это тупиковая вещь? На С++ это чуть ли не обязаловка, управление памятью напрямую организуется обычно в исключительных целях, и считается плохим тоном в реалиях современной разработки на С++.
В С++ просто альтернативы нет. Из-за его низкоуровневой природы указателей. А, вот, в JavaScript (точнее в его распространенных реализациях), как раз, от подсчета ссылок в свое время отказались и переделали все на GC.
применение сборщиков мусора это, конечно не та тема, которую я хотел бы видеть в рамках обсуждения этой статьи.
Хотелось бы что то про сложность реализации, критерии ее расчета, сложность реализации кода в соответствии с СОМ спецификацией, ... про dependency injection наконец.
Вот, сдается мне, это облачные технологии плохо влияют на способности программистов, все сводится к тому, как бы найти то, что сделает всю работу за нас.
Потому что там и нет в этом особой нужды, JS язык не для производительности кода. И в С++ были альтернативы да и сейчас есть всякие версии сборщиков мусора, только они не приживаются, потому что сборка мусора отнимает производительность (ну или ручное управление памятью). А если например использовать только unique_ptr то вообще можно получить подобие rust.
Интересно а для какой идеи такого уровня вы видели не запутанную реализацию?
Потом почему идея "была"? Если кто-то решил на какую то идею забить, это не значит что она для всех пропала.
Как говорится:
что один человек придумал, другой завсегда разобрать сможет!
Статья припозднилась лет, этак, на 25, а в остальном все более-менее ок :))
Когда-то давно разрабатывал под COM на паскале (дельфи). До сих пор осталось несколько книжек. В одной, как сейчас помню, написано что-то вроде: "Вот-вот COM заработает на макос". Сейчас это, разве что, в экселе можно встретить.
Ещё читал про XPCOM от Mozilla, но ни разу не видел в использовании. Жаль, что технология не получила развития.
Вау! Написать про COM статью в 2023... И при этом не написать в этой статье реально ни о чём! Где описание жизненного цикла, базовые интерфейсы, базовые возможности, OLE, Automation, thread-model, ATL (for C++)...
Мечтал в молодости написать какой-то крутой редактор с поддержкой OLE (на MFC или OWL), но не сложилось ((... А сейчас OLE уже давно deprecated так как небезопасно (и в том же word сейчас поддержка OLE или удалена, или выключена, а было очень удобно лет 20 назад вставлять MathCAD документы в Word)
Минусанул бы, да прав нет))
Если бы вы действительно прочитали статью, вы бы заметили что речь там идет не о работе с офисными программами! Вставлять MathCAD документы в Word наверно очень круто, но я спезиализируюсь по видео обработке, или, обобщенно, по потоковой обработке данных в реальном времени.
Насколько я знаю-понимаю thread-model относится не в общем к COM - технологии, thread-model достаточно специфична для каждой отдельной предметной области. Я бы мог написать про thread-model для видео обработки, но после полученной оценки за эту статью желания нет.
Буду немножко вредным дальше ))
>> "Вставлять MathCAD документы в Word наверно очень круто..."
Сори, это было мое лирическое отступление, простите уж ))
>> "thread-model относится не в общем к COM..."
COM имеет свою thread-model https://learn.microsoft.com/en-us/windows/win32/com/choosing-the-threading-model и очень много чего ещё, что уже почти никому не нужно сегодня https://learn.microsoft.com/en-us/windows/win32/com/guide (характерный стек сервисов/обязательств для компонентной модели)... а еще есть/были COM+, DCOM расширения.
>> "... но после полученной оценки за эту статью желания нет."
Понимаю, но вы написали слишком general title для очень маленькой статьи (ваша ошибка; насколько я вижу вы уже переименовали статью, и правильно сделали, но опоздали), а тема то мега-мега-жирная, по которой толстые книги/мануалы (но по большей части это устарело). Это как заявить, что я вам расскажу о С++ в статье "Язык С++" на пару страниц ))
Не переживайте, у вас всего 4 минуса, надеюсь в карму много минусов не накидали.
На хабре любят новые фундаментальные (выстраданные на своем опыте) статьи, а короткие уже давно где-то написаны.
Успехов вам!
Не умер ли еще Microsoft COM, где можно найти его применение?