[delphi]Экспорт класса из dll

grnat

Кто нибудь сталкивался с таким: есть сиппная длл, в ней - некоторые классы, необходимо динамически экспортировать этот класс в Делфю.
ЗЫ еще есть сэмпл на плюсах, там все это реализовано, но мне это пока никак не помогает, разве что структуры посмотреть.

Marinavo_0507

А давно в Си появились классы?
А описания классов в DLL?

grnat

ну плюсы плюсы везде... в длл классы, зачем придираться к словам то?
Зы я плюсы на уровне классов вообще не помню.

Marinavo_0507

Интересует и второй вопрос.
Покажи свои сэмплы, интересно, как на плюсах в динамике подгружают классы.

kill-still

Ну я сталкивался.
В чём проблема-то?
Рассказывай.

grnat

на плюсах видимо они не в динамике, мне надо в Делфе в динамике.


#if !defined(AFX_PCPNBAPIBASE_H__73AADE92_BFE4_40E6_B2CE_F890E7C7F16D__INCLUDED_)

#define AFX_PCPNBAPIBASE_H__73AADE92_BFE4_40E6_B2CE_F890E7C7F16D__INCLUDED_

#if _MSC_VER > 1000

#pragma once

#endif // _MSC_VER > 1000

#ifdef PCPNB_EXPORTS

#define PCPNB_API __declspec(dllexport)

#else

#define PCPNB_API __declspec(dllimport)

#endif

class CPCPNBAPIApp;

class CDeviceThread;

/*! \class CPcpNBAPIBase

  \brief Base class for each device's API.

*/

class PCPNB_API CPcpNBAPIBase  

{

public:

 CPcpNBAPIBase;

 virtual ~CPcpNBAPIBase;

  //! Test the netbios session to see if it's connected.

  virtual BOOL IsConnected;

  virtual int Send(LPCSTR strBuffer, int iLength);

  virtual LPSTR GetDeviceResponse( LPSTR strBuffer ){return NULL;}

  virtual int SendCommand( int iCommand );

  //! Get the physical port Status of the device.

 virtual int GetDevicePortStatus( PUSHORT pStatus );

  virtual int GetParallelPortStatus( PUSHORT pStatus );

 virtual int SetAEAMode( LPCSTR strMode );

 virtual BOOL ReInitialize;

 virtual BOOL IsInitialized;

  //! Load the pectab buffer.

 virtual int LoadPectab( LPCSTR strPectab, BOOL bStrip );

  virtual int LoadLogo( PCHAR pLogo, LPCSTR strLogoID, int iLogoSize );

  virtual int PcpLock;

  virtual int PcpUnLock;

protected:

 CDeviceThread* m_pPeripheral;

};

  

и т.д.

grnat

не знаю как это сделать, все понятно с процедурами и функциями с классами вообще без соображений.

kill-still

Так ты даже не начинал чтоли писать?
Ботай тогда
http://www.delphikingdom.ru/asp/viewitem.asp?catalogid=1282

Marinavo_0507

ну насколько я знаю, нету в DLL такого понятия, как классы, соответственно загрузить их нельзя
хотя может в MS что и придумали недавно

kill-still

если в кратце, то абстрактно описываешь класс, потом динамически подгружаешь библиотеку:
  try

    LibHandle := LoadLibrary(fullpath);

    @InitSearch := GetProcAddress(LibHandle, 'InitSearch');

    @DelSearch := GetProcAddress(LibHandle, 'DelSearch');

  except

    STOFMessageDLG('Библиотека '+path+' не найдена, или повреждена. Приложение будет закрыто.',mtError,[mbOK],0);

    Application.Terminate;

  end;

создаёшь объект класа:
IntSearchPointer:=InitSearch;
AIsearcher:=pointer(IntSearchPointer);
и пользуешься дальше им как обычным.

kill-still

в DLL такого понятия, как классы
О_о
омг
*wall*
ну ты дал :)

grnat

как раз сижу и читаю :) тока не давно нашел

kill-still

Велкам, если что-пиши.

slonishka

он прав, это все "умный компилятор". gcc, насколько я понял, тоже так умеет.

Andbar

О_о
омг
*wall*
ну ты дал :)
На сколько я себе представляю, на уровне экспортируемых символов, методы класса превращаются в экспортируемые функции. Естественно, для программиста это проходит незаметно. При этом, компиляторы, использующие разные правила генерации имён классов не совместимы.
Borland поступила иначе и в Delphi-шных bpl-библиотеках экспортируются не классы/функции и т.п., а целые модули. Естественно, этот экспорт работает поверх DLL

Marinavo_0507

Borland поступила иначе и в Delphi-шных bpl-библиотеках экспортируются не классы/функции и т.п., а целые модули. Естественно, этот экспорт работает поверх DLL
Насколько я знаю, борландовские модули с какого-то момента совместимы с COM. Но судя по примеру топикстартера, в его библиотеках никаким COM не пахнет.

SPARTAK3959

Борланд сделала Delphi совместимым с COM, в результате использование COM под дельфи значительно упрощается. Если С++ библиотека имеет интерфейс на уровне классов, но не поддерживает COM, то ее программистам нужно оторвать их кривые руки.

Marinavo_0507

Ого бля, STL фпомойку?

freezer

Если С++ библиотека имеет интерфейс на уровне классов, но не поддерживает COM, то ее программистам нужно оторвать их кривые руки.
это руки надо отрывать, что поддержку COM какую-то делает в плюсовых библиотеках. Это ж непортируемо совершенно.
to : в общем, ничего особо сложного. 1) Из DLL экспортируются методы класса, их имена хитро манглятся, остальное всё делает компайлер 2) в хереде определяется чисто виртуальный класс + невиртуальные инлайн-методы, DLL возвращает указатель (фактически выдает vtbl).
Второй вариант лучше в плане бинарной совместимости разных компиляторов.

SPARTAK3959

Это ж непортируемо совершенно.
Ну а так оно даже на одной платформе не может быть использована без такого же компилятора. Я уж не говорю о том, что автора-то с LoadLibrary переносимость точно не интересует.

Andbar

это руки надо отрывать, что поддержку COM какую-то делает в плюсовых библиотеках. Это ж непортируемо совершенно.
На сколько я понимаю, COM придумали потому, что на плюсах свет клином не сошёлся.
А так, мне встречалась реализация некой COM-подобной системы (написанной на плюсах использующей интерфейсы с GUID-ами, но не использующей системные библиотеки... По идее, при поддержке со стороны компилятора соответствующих языковых конструкций, такая штука может быть собрана не только под винду.

Dasar

это руки надо отрывать, что поддержку COM какую-то делает в плюсовых библиотеках. Это ж непортируемо совершенно.
каким образом поддержка com может мешать портированию?
Оставить комментарий
Имя или ник:
Комментарий: