Skip to main content
gamedev.net
🔒 Locked

Strange vector/string problem

Started by Zipster Dec 28, 2004 at 3:47 PM 4 replies 1.2k views
Original Post
Zipster
Zipster
My code is simply this: 

vector<string> CreateVector()
{
   vector<string> theVector;
   theVector.push_back("Arbitrary string");
   return theVector;
}

// ... elsewhere ...
vector<string> someVector;
someVector = CreateVector(); // BREAK
However after the line labeled "BREAK" is executed, I get a user break in my application associated with the destruction of the vector and its string resource(s). Call stack excerpt included for your convenience right here (using wide-character strings, however doesn't work with regular strings either): 

>	AppFrame.dll!_CrtIsValidHeapPointer(const void * pUserData=0x002f5df0)  Line 1807	C
 	AppFrame.dll!_free_dbg_lk(void * pUserData=0x002f5df0, int nBlockUse=1)  Line 1132 + 0x9	C
 	AppFrame.dll!_free_dbg(void * pUserData=0x002f5df0, int nBlockUse=1)  Line 1070 + 0xd	C
 	AppFrame.dll!operator delete(void * pUserData=0x002f5df0)  Line 54 + 0x10	C++
 	AppFrame.dll!std::allocator<unsigned short>::deallocate(unsigned short * _Ptr=0x002f5df0, unsigned int __formal=24)  Line 132 + 0x9	C++
I'm using the stock implementation of STL, but I'm also using MSVC 7.1 which supposedly has a pretty solid implementation. One thing I've noticed is that if I use copy construction for someVector instead of assignment, then the application doesn't break until the vector goes out of scope, but it still happens. And for the pedantic among you ([smile]), this code is only run once during initialization so ignore the abundant copies. It simply makes my life easier.
Enokh
Enokh
Ooooo I know. When you're adding a cell to the vector, you're adding a string literal, (a char[]), and not an actual std::string. Try doing this:

vector<string> CreateVector(){   vector<string> theVector;   string tempString;   tempString = "Hello";   theVector.push_back(tempString);   tempString = "Two";   theVector.push_back(tempString);   return theVector;}


See if that works. If it does then the problem is indeed what I described above.
SiCrane
SiCrane
Are you trying to call your function across DLL borders? If your vector class isn't properly exported, then that is an unhappy operation.
Zipster
Zipster
Enokh: I've tried that and it still doesn't work. It wouldn't make much difference anyway since the vector is templated to take a std::string, so a string literal would be initialized into a std::string by a non-explicit constructor before being pushed.

SiCrane: As a matter of fact, I am doing this across DLL borders [smile] I'm using dynamic linking with an interface design and everything was going fine until this. How, exactly, do I "properly" export a build-in class though (it's a std::vector, don't know if I made this clear or not, hehe). I should mention that CreateVector is a concrete implementation of one of the virtual interface methods, if that helps any. It's being called from the test program (module that created the process), through an interface into the DLL.
SiCrane
SiCrane
How To Exporting STL Components Inside & Outside of a Class
[edit: warning, that link might need to be viewed in Internet Explorer; other browsers tend to display the page funny.]

You'll probably need to export both std::vector and std::string in order for things to work. Also, don't forget all the normal DLL caveats: make sure everything is compiled with the same version of the same compiler, use the DLL version of the C runtime library, etc.

For even more bad news, from what you said, it sounds like you're using LoadLibrary() and so on for your DLL loading needs, in which case you might need to go one step further and put the exports for the vector and string classes in a separate DLL class that both your exe and all your DLLs link against.

If at all possible I'd try to refactor your design to avoid C++ constructs in your DLL interface, especially anything that comes within spitting distance of a template.
Zipster
Zipster
Actually, after making sure that everything was linked against the same runtime (multi-threaded DLL), the problem went away. I should probably still export the classes, but that seems like a pain in the butt and I don't feel like doing it until more problems start [totally]

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.