Что удалось узнать про SOM. Отличия от COM выходят далеко за рамки наличия наследования. Например, в COM очень важна ссылочная непрозрачность. Есть ссылка, и всё. Куда она указывает, неведомо. В SOM, напротив, имеют значение values, а не только references, пусть даже структура этих value неизвестна. У объектов есть фиксированный для каждого класса размер, который можно узнать у класса вызовом somGetInstanceSize. Можно узнать размер, выделить памяти под 10 экземпляров и разместить их плотно друг за другом, инициализировав каждый методом somRenew. Есть присваивание и копирующий инициализатор. На уровне DLL всё держится на экспортируемых и импортируемых функциях НазваниеКлассаNewClass. SOM compiler из одного .idl обычно делает 3 файла: хедер для чужих, хедер для себя и заглушка, в которую программист вписывает реализации методов. Хедер для себя как раз и содержит сгенеренные по шаблону тела НазваниеКлассаNewClass. Эта функция для своей работы потребует классы–родители и метакласс, которые при необходимости будут созданы через аналогичные NewClass в тех .dll, где реализованы соответствующие классы. Так происходит почти со всеми классами, кроме основных (SOMObject, SOMClass, SOMClassMgr), которые создаются somEnvironmentNew. Когда создан класс, всё остальное происходит через штатные механизмы SOM. Создание объектов — метод somNew у объекта–класса. Или somRenew, если объект создаётся в уже выделенном участке памяти. При использовании C генерится уйма макросов, которые приукрашивают косвенный механизм вызова методов. Если без макросов, вызов обычно состоит из SOMResolve и собственно вызова. SOMResolve возвращает MethodPtr, который нужно привести к прототипу нужного метода и уже тогда вызвать с аргументами. Всё это и скрывается макросами. Обилие макросов чем–то напоминает GObject. По тексту Programming Guide периодически проскальзывает CORBA, и все эти макросы вроде бы как по спецификации CORBA генерятся. Моё личное мнение: SOM'у не помешал бы свой аналог Objective-C или Vala, в котором всё было бы красиво и без макросов. При использовании C++ в хедерах генерятся как бы классы, но объекты этих классов напрямую (на стеке) создавать нельзя, потому что размер неизвестен до инициализации класса. Нельзя наследоваться от таких классов средствами самого C++. Только через IDL и SOM compiler. Можно вызывать operator new и operator delete, которые перегружены так, чтобы вызывать somNew и somFree, соответственно. Если у SOM класса есть нестандартные инициализаторы, каждый из них становится доступен не только как метод, но и как конструктор. somDefaultAssign и somDefaultCopyInit превращаются в копирующий конструктор и operator =. По идее, можно ещё operator new (void*) перегрузить так, чтоб вызывал somRenew, но это не сделано. В февральской бете совместно с компилятором VisualAge была экспериментальная фича Direct2SOM. Компилятор C++, поддерживающий эту фичу, мог генерить по обычному C++ коду SOM–совместимые классы и .idl для них. В каком состоянии это было, неизвестно, в декабрьском релизе это решили вырезать и потом доделать.