Всем привет.
Ребята, я уже описывала эту проблеу, и честно думала, что она у меня благополуно решина
http://forum.vingrad.ru/index.php?showtopic=47242
В кратце ситуация была такая, для класс наследуется от некого интерфейса (структуры с объявлением чистовиртуальных функций).
В dll модель подключается описание это интерфейса, а при вызове функции dll передается указетль на объект моего класса, функция соответственно юзает методы класса.
Все очень хорошо, но когда основной модуль созается в visualStudio, а сама dll пишется на Borland (это принципиально) возникают траблы, связанные с тем, что компиляторы, по разному создают таблицы виртульных функций.
Можно ли решить эту проблему, если да, то как?????

Цитата(Nastya @ 25.4.2005, 07:14)

) возникают траблы, связанные с тем, что компиляторы, по разному создают таблицы виртульных функций.

Ты в этом абсолютно уверена? Метод создания виртуалных таблиц весьма прост и очевиден в реализации, что обычно все компиляторы реализуют его одинаково. Даже Делфи, например.

Единственно, разница может заключатся в умолчаниях. В VS, соглашение вызовов по умолчанию cdecl, а в Борланде fastcall, вроде. Если соглашение одинаковое, посмотри ключевое слово interface в Борланде, если оно там есть используй его (в VC оно точно есть). Это слово специально было введено для обозначения COM интерфейсов, а вызовы к ним унифицированны стандартом.

В принципе, если ты на 100% процентов уверенна, что ДЛЛ экспортирует всё и только то что должен, то Win32 API компотобильность должна соблюдаться.. насчёт C++-ных штук - сумлеваюсь, что проблема в несовместимости vptr'ов и т.д..
со всеми виртуальностями нужно _очень_ сильно осторожничать и лучше вообще отказаться от них.
а вообще непонятна проблема. ты писала access violаtion. значит у тебя там что-то не то: если ДЛЛ загрузился, то память не должна быть блокированна: это одна программа, один пользователь, одно виртуальное адресное пространство... может у тебя там с пользователями, или с правами пользователей проблемы ?
и ещё ... каким образом существует нужда совмещения кода такого рода ?
короче... если тебе не трудно наплевать немного примеров, будет проще думать.

пока...

Извените, может мне кто укажет, гдев СТАНДАРТЕ С++ описанно, как создаются таблицы виртуальных функций и стандартизированно ли это в принципе

Цитата(Nastya @ 25.4.2005, 08:43)

гдев СТАНДАРТЕ С++ описанно

Нет, это никак не стандартизированно, но просто есть вещи, которые делать имеет смысл наиболее очевидным способом. Общепринятым. Как например реализация std::vector - вроде как во всех реализациях его итератор является простым указателем и само внутреннее представление исполненно в виде указателя. Это не стандартизированно, но многие девелоперы закаладываются но то, что это именно так, потому как по другому реализовывать это не умно.


Добавлено @ 18:44
Опять же, Borland весьма заботился о том, чтобы COM технологии работали с ихними средами, а соотвественно им нет смысла уходить от стандартной реализации виртуальных таблиц (стандартизированно COM). Или, по крайней мере, у них должен быть способ указать, что этот интерфейс будет использован как COM интерфейс.

Виртуальные таблицы в Delphi, C++Builder, Visual C++, g++ устрены по-разному.
Совместимость если есть - то только на уровне исходников.
Для вызова функций из dll, написанной с помощью другого компилятора (за исключением
вызова Delphi из C++Builder) нужно использовать чистый C или технологию COM, CORBA etc.

Цитата

Виртуальные таблицы в Delphi, C++Builder, Visual C++, g++ устрены по-разному. Совместимость если есть - то только на уровне исходников.

Устроенны по разному, принцип вызова одинаков. В стек заталкивается указатель на класс, потом все остальные параметры, потом осуществляется вызов по адресу находящемуся по адресу указателя на класс плюс номер метода*4. Совместимость на уровне вызова.

Цитата

технологию COM

А как, по-твоему, вызовы в СОМ осуществляются?

То что принцип одинаковый - никакой роли не играет, потому что детали не сопадают.
Указатель на вируальную таблицу может быть вставлен в другое место в классе, поля в классе
могут быть выровнены по-разному, виртуальные функции могут быть вставлены в таблицу в другом порядке, имена функции декорируются(mangling) по-разному. Нестыковка может быть и
между двумя версиями одного и того же компилятора.
С технологией COM не работал, только иногда использовал готовые компоненты в C++ Builder,
поэтому как она работает не знаю
Здесь по-видимому выбрана C++Builder для dll потому что она написана для этого компилятора и исходники отсутствуют (но заголовки в любом случае нужны)
В этом случае основной модуль лучше писать тоже на C++Builder (преимуществ Visual C++ в этом случае не вижу, если только не нужно использовать еще одну dll, написанную на Visual C++).
Или же придется создавать dll-переходник(bridge) на C++Builder:

Код

class BuilderClass { BuilderClass(); ~BuilderClass(); void Method (); }; extern "C" { void* createBuilderClass () { return new BuilderClass(); } void deleteBuilderClass (void* p) { delete (BuilderClass*)p; } void callBuilderClassMethod() { ((BuilderClass*)p)->Method (); } }

Цитата

Указатель на вируальную таблицу может быть вставлен в другое место в классе, поля в классе могут быть выровнены по-разному, виртуальные функции могут быть вставлены в таблицу в другом порядке, имена функции декорируются(mangling) по-разному.

Безусловно это так. Я про это уже тоже говорил - могут. Но реально никто так не делает, потому что это не удобно, не стандартно, преимуществ никаких не дает, и народ совершенно не оценит. Так же как и с std::vector - его можно реализовать с другой внутренней структурой, но никто так не делает. Декорация функций тут, конечно, упомянута не к месту, так же как и выравнивание полей в классе - они на вызов виртуальных функций не влияют. Собственно, место нахождения указателя на виртуальную таблицу в классе тоже никакой роли не играет.

Цитата

То что принцип одинаковый - никакой роли не играет

Как раз таки он очень большую роль и играет. Именно из-за него я могу вызывать виртуальные методы класса написанного на Делфи из VC.

Смысл реализовавать виртуальные таблицы стандартно есть еще именно из-за COM. Вызовы интерфейсов - это обращения к виртуальным таблицам, и если делать их не стандартными, то придется еще специальные заморочки делать для написания СОM объектов. С CORBA, кстати, та же история. Я и с тем и с другим занимался на достадочно низком уровне, чтобы знать это.

Воообще проблем никогда не существовало. Во всяком случае мпри использовании класса из dll, созданного VC и имортированного в Builder. Естественно елси соблюдабтся определенные правила
С++ Builder

Код

class FromVC { public:     virtual __stdcall void Fun1() =0;         virtual __stdcall  void Fun2() =0;              // и так далее     }; // создание объекта extern 'C' FromVC* __stdcall CreateFromVC(); extern 'C' void __stdcall  DeleteFromVC(FromVC*); FromVC*  fromVC = CreateFromVC(); //...  DeleteFromVC(fromVC);

VC++

Код

class FromVC { public:      FromVC(){}     virtual __stdcall void Fun1(){}     virtual __stdcall  void Fun2(){}              // и так далее      virtual ~FromVC(){} }; extern 'C' FromVC* __stdcall CreateFromVC(); extern 'C' void __stdcall  DeleteFromVC(FromVC*); FromVC* __stdcall CreateFromVC()  {      return new FromVC(); } void __stdcall  DeleteFromVC(FromVC* fromVC) {     delete  fromVC; }

Спасибо, попытаюсь еще раз.