Re: [boost] Re: utilities & tuples

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-08-24 09:55:01

----- Original Message -----
From: <jaakko.jarvi_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, August 24, 2001 4:25 AM
Subject: [boost] Re: utilities & tuples

> --- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> > I realize that I suggested that tuples go directly in the boost
> namespace,
> > but I think I'm going to reverse my position, at least in part. I
> wasn't
> > looking carefully at everything in the library when I suggested that
> it go
> > directly in namespace boost. For example, I am concerned about
> functions
> > such as tie, get, and set. It seems to me that those names at least
> should
> > go in a nested namespace.
>
> Dave's previous comments sure influenced in the decision to drop the
> subnamespace :)

Yes; I'm sorry. I guess my words are more dangerous than I thought ;-)
I hadn't had time to look at the contents of the library, so I was just
speaking generally.

> 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:
>
> null_type

   fine in boost

> cons

   I'm not sure about this one. It would be good to use the same thing for
tupel and type_list /if/ it's going to go directly in boost. For tuple, it
stores an element of both the head and tail types. For mpl::type_list, it
would store nothing. We could generalize this with a compressed_pair of
empty type<T> objects, but compressed_pair adds a lot of complexity to
type_list and doesn't even work right all the time on some compilers
(MSVC6). My metaprograms are compiling S-L-O-W-L-Y with GCC 3.0.1 and I'm
reluctant to add anything at the type_list element level of granularity.

> tuple

   fine in boost

> tuple_element
> tuple_access_traits
> tuple_length

   Not documented, are they? This really needs to be done!
   But anyway, tuples::element, tuples::access_traits, tuples::length would
be fine or even better I suppose.

>
> ignore

    Perhaps a bit too generic a name for direct inclusion in boost

> get(cons<HT, TT>&)
> get(const cons<HT, TT>&)

    If these are really as specific as you say (the argument must be a
cons), then they're fine in boost.

> make_tuple() // 0, 1, 2, ... 10 argument versions

    fine in boost

> tie()        // 1, 2, ... 10 argument versions

    fine in boost, IMHO, but this one could be argued either way. tie is
such a savings that boost::tuples::tie(...) is not too odious.

> operator<< and operator>> for cons lists
>
> operator<< and operator>> for tuple_manipulators

  If these only pick up the intended types, then OK.

> set_open(charT), set_close(charT), set_delimiter(charT)

  If these are tuple-specific, then I think they go in boost::tuples

> reference_wrapper
> ref
> cref

    ref and cref are too short, IMO, for boost::. I would be pleased for you
and Peter Dimov to work out the future of the above names, though.

> operator>   // these take two cons lists as arguments
> operator<
> operator==
> operator!=
> operator<=
> operator>=

   Again, as long as they pick up the intended types only, OK. Of course, if
cons<> goes into tuples::, these will have to go as well (Koenig lookup).

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

Better be tuples if tuple is going to be the name of a class.

> 2. Will the most common names remain in boost namespace?

I still hope so.

> 2.1. If yes, which, and are they defined in boost namespace
> or defined in boost::tuple(s) namespace and lifted to boost with
> using declarations.

No opinion yet.

> -----------------
> Other issues:
> > tuples from type lists, etc.), I need to be able to get at the
> underlying
> > cons cells.
> 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> > >

OK. I think cons<> was in detail or something in the pre-release.

> > I also need the following simple constructor in the cons cell
> > which isn't currently supplied:
> >
> >   cons(head_type const& x, tail_type const& y) : head(x), tail(y) {}
> Ok, this can be added.
>
> > Finally, the file boost/tuple/detail/tuple_basic.hpp seems to
> contain some
> > very strange line endings.
> Cleaned.

Thanks!

-Dave