From: Ed Brey (brey_at_[hidden])
Date: 2001-01-12 09:15:53
From: "Schaible, Joerg" <joerg.schaible_at_[hidden]>
> >What did you do about the warning messages? (See below.)
> #pragma warning( disable : 4251 ) // needs dll-interface
> // here comes the class definition
> #pragma warning( default : 4251 ) // needs dll-interface
This works most of the time, but not always. The problem is that if the
user had disabled the warning before #including the boost header, he will
find the warning turned back on for him. To get around this, one can use
the warning stack:
// class definition
> >I think I'll just move the timer, etc., implementation into the headers
> >and be done with it. Slightly poorer encapsulation, but much less
> I always vote encapsultaion :)
I concur, primarily on the principle of writing to an ideal compiler and
not letting specific compiler issues diminish the value of boost to users
of other compilers.
OTOH, I realize the value of not having compiler-specific clutter getting
in the way. To that end, I would propose that boost do something similar
to STLport and use a prolog/epilog header where needed. Here's what I
// First line of someboostheader.hpp.
// Class definition and various items that cause warnings.
// End of file.
// First line of detail/prolog.hpp.
// Notice no guards to prevent this file from being processed
// more than once in a translation unit.
#ifdef BOOST_MSVC // do proper version checking here
# pragma warning(push)
# pragma warning(disable:4251)
// First line of detail/epilog.hpp.
# pragma warning(pop)
The usage would be that a boost header could just include config.hpp, as
is done now, or as needed, include prolog.hpp and epilog.hpp. This hides
away all the warning disabling business for the current platform (VC is
just one platform that would benefit), without changing the warning state
as far as the user is concerned.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk