overload в dll

← →
Gu (2011-12-21 03:43) [0]

в моей dll имеются функциии

Function MyFunc(const X:Integer):string; Overload; StdCall;
Function MyFunc(const X: Extended):string; Overload; StdCall;
...
Function MyFunc(const X:Integer):string;
begin
result:=Inttostr(x);
end;

Function MyFunc(const X: Extended):string;
begin
result:=Floattostr(x);
end;

Вопросы:
1. Имеет ли значение как написать: Overload; StdCall; или StdCall; Overload; ?
2. Будет ли возможно корректное использование таких функций из этой длл в приложениях на других языках, например VB, C++, C# ?
3. Возможно ли экспортировать эти функции под одним именем ?

← →
MBo © (2011-12-21 05:32) [1]

Нет. Нет. Нет.

И идею с перекрытием по типу параметра Float/Int я бы не считал удачной.

← →
Dimka Maslov © (2011-12-21 09:43) [2]

В С++ вообще нет типа extended

← →
Сергей М. © (2011-12-21 09:48) [3]

2. VB, C++, C# ничего не знают про дельфийский тип String

← →
Dennis I. Komarov © (2011-12-21 12:49) [4]

string в dll не по феншую...

← →
Gu (2011-12-21 14:54) [5]

какой аналог для string (Dll пишется в Xe) лучше? shortstring,ansistring,pchar (он теперь кстати не простой),pointer? или еще что?

чтобы

>> 2. VB, C++, C# ничего не знают про дельфийский тип String

знали?

← →
MBo © (2011-12-21 15:01) [6]

Никакого аналога string в Сях нет. Про дельфийские строки знает только Builder.

Можно обмениваться PChar-ным семейством и WideString (убедившись, что вторая сторона знает про COM-овские BSTR)

← →
Gu (2011-12-21 15:05) [7]

WideString ща вроде и есть string (ну почти или ansistring), имеется ввиду Xe и xe2

← →
MBo © (2011-12-21 15:43) [8]

>WideString ща вроде и есть string

начни уже справку почитывать:
http://docwiki.embarcadero.com/RADStudio/XE/en/String_Types

← →
Ega23 © (2011-12-21 16:43) [9]

> какой аналог для string (Dll пишется в Xe) лучше? shortstring,
> ansistring,pchar (он теперь кстати не простой),pointer?
> или еще что?
>
> чтобы
>
> >> 2. VB, C++, C# ничего не знают про дельфийский тип String
>
> знали?
>

Адрес буфера + его длина. Ну и соглашение, что это у тебя: ansi-строка, юникод-строка, либо ещё какая-нить экзотика.

← →
DiamondShark © (2011-12-21 17:53) [10]

> Адрес буфера + его длина. Ну и соглашение, что это у тебя:
> ansi-строка, юникод-строка, либо ещё какая-нить экзотика.

А ещё общий менеджер памяти запилить.

← →
DVM © (2011-12-23 10:31) [11]

> Gu (21.12.11 03:43)

Как уже сказали, от функций вида
function MyFunc(const X: Integer): string;
придется отказаться, если DLL планируется использовать в других языках, отличных от Delphi. И даже в Delphi для того, чтобы экспортировать подобную функцию надо прибегать к помощи ShareMem или вообще отказаться от Dll в пользу пакетов.

Просто заменить string на PChar или PAnsiChar нельзя, т.е:

function MyFunc(const X: Integer): PAnsiChar; - так неправильно.

Если так сделать, то получается, что память под строку должна будет выделять Dll (что разумеется она может сделать), но сразу возникнет другой вопрос, кто эту память будет освобождать и главное как?
Вызывающая программа ничего не знает о работе менеджера памяти, который используется внутри Dll и соответственно не может правильно освободить эту память. Частичным решением этой проблемы может стать экспортирование из Dll некой функции MyFreeMem(Buffer: PAnsiChar; BufferLen: integer), которая внутри себя вызывает функцию освобождения памяти внутри Dll, но такой способ на мой взгляд неудобен.

Гораздо правильнее, на мой взгляд, следовать простому правилу: память выделяет и освобождает приложение, а в Dll передается лишь указатель на буфер и его длина.

В общем же случае, советую поглядеть как сделано в WinApi и делать по аналогии. Подавляющее большинство функций WinApi возвращающих строки НЕ ВЫДЕЛЯЮТ сами память под строку, а принимают указатель на буфер + его размер. Например, можно сделать так:

function GetMyString(Buffer: PAnsiChar; BufferLen: Integer): integer;

Данная функция принимает указатель на уже выделенный буфер и заполняет его. При этом она возвращает количество реально записанных в буфер байт (с учетом нулевого завершающего символа или без, как уж решишь). Если окажется, что размер буфера недостаточный, то функция может, например возвращать ошибку -1. Также можно предусмотреть возможность получения с помощью этой же функции необходимого размера буфера, например, передавая первым параметром в нее nil, тогда она возвращает необходимый размер.

Кроме этого, возможно стоит сделать 2 варианта этой функции GetMyStringA и GetMyStringW если планируется возвращать Ansi (для не поддерживающих Unicode программ) и Wide (для поддерживающих). При этом функция GetMyStringA может быть оберткой к GetMyStringW автоматически преобразующей даные в/из юникод.

← →
Медвежонок Пятачок © (2011-12-23 10:45) [12]

Гораздо правильнее, на мой взгляд, следовать простому правилу: память выделяет и освобождает приложение, а в Dll передается лишь указатель на буфер и его длина.

Уж лучше по старинке,

function get_something(buff : pchar; var len: dword) : longint;

первый вызов - буфер нил, затем выделение памяти по len и второй вызов c реальным буфером.

"как учили в автошколе"

← →
Gu (2011-12-23 11:02) [13]

> DVM © (23.12.11 10:31) [11]

Большое спасибо за такой полный ответ. Буду думать

← →
han_malign (2011-12-23 11:51) [14]

> Как уже сказали, от функций вида
> function MyFunc(const X: Integer): string;
> придется отказаться, если DLL планируется использовать в
> других языках, отличных от Delphi.

- можно не отказываться(см. MBo [6]), только привести к каноническому виду:
function MyFunc(X: integer): WideString; safecall; HRESULT __stdcall MyFunc(int X, [out,retval] BSTR * result);

- хост-приложение, естественно, должно знать о контракте использования BSTR(SysAllocString/SysFreeString)...

← →
Gu (2011-12-23 11:58) [15]

> han_malign (23.12.11 11:51) [14]

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

эээ. а можно где то хотябы поверхностно о соответствии типов языков почитать, или они уже давно безвозмездно утеряны? ;(

← →
Ega23 © (2011-12-23 13:24) [16]

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

Строгое соответствие типов есть у Char, AnsiChar, unsigned int8, signed int8 (и то же самое для int16, int32 и int64). GUID ещё. Ну и pointer, как 32 так и 64 (второе - не всегда).
Вот, собственно, и всё.
А всякие Boolean, Enum, Interface, string, PChar, и т.д. - строгого соответствия не имеют.

← →
Gu (2011-12-23 16:40) [17]

>> есть у Char, AnsiChar
возможно было
Предлагаю без обсуждения начинать вопрос с того - что Delphi=Xe

← →
Ega23 © (2011-12-23 16:53) [18]

> Предлагаю без обсуждения начинать вопрос с того - что Delphi=Xe

Вопрос был какой? О типах данных, так? Которые распознаются разными другими ЯП. Delphi - это delphi. PHP - это PHP. С++ - это С++. Со всеми своими заморочками, менеджерами памяти и т.п. Тип (magic-class, class) "string" есть у всех. А как он реализован, плюс как реализованы операции с ним - зависит от.
Стандарта на этот счёт нет. В общем виде - есть адрес буфера данных и его длина.

← →
Inovet © (2011-12-23 16:56) [19]

> [2] Dimka Maslov © (21.12.11 09:43)
> В С++ вообще нет типа extended

Куда же он делся? Называется только
long double

← →
Gu (2011-12-23 21:11) [20]

на счет цивер както договоримся, больше волнует вопрос со строками.
есть ли тут люди, которые гарантировано смогут сказать, то в Vb и C++/C# строки имеют "такоето представление" (если вообще они там есть - но подобие должно быть). Отдельно интересует вопрос анси (пусть хотяюы shortstring) и юникода (пусть хотябы тойже размерности в длинну что и наси). И что там с двухбайтовыми чарами в строке. ПЧар вариант интересный был, но нсколько понимаю - сейчас он не поктит (сруктура изменена), говорим о Xe/2

> [20] Gu (23.12.11 21:11)
> Vb и C++/C# строки имеют "такоето представление" (если вообще
> они там есть - но подобие должно быть)

А Фортран и Брайнфак не надо чтобы работали с этой ДЛЛ? Тебе уже сказали что передавать надо указатель на буфер, но это же ответ не на тот вопрос который ты задал, а поучения ьебя и чесание ЧСВ, выражаясь твоими словами.

library Project1; { Important note about DLL memory management: ShareMem must be the first unit in your library"s USES clause AND your project"s (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } uses SysUtils, Classes; {$R *.res} begin end.

Читал? Или опять кругом все виноватые?
200 раз сказали уже, НЕ НАДО... СМОТРИ WINAPI... ТАК ВИНДА УСТРОЕНА...

← →
Gu (2011-12-24 02:01) [24]

Читал. В делфях обойдемся SimpleShareMem. Но эта шштука как раз для вещей длс строк нужна (а можит и вообще не понадобится, если альтернативу делать)

Вот пока вопрос:

> Gu (23.12.11 21:11) [20]

> Вот пока вопрос:
>
> > Gu (23.12.11 21:11) [20]
>

Если уж ты просишь уважительно к тебе (и к твоим вопросам) обращаться, то уж, пожалуйста, изучи русский язык, хотя бы на уровне (5-6)-го классов общеобразовательной российской школы!

Покажи, где в генофонде экспортируется функция с типом string (из винды).

> [24] Gu (24.12.11 02:01)
> Вот пока вопрос:
>
> > Gu (23.12.11 21:11) [20]

На него ответили.

overload в dll Найти похожие ветки