From: Russell Hind (rhind_at_[hidden])
Date: 2003-08-04 12:38:12
E. Gladyshev wrote:
>
>
> 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