Thread: goto

Originally Posted by Bubba

Another issue I have with boost has to do with the templates. I realize the only way to create a library such as boost is to use templates but this makes using them in projects with multiple DLLs a major issue. You can't return boost::weak_ptr's or boost::shared_ptr's across a DLL boundary. What you end up with is a system which resides in a DLL which either hands out handles to the objects or hands out raw pointers to them. Handing out raw pointers here is a very bad idea indeed since if delete is called on said pointers and those pointers were created in the DLL, the CRT of the caller will be pretty much hosed. So you will end up passing out handles to boost::shared_ptr's that really do nothing. Since you are using handles you might as well store raw pointers inside the container and forego boost altogether. Boost is fine when used in the same module but cannot be used effectively across multiple modules even using the PIMPL idiom - which you must do or you will get a warning similar to: clients of xxx must have a dll-interface to access templated member<X> Of course this type of system could be re-factored so it actually factories out the object in the CRT of the caller instead of the DLL but it's just an illustration of some issues.

Are you sure about that? If I remember correctly, the only issue with sharing boost smart pointers across DLLs is when the DLL that created the underlying object is unloaded before the object is destructed.

Originally Posted by bithub

Are you sure about that? If I remember correctly, the only issue with sharing boost smart pointers across DLLs is when the DLL that created the underlying object is unloaded before the object is destructed.

I think the problem is that each DLL has its own heap, which means if the ref count goes to zero in a different module it will attempt to delete the object (and the refcount, which is tracked separately) from the wrong heap.

Originally Posted by brewbuck

I think the problem is that each DLL has its own heap, which means if the ref count goes to zero in a different module it will attempt to delete the object (and the refcount, which is tracked separately) from the wrong heap.

But how is that different than the following (which you see in libraries all the time).

Code:

// Caller is responsible for freeing up memory
char* some_dll_function(void)
{
    return malloc(100);
}

Originally Posted by bithub

But how is that different than the following (which you see in libraries all the time).

Code:

// Caller is responsible for freeing up memory
char* some_dll_function(void)
{
    return malloc(100);
}

I dunno. It's just a wild guess. I'm probably wrong.