"Jonathan Turkanis" <technews@kangaroologic.com> writes:
"Rob Stewart" <stewart@sig.com> wrote...
From: "Jonathan Turkanis" <technews@kangaroologic.com>
"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message:
range::size<R>::type range::difference<R>::type
I don't like dropping the '_type' here -- One of the main advantages of a naming convention is that you can figure out what the name should be without consulting the docs. Consider a nearly identical situation
The duplication, "..._type<...>::type," seems silly, though, doesn't it?
I guess it depends if you focus on how it looks when you're using it or defining it.
I'm ambivalent. value_type<Foo>::type looks silly, but people are familiar with value_type as value_type and reference as reference. There's gonna be reference<Foo>::type.
Having said that, the "_type" can simply be construed as saying that the type is a type generator, and the "::type" as the generated type. What's more, while the entire expression is meaningful, the class template isn't well named.
Yes. To me, calling the metafunction 'size' seems as misleading as calling the member type 'size' instead of 'size_type'. This name is better reserved for a function returning the actual size of a collection.
Right.
I think range_xxx and ranges::xxx are about equally good. I don't really like the convention of forming namespace names by adding 's' --
I think that's a really good convention. For example, boost::tuples is the namespace for the code from which one can create tuple types. That is, various specializations of boost::tuple.
Yes, I know it's an existing convention, and I agree that it's good to have some convention. The namespaces formed by adding 's' just sounds funny to me. So I'm in favor of using 'ranges' for the namespace associated with range, if such a namespace is needed, but if it's debatable whether to use a namespace, I'm inclined to avoid the awkwardness of the name.
However, this convention is the opposite of the detail namespace which I think should be named "details" instead since it holds more than one implementation detail.
Oddly, 'details' seems more natural to me than 'detail'. I guess it's because 'detail' actually contains details, whereas 'tuples' doesn't contain tuples (it contains 'tuple')
And in the near future we may end up with totally unrelated names; the contents of boost::fusion will supplant those of boost::tuples. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com