Re: [boost] Re: Re: the boost::signal sample crashes

From: E. Gladyshev (egladysh_at_[hidden])
Date: 2003-08-04 13:07:02

--- Russell Hind <rhind_at_[hidden]> wrote:
> E. Gladyshev wrote:
> It can cause problems but if you are aware of it,
> then you can work 
> around it quite easily.  

IMO, I should be able to just use the library w/o this
kind of workarounds. It is hard to debug these .lib/.h
conflict issues.

> > 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.  

I think that it doesn't make sense if we have all
these problems that you are talking about below. If
the user wants to speed the compile-time up, he/she
can always create a simple wrapper around the standard
signal.h.

> 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 never do it.

> 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.

Forgive me but it seems insane to me that we make
boost users to go through all this hell with .lib
files.
I am really worried about the road the boost comunity
has choosen just to reduce the compile time.  Please
let the user to reduce the compile time (making his
custom wrappers) any way he/she likes it. I want to be
able to just include a .h file w/o having to verify
that my program won't break from time to time because
of some .lib/.h conflicts enforced on me by boost
developers.
On the side note: this boost road already lead to the
fact that the boost::thread library is not up-to-date
anymore. Win32 supports two threading models that can
be used in one application at the same time. 
boost::thread doesn't allow it.  I think if we
continue down this road, boost will be in a big
trouble becoming a true industry standard (at least
for some of its components).

IMHO boost::signals should be in a .h file completely.
I can always reduce the compile time myself if I need
to.

Eugene

__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com