From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-03 07:28:58
----- Original Message -----
From: "Jaakko Järvi" <jaakko.jarvi_at_[hidden]>
> Rest of such names are functions/operators that are fetched based on the
> namespace of their arguments. The remaining names are metafunctions etc.
> and not meant to be used by 'Joe the Programmer'.
> So particularly, cons lists, and names like tuple_element<N>,
> can stay under boost::tuples (and their names can be changed to
> tuples::element<N> ...),
> as well as the tuple specific io manipulators.
All good so far...
> Further, streaming and comparison operators are under a subnamespace as
std::cout << make_tuple(3, "hello") // error?
if (make_tuple(3) > make_tuple(7)) // error?
> The points in favor for using using declarations to lift the common
> names into
> boost namespace, instead of defining them directly there are:
> - tuple and cons stay in the same namespace
> - functions that operate on tuples/cons list can be
> defined under boost::tuples.
I have no problem with reserving functions like streaming operators, etc. in
boost, so long as their argument types are specific enough to prevent lookup
problems. I think that if you don't put tuple and cons in the same namespace
with the operators that work on them, we may have problems. Although Koening
lookup works on the namespace of base classes, it looks first in the
namespace of the derived class. Won't it ignore operators in boost::tuples
if it finds the name in boost ?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk