Thanks for taking a look at the problem. IMO, distributing objects between inlines and DLL functions is not a very good idea. The classic example is:
It can cause problems but if you are aware of it, then you can work around it quite easily. Part of the reason in speed. Some code can be inlined to optimise things for release builds. This is a good thing IMHO.
Also, some libraries are wholly or partly template based so they can't go completely in a .lib yet. I'm sure there are other reasons that other people could fill you in on.
IMHO, boost needs to get rid of any possibility of this to happen. Why does boost::signal() need a DLL/LIB in the first place? Would not be just the .h file enough?
It could be put in a .h, but there is a lot of code in the library and it makes sense to have it built as a .lib. Perhaps another solution would be for all the inlined code in the header to be moved into the .lib at a loss of performance.
I would just prefer a solution mentioned above where the libs built by boost have different name endings for debug/release multi/single threaded.
But this isn't the whole problem. The other problem is compiler options and such for the structures in the header files. For example, data alignment. boost builds with alignment of 8 for Borland by default. If your app uses another alignment option (we used to use 4 for historic reasons) then when you accessed objects returned from the dll, you would access the wrong offsets for the members because the boost headers don't force options such as this around there structures. I have created a duplicate set of headers for the parts of boost that I use that force compiler options using a #pragma push, then include the boost header, then pop those compiler options. I only ever include my wrappers so that I don't get caught by this and am free to use whatever compiler options I wish for the rest of the project.
Russell
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
