Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-08-13 14:04:30


"Thorsten Ottosen" <nesotto_at_[hidden]> writes:

> "David Abrahams" <dave_at_[hidden]> wrote in message news:ullgj9dly.fsf_at_boost-consulting.com...
> | Daniel Frey <daniel.frey_at_[hidden]> writes:
>
> | > I agree. Also, the user can use namespace aliases to shorten calls,
> | > which doesn't work with range_.
> | >
> | > The difference for the user is also quite minimal, but using
> | > namespaces might also help to keep the library "cleaner" internally,
> | > as the algorithms in range:: can call each other without long names.
> |
> | Are we sure we want boost::range to be a namespace and not a class or
> | a template, forever?
>
> no.

Following the tuples library convention, the namespace would be
"ranges".

> | I had a horrible thought: boost::range_traits::value<R>::type
>
> :-) (btw, how would you follow that in the iterator lib? std::iterator_traits is already there)

Right.

> The primary motivation for the namespace version seems to be
> shortening of names.

That doesn't seem very compelling to me.

> So we can go from range_ to r::. so we save 3 chars. is that really
> worth the trouple?. Of course, other namespace can be much longer,
> but reasonable and short prefixes should be plenty; however it might
> also be worth something that a name can never be shortened, ie, it
> brings a certain consistency into the picture.

In this particular case, I think you could make a good argument that
these traits (for iterators and ranges) are really the same,
semantically. Maybe that solves some problems?

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

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