Допустим есть класс экземпляр которого возвращает функция реализованная в dll.
И dll собрана компилятором А.

class Foo {
...
};

Foo* CreateFoo();


Какие гарантии ,что при использование этой dll в коде собранном при помощи компилятора Б, вызов функций членов Foo будет правильный?
Ведь как я понимаю различные компиляторы могут по разному представлять экземпляр класса.

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

F>Какие гарантии ,что при использование этой dll в коде собранном при помощи компилятора Б, вызов функций членов Foo будет правильный?
F>Ведь как я понимаю различные компиляторы могут по разному представлять экземпляр класса.

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

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

F>class Foo {
F>  ...
F>};

F>Foo* CreateFoo();

F>Какие гарантии ,что при использование этой dll в коде собранном при помощи компилятора Б, вызов функций членов Foo будет правильный?
F>Ведь как я понимаю различные компиляторы могут по разному представлять экземпляр класса.

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

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

F>Допустим есть класс экземпляр которого возвращает функция реализованная в dll.
F>И dll собрана компилятором А.
F>...
F>Какие гарантии ,что при использование этой dll в коде собранном при помощи компилятора Б, вызов функций членов Foo будет правильный?
F>Ведь как я понимаю различные компиляторы могут по разному представлять экземпляр класса.

Думаю, что даже если А==Б, то можно наступить на грабли, если, скажем, struct member alignment будет отличаться.

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

F>Какие гарантии ,что при использование этой dll в коде собранном при помощи компилятора Б, вызов функций членов Foo будет правильный?

Никаких.

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

PD>Никаких.

COM, тем не менее, обычно работает...

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


E>Для таких гарантий должно совпадать соглашение о вызове методов. Дэйаут класса совпадать для этого не должен...

Для таких гарантий должно совпадать гораздо более важное, чем соглашения о вызове методов. Эти соглашения стандартизованы и могут вполне выполняться, поэтому если речь идет не о классах, то проблемы нет — stdcall можно вызывать откуда угодно, хоть из Delphi или VB.
А вот для классов — должен совпадать формат vtable и то, как указатель на нее в экземпляре хранится. Иначе первый же вызов виртуальной функции отправит вас в голубую даль. А вот это никем не стандартизируется.

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

E>COM, тем не менее, обычно работает...

COM-объект и экземпляр C++-класса — прямо скажем, не одно и то же.

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

__>COM-объект и экземпляр C++-класса — прямо скажем, не одно и то же.

Конечно не одно и то же. Но обычно в С++ можно представить себе указатель на COM-объект, как указатель на абстрактный класс. И при inproc сервере стараются обойтись без маршалинга...

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

E>COM, тем не менее, обычно работает...

Э нет, там двоичный стандарт.

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

E>>COM, тем не менее, обычно работает...
PD>Э нет, там двоичный стандарт.

И компиляторы С++ под винду обычно предоставляют возможность описать интерфейс абстрактного класса так, чтобы он соответствовал стандарту COM... Кстати, ТС не упоминал именно виртуальные функции. Возможно его интересует вызов обычных

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

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

__>>COM-объект и экземпляр C++-класса — прямо скажем, не одно и то же.

E>Конечно не одно и то же. Но обычно в С++ можно представить себе указатель на COM-объект, как указатель на абстрактный класс. И при inproc сервере стараются обойтись без маршалинга...

Топикстартер нигде не говорил, что собирается ограничиваться исключительно абстрактными классами.

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

__>Топикстартер нигде не говорил, что собирается ограничиваться исключительно абстрактными классами.

С обычными методами всё ещё проще. Если подавить inline'инг и не работать с полями напрямую, то достаточно, чтобы совпадало соглашение о вызове...

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

E>И компиляторы С++ под винду обычно предоставляют возможность описать интерфейс абстрактного класса так, чтобы он соответствовал стандарту COM... Кстати, ТС не упоминал именно виртуальные функции. Возможно его интересует вызов обычных

С обычными что-то сделать можно, если только не забывать, что для класса в том же VC используется thiscall, а в BCB ароде как fastcall, причем я даже не уверен, что fastcall_VC == fastcall_BCB

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

PD>С обычными что-то сделать можно, если только не забывать, что для класса в том же VC используется thiscall, а в BCB ароде как fastcall, причем я даже не уверен, что fastcall_VC == fastcall_BCB

На самом деле ещё будет проблема с декорацией имён методов. Так что химичить надо много и хитро. Но часто таки можно...

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


E>На самом деле ещё будет проблема с декорацией имён методов.

Это мелочи, на это есть GetProcAddress

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

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

__>>Топикстартер нигде не говорил, что собирается ограничиваться исключительно абстрактными классами.

E>С обычными методами всё ещё проще. Если подавить inline'инг и не работать с полями напрямую, то достаточно, чтобы совпадало соглашение о вызове...

Ну, видите, сколько разных "если"... А топикстартер никаких ограничений на класс не накладывал.

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

PD>Это мелочи, на это есть GetProcAddress

А звать как? Например операторы?
Я бы, лучше, при помощи DEF файла экспортировал из DLL методы сразу под несколькими именами...

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

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


E>>Для таких гарантий должно совпадать соглашение о вызове методов. Дэйаут класса совпадать для этого не должен...

PD>Для таких гарантий должно совпадать гораздо более важное, чем соглашения о вызове методов. Эти соглашения стандартизованы и могут вполне выполняться, поэтому если речь идет не о классах, то проблемы нет — stdcall можно вызывать откуда угодно, хоть из Delphi или VB.
PD>А вот для классов — должен совпадать формат vtable и то, как указатель на нее в экземпляре хранится. Иначе первый же вызов виртуальной функции отправит вас в голубую даль. А вот это никем не стандартизируется.

это то что назвается http://en.wikipedia.org/wiki/Application_binary_interface

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

_>Здравствуйте, Pavel Dvorkin, Вы писали:

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


E>>>Для таких гарантий должно совпадать соглашение о вызове методов. Дэйаут класса совпадать для этого не должен...

PD>>Для таких гарантий должно совпадать гораздо более важное, чем соглашения о вызове методов. Эти соглашения стандартизованы и могут вполне выполняться, поэтому если речь идет не о классах, то проблемы нет — stdcall можно вызывать откуда угодно, хоть из Delphi или VB.
PD>>А вот для классов — должен совпадать формат vtable и то, как указатель на нее в экземпляре хранится. Иначе первый же вызов виртуальной функции отправит вас в голубую даль. А вот это никем не стандартизируется.

вот так правильно, сорри
_>это то что назвается ABI