Thread: Help returning string from dll

std::string* is a pointer to string, you need to return an address to a string object.

std::string is a class and returning it in any way is not a good idea, since you will not be able to use this DLL in any other language or even different compiler version.

I'd recommend passing a 'char*' parameter to the function, which would fill it with necessary data (plus an 'int' parameter for max length), or returning a const char* (worse idea in some cases).

Originally Posted by kmdv

std::string* is a pointer to string, you need to return an address to a string object.

std::string is a class and returning it in any way is not a good idea, since you will not be able to use this DLL in any other language or even different compiler version.

I'd recommend passing a 'char*' parameter to the function, which would fill it with necessary data (plus an 'int' parameter for max length), or returning a const char* (worse idea in some cases).

"Passing a char" i assume you mean change,

Code:

string line;  to
char line;

I get all kinds of errors if i do that, starting in this line,

Code:

getline(Myfile,line);

no matching function for call to `getline(std::ifstream&, char&)'

I also tried converting the string output "line" to a char with line.c_str() and making the fucntion a const char like you said so,

Code:

extern "C" __declspec( dllexport ) __stdcall const char* Trimstr(char* strString)

and although i did get a response form the dll(i'm using VB as a front end), bizzarly enough the data that was returned was the partial name of the VB project i am working in, how it got that i don't know, it's as if it's reading some random memory location and sending that back. It is almost there though i think.

Any suggestions?

Nope, kmdv ment this:

Code:

void foo(char* buffer, int length) {
    // fill buffer, mind it's length
}

You can use std::string internally if you like it (I do ), just copy it over to char* buffer after all is done.

Returning const pointer would work more or less like string::c_str() does, so the library would have to allocate and deallocate it on its side.

You could also take a pointer and allocate memory for it in foo, then return it, but that is error prone solution - memory leaks will occur if you forget to free memory or provide a pointer to already allocated memory. So, I'd say don't do it.

edit: Are you by any chance doing something like this?

Code:

const char* foo() {
    std::string s = "Hello there!";
    return s.c_str();
}

Ever heard of "dangling pointer"? By the time you get the pointer back, the string object is destroyed. Even though the memory is probably unchanged at the moment and it may look like no big deal, it can be claimed and changed any moment now.

The last part makes no sense. You can't fit more than one character in one character, right?

Just to make sure you understand it, the following code is NOT working properly:

Code:

const char* foo() {
    std::string s = "Hello there!";
    return s.c_str(); // kaboom, the pointer won't be valid after return
}

what you want is something like this:

Code:

#include <iostream>
#include <string>
#include <cstring>

int foo(char* buffer, int len) {
    std::string s = "Hello there!";
    // do something
    strncpy(buffer, s.c_str(), len-1); // copy things, but don't overrun buffer
    buffer[len - 1] = '\0'; // 0 terminates the c-string
    return 0; // return error state, e.g. 0 - all good, something else -  bad
    // or maybe return char*, but NULL (or nullptr) on error?
}

int main() {
    char buf[5] = { 0 }; // or dynamically allocated 
    foo(buf, 5); 
    std::cout << buf << '\n';
    
    return 0;
}

You cannot return a std::string without problems as has been mentioned. You also do not want to return a pointer to memory that was allocated inside of a DLL and then de-allocate or call delete on that pointer from outside of the DLL. This will corrupt the heap of the module that is attempting to the clean up because it's CRT does not know about the allocation. Your best bet is to do something like this:

Code:

unsigned int GetStringLength();
void GetString(char *pBuffer,unsigned int length);

The client calls GetStringLength() and then allocates a char array of that size. GetString() is then called by the client and the array it allocated is passed in as a param. The length is passed in as a simple buffer overrun check. Even though the DLL knows the length of the string this type of function could be used to execute a buffer overrun exploit so you will want to pass in the length. Do a memcpy for this length from the DLLs string buffer to the buffer passed to the function. Check to ensure that the length passed in matches the length of the string and only copy at max the length of the string into the buffer. This does not ensure that the array passed in is actually the correct size and the code could still crash if it is not. This will work and it is clunky but it ensures that the client allocates the memory for the resulting string and thus can correctly clean it up and it does not expose the actual string in the DLL to external clients who could then misuse this and wreak havoc. Keep in mind if you wish to return a null terminated string you must allocate an array of sufficient size to accomodate for that.

Understand that the std::string approach will work as long as the client of the DLL and the DLL are guaranteed to use the same version of the STL. So if this is the case you may be wasting cycles solving a problem that may never happen in your program.

Originally Posted by Bubba

You cannot return a std::string without problems as has been mentioned. You also do not want to return a pointer to memory that was allocated inside of a DLL and then de-allocate or call delete on that pointer from outside of the DLL. This will corrupt the heap of the module that is attempting to the clean up because it's CRT does not know about the allocation. Your best bet is to do something like this:

Code:

unsigned int GetStringLength();
void GetString(char *pBuffer,unsigned int length);

The client calls GetStringLength() and then allocates a char array of that size. GetString() is then called by the client and the array it allocated is passed in as a param. The length is passed in as a simple buffer overrun check. Even though the DLL knows the length of the string this type of function could be used to execute a buffer overrun exploit so you will want to pass in the length. Do a memcpy for this length from the DLLs string buffer to the buffer passed to the function. Check to ensure that the length passed in matches the length of the string and only copy at max the length of the string into the buffer. This does not ensure that the array passed in is actually the correct size and the code could still crash if it is not. This will work and it is clunky but it ensures that the client allocates the memory for the resulting string and thus can correctly clean it up and it does not expose the actual string in the DLL to external clients who could then misuse this and wreak havoc. Keep in mind if you wish to return a null terminated string you must allocate an array of sufficient size to accomodate for that.

Understand that the std::string approach will work as long as the client of the DLL and the DLL are guaranteed to use the same version of the STL. So if this is the case you may be wasting cycles solving a problem that may never happen in your program.

Thanks for your help but most of that is over my head, i did however find a function that converts a string to a char,

Code:

char *convertStringToChar(const string &str)
{
    char *retPtr(new char[str.length() + 1]);
    copy(str.begin(), str.end(), retPtr);
    retPtr[str.length()] = '\0';
    return retPtr;
}

and this all seems to work, also if i add a MessageBox in the code(for debugging purposes) it does show the right "line" from the text file when calling it from VB, however in the next line when the dll actually tries to return the (now char) data back to VB, well VB crashes giving me the error, "The instruction at "xxxxxx" referenced memory at "xxxxxxx". The memory could not be read. I know i am declaring the function correct in VB as there is only one way to do so. Here is what i have, any more ideas?

Code:

using namespace std;


BOOL APIENTRY DllMain (HINSTANCE hInst, DWORD reason, LPVOID reserved){
    return TRUE;
}

char *convertStringToChar(const string &str)
{
    char *retPtr(new char[str.length() + 1]);
    copy(str.begin(), str.end(), retPtr);
    retPtr[str.length()] = '\0';
    return retPtr;
}


extern "C" __declspec( dllexport ) __stdcall  const char* sSearch(char *);

extern "C" __declspec( dllexport ) __stdcall  const char* sSearch(char* strString)

{
    
    char* search = strString; // search pattern
    int offset;
    string line;
    ifstream Myfile;
    Myfile.open ("c:\\example.txt");
    
    if(Myfile.is_open())
    {
        While (!Myfile.EOF())
        {
            getline(Myfile,line);
            if ((offset = line.find(search, 0)) != string::npos) {
                //cout << "found '" << line <<endl;
                char *dPtr(convertStringToChar(line));
                MessageBox(NULL, dPtr, NULL, NULL);  // This (dPtr) give the correct result i have successfully converted a string to a char
                return dPtr;   //  This crashes my VB app
            }
        }
        Myfile.close();
    }

    return 0;
}

Returning a raw pointer should not cause memory access violation, something must be wrong in the main application. We have already told you not to return a pointer. Your function convertStringToChar() returns a POINTER to char, not char, I noticed you don't distinguish these two completely different things. Learn about pointers.
This function creates a memory leak, because it allocates necessary amount of memory but does not free it (there should be an appropriate call to delete[]). The only way I see returning a pointer is creating a global buffer.

While (!Myfile.EOF())

What is this? What is 'While' and what is 'EOF'. It is 'while' and 'eof'. I don't even know how it can compile (with default compiler settings).

And how the hell did you want to manage std::string with visual basic?

but most of that is over my head

Then ditch the multi-DLL approach because you are not ready for it. Compile everything into the same exe via static libraries. DLLs are actually very simple to use but there are a few ground rules you must follow or should follow (depending on your usage) and this is a result of the way in which DLLs are treated in the Windows operating system.

Since we're talking about DLLs, can i ask something relevant?

At a project i found on the net i discovered two small classes called Allocator and AllocatorFast. The former used virtual functions to allocate and free memory, while the latter did it directly. The docs say that the first can be used across dll boundaries while the second can't! Why's that?

Here's the file. It's from the Irrlicht SDK.

Originally Posted by rm78

I have a theory that one day all proramming lanaguges will become extinct as soon you will just be able to speak into a microphone and some clever app will auto convert your voice into the code you wan't. Thanks again.

Who's gonna make/debug/fix/maintain this clever app? I know!...