Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-08-24 06:41:29


From: <jaakko.jarvi_at_[hidden]>
> Dave's previous comments sure influenced in the decision to drop the
> subnamespace :) But ok, let's bring the issue up again.
> Before jumping into moving the stuff back to a subnamespace, I'd be
> happy if we could reach a (new) firm conclusion.
>
> All interested, please read the 'About namespaces' section in the
> tuple design decisions rationale for some
> background.
>
> http://www.boost.org/libs/tuple/doc/design_decisions_rationale.html
>
> Also, below is a list of names, that the library currently adds to
> boost namespace:

[...]

My first reaction is that the compile-time list support should probably be
factored out into a submodule. Many of the tuple_* operations are actually
list operations; a compile-time list library would be useful for template
metaprogramming, although I don't know how this will be affected by the
upcoming boost::mpl.

> reference_wrapper
> ref
> cref

Of course I think that these should stay in boost::. I've already factored
them out in boost/ref.hpp; they are of general utility (not tuple-specific)
and are used by Bind as well.

> So if tuples go back to a subnamespace, the questions are:
>
> 1. What is the name of the namespace (tuples or tuple?)

A possible alternative is to define a tuple namespace and a nested class
template named 'type'; a tuple will then be referred to as

tuple::type<X, Y> t;

> Tuple has a typedef 'inherited' which gives the underlying cons list
> type, e.g.:
> tuple<A, B, C>::inherited equals cons<A, cons<B, cons<C,null_type> > >

Have you considered tuple<...>::list_type?

--
Peter Dimov
Multi Media Ltd.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk