Thread: Help returning string from dll

It appears that those allocators are supposed to reside on the client side but are provided by Irrlicht. Neither of those classes are exported. Also the first class seems to wrap the new but yet performs the same exact call as the second class only in a private function. I have no idea why they say one is safe and one is not or why it matters when none of them are exported.

You can use a reference counted smart pointer as long as when the pointer goes out of scope it calls the DLL to clean up the memory. This is a very specific type of smart pointer relative to the DLL or relative to DLLs that match a certain interface so boost would not work...that is....unless you made use of it's custom deleter. The DLL can provide a specific smart pointer template class that is to be used by clients of the DLL yet the DLL does not have to export the template. It is a convenience header provided by the DLL.

What i was really trying to do is comapre the speed of VB vs C++ to open a file and search for a string. Obvioulsy i am not using pure c++ but accessing it via a dll.

Then why do you need a pointer to the string at all?

C++ is hard, .NET should supercede it though.

Hard does not mean useless. Both will co-exist quite nicely for a very long time. I will also predict that .NET will either die, change completely, or be moved to a newer shinier technology by MS long before C++ goes the way of the dodo. C# will probably be in less flux since it is ECMA certified but I assure you .NET will be in a constant state of flux so long as MS is continuing to work on it. .NET is not a language so comparing it to C++ is an incorrect comparison. .NET is a framework. You seem to have a few misconceptions about C++ and about .NET.

Who needs C++ anymore??

I hope this is sarcasm.

Originally Posted by Sipher

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?

Because every modern compiler supports COM, which relies on virtual tables. And you don't need to use COM in your application, I mean, you can create your own interfaces without inheriting IUnknown and you will be able to use them across dll boundaries.

kmdv: That's the reason then! Interesting!

EVOEx: What if the app has a bug because of which it can't fix it? ( i know it sounds crazy, but in the world of programming many crazy things occure all the time )

Because every modern compiler supports COM, which relies on virtual tables. And you don't need to use COM in your application, I mean, you can create your own interfaces without inheriting IUnknown and you will be able to use them across dll boundaries.

It is a simple rule. If you allocate in the DLL, de-allocate in the DLL. Whatever constructs make this possible will work. Whatever constructs do not follow this will not work. Memory that is managed inside the DLL should not be exposed outside of the DLL unless there is a mechanism in place that allows clients to use said memory safely. Safely as in they are not allowed to clean it up. Pointers into DLLs work perfectly but the danger is that a client will call delete on the pointer. Obviously this would be stupid to do but the DLL should provide some abstractions that make this harder to do if it is going to provide public methods that return pointers to memory in the DLL.

Of course! After all, a DLL is a shared object, right? If you delete something, the other applications that use it won't have a clue!