"Rob Stewart" <stewart@sig.com> wrote in message news:200408171530.i7HFUD728557@entwistle.systems.susq.com...
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.
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.
in my iostreams library (to be reviwed later this month). Instead of
typename Source::char_type
I use
boost::io::char_type<Source>::type
If we were to drop the '_type' we would have boost::io::char, which is illegal. Same for int_type. Of course, the convention could be to keep '_type' if necessary, or to use a trailing underscore, but I'd rather
A convention that you add a trailing underscore to keywords should be easy enough to administer and remember.
I didn't make my point very well. The problem is not just that 'char' is not a legal template name, but that when you shave of the _type suffix to eliminate an apparent redundancy you might end up with something with a slightly different intuitive meaning -- increasing the chance that the name has already been used for something else and is not available.
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') Jonathan