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?
Following the tuples library convention, the namespace would be
> | 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)
> 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