|
Boost : |
From: Moore, Paul (paul.moore_at_[hidden])
Date: 2000-04-20 05:46:24
From: Dave Abrahams [mailto:abrahams_at_[hidden]]
>
> on 4/19/00 10:11 AM, Gary Powell at Gary.Powell_at_[hidden] wrote:
>
> > This library also violates the standard rules about adding things
> > to the namespace std. VTL adds new versions of swap to the std
> > namespace so that callers to std::swap using a view will get our
> > version and not the std version. It's the best of a lot of worse
> > choices.
> >
> > In addition, it violates the rules about forward declarations of
> > container classes. (They are prohibited) These declarations are all
> > in one file, stl_traits.h, so if your compiler has problems
> > with them you can either include the correct files or fix it. The
> > reasoning is that by forward declaring the containers we can
> > reduce the compile time by elimination of unnecessary parsing.
> > All we are interested in is some trait information about the containers.
>
> I don't find these to be worth inducing undefined behavior
> for, and I would avoid using this library for that reason. I
> doubt such a library will find much acceptance in this forum.
On adding stuff to std::, isn't this currently very much a live issue for
debate? As Gary says "it's the best of a lot of worse choices" - I didn't
read this as being a gratuitous violation of the standard, but more a
compromise until the current issues on how to properly extend things like
std::swap for user-defined containers and template stuff is resolved.
On the forward declaration issues, just include the full headers - it's just
a compile time optimisation.
Personally, I have no problem with accepting this for boost, on the basis
that (a) the forward declarations go (maybe leave them as a compile-time
option for people who want to trade safety for compile speed, but definitely
off by default), and (b) there is a clear intention to do "the right thing"
with regard to swap() once it is clear what that is (that may need a
detailed discussion of what the issue is, and why the other choices were
worse).
Paul.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk