DLL Returning char *

J

Joey Sabey

Hey, I've got a bit of a strange problem caused by a situation I'm in.
I'm writing a DLL for a friend of mine in C++, and he plans to use it
in delphi. The DLL needs to return strings, and we doubt that a string
would return well to a delphi program, so the only thing I could think
of was returning a char*, which obviously would be very dangerous as
the array would be being declared as a local variable and would only be
returning it's address.
Anyway, anyone know a solution to such a problem? I can't think of
anything myself, as I'm not that an experienced C++ programmer as it
is, and the whole delphi aspect complicates things for me, as I know
nothing of it.
 
O

Ondra Holub

Joey Sabey napsal:
Hey, I've got a bit of a strange problem caused by a situation I'm in.
I'm writing a DLL for a friend of mine in C++, and he plans to use it
in delphi. The DLL needs to return strings, and we doubt that a string
would return well to a delphi program, so the only thing I could think
of was returning a char*, which obviously would be very dangerous as
the array would be being declared as a local variable and would only be
returning it's address.
Anyway, anyone know a solution to such a problem? I can't think of
anything myself, as I'm not that an experienced C++ programmer as it
is, and the whole delphi aspect complicates things for me, as I know
nothing of it.

Hi. I think it is question more related to some delphi forum. If you
are using only C interface for your shared library, it should be
accessible by other languages. Most modern languages have some
capability to call routines written in C/C++.
 
J

Joey Sabey

Ondra said:
Hi. I think it is question more related to some delphi forum. If you
are using only C interface for your shared library, it should be
accessible by other languages. Most modern languages have some
capability to call routines written in C/C++.

Well, it might be more suited there, but I doubt it, as I am writing
the thing in C++, and they would likely not be able to help... I might
try looking for a delphi place to ask though...
 
D

Dennis Jones

Joey Sabey said:
Well, it might be more suited there, but I doubt it, as I am writing
the thing in C++, and they would likely not be able to help... I might
try looking for a delphi place to ask though...

In the future, a good bet for getting answers that relate to both Delphi AND
C++ is to ask in one of the C++Builder forums since most C++Builder
developers are also generally knowledgeable in Delphi.

To answer your question, Delphi has a "pchar" (pointer to string) type which
is the equivelent of a "char *" in C/C++. But, as you have surmised, you
should not return a char * as a reference a local string in the DLL back to
the EXE, but this would be true no matter what lanaguage the executable was
written in (not just Delphi). For any function that needs to return a char
*, you should have it accept two arguments: a char *, to which you would
copy the string, and a size parameter that specifies how big the buffer is:

void SomeFunc( char * str, int size )
{
strncpy( str, "some text", size-1 ); // don't write past the end of the
given buffer!
str[size-1] = '\0'; // make sure the string is null-terminated!
}

The Delphi program would then call this function passing a 'pchar' (pointer
to some buffer) and a buffer size argument. The Delphi program would own
the memory to the buffer, so you don't have to worry about memory
allocations going across the DLL/EXE boundary.

Then of course, you have to make sure the function is exported by the DLL
and usable by Delphi. To do this, the function must use the standard
calling convention, and must be declared as exportable:

extern __declspec( dllexport ) void __stdcall SomeFunc( char * str, int
size );

To use this function, the Delphi program must define an equivelent prototype
and import the function from the DLL:

SomeFunc : procedure( str : pchar; size : integer ); stdcall;

SomeFunc := GetProcAddress(GetModuleHandle('yourdll.dll'), 'SomeFunc');

I am a C++Builder developer (but by no means a Delphi expert) and none of
the code above has been tested, but it should provide you with enough
information to get you started.

- Dennis
 
J

Joey Sabey

Dennis said:
For any function that needs to return a char
*, you should have it accept two arguments: a char *, to which you would
copy the string, and a size parameter that specifies how big the buffer is:

Problem is that the EXE doesn't know how big the data back is gonna be,
it could be small, or a lot bigger, meaning you'd have to pass a very
large, and inefficient, buffer... I doubt that'd would help at all.

Would packing the data into a struct or something help at all..?
 
D

Dennis Jones

Joey Sabey said:
Problem is that the EXE doesn't know how big the data back is gonna be,
it could be small, or a lot bigger, meaning you'd have to pass a very
large, and inefficient, buffer... I doubt that'd would help at all.

Would packing the data into a struct or something help at all..?


No, but you could do like some Windows API functions do and have the
function return the size of the needed buffer. So something like this very
simple example:

int SomeFunc( char *str, int size )
{
char text[] = "some text";
int reqsize = strlen( text ) + 1;

if ( str != NULL && size >= reqsize )
{
strncpy( str, text, size-1 );
str[size-1] = '\0';
}
return reqsize;
}

Now the caller can call SomeFunc() with either a null pointer or an
insufficiently sized buffer and your function will return the necessary
buffer size:

int bufsize = 0;
char *somebuffer = NULL;

int reqsize = SomeFunc( NULL, 0 ); // how much space do we need?
bufsize = reqsize;
somebuffer = new char[bufsize]; // allocate it

reqsize = SomeFunc( somebuffer, bufsize );
if ( reqsize <= bufsize ) // somebuffer was both non-NULL and big enough
to hold the data
{
// use somebuffer
}

- Dennis
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,770
Messages
2,569,586
Members
45,088
Latest member
JeremyMedl

Latest Threads

Top