Re: warnings in Thread library in 1.30.0 release when compiled by VC

From: Sean Huang (yg-boost-users_at_[hidden])
Date: 2003-03-20 19:13:55

Bill,

Thanks for the reply.

>From what I understand (without looking into the detail implemenation of
boost.thread), these warnings can only be safely ignored if we can be sure
we use the same version of  CRT (dll v.s. static). If this is true, then it
essentially means we cannot use boost::thread in applications that
statically link to rtl.

Thanks,

Sean

"William E. Kempf" <wekempf_at_[hidden]> wrote in message
news:2485.167.16.75.51.1048202497.squirrel_at_frodo.kempf-ville.com...
>
> huangsean said:
> > Subject: numerous warnings in Thread library in 1.30.0 release when
> > compiled by VC7.1 (or other vc versions) with warning level 3 or above
> >
> >
> > We're in the process of migrating our project from V1.29.0 to 1.30.0.
> > We are
> > getting a lot of warnings with thread library such as the following:
> >
> > c:\Program Files\Boost\boost\thread\condition.hpp(38) : warning
> > C4275: non
> > dll-interface class 'boost::noncopyable' used as base for dll-
> > interface
> > class 'boost::detail::condition_impl'
> >
> > I know very little about bjam but it looks like it doesn't even
> > use /Wn
> > switch (correct me if I am wrong and the default is /W2. IMHO, it  seems
> > to me that
> > it is always a good practice to set the warning level to at least 3.
>
> I believe it uses the default on all compilers?  I test with VC6, VC7,
> VC71, gcc-nocygwin and the free Borland on Windows, and none of them
> report any warnings.  (Well, Borland reports some "unused variable"
> warnings that I've recently disabled with some brute force command line
> options.)
>
> I don't believe the warning you're reporting is one you should worry
> about... though I can understand the desire to eliminate it from the
> compiler output.  I'll look into it.
>
> > Also,  we would really really like to have the static library option
> > back.
> > :-)
>
> *sigh*  Noted... but I don't think it's likely to happen.  Unless of
> course you (or anyone else) can come up with a viable way to get TLS
> cleanup to function with out a DLL implementation.  With out that,
> maintaining two forms of building is just too much effort, and won't
> really be usable in the next version any way (since thread creation will
> rely on TLS data that needs cleanup).
>
> --
> William E. Kempf
>
>
>
>
> Info: <http://www.boost.org>
> Wiki: <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl>
> Unsubscribe: <mailto:boost-users-unsubscribe_at_[hidden]>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>