"Neal D. Becker" <ndbecker2@verizon.net> wrote in message news:cffllo$r72$1@sea.gmane.org... | Minor typo: | The example for sub_range says: | | typedef sub_range sub_string; | | But sub_range is a template class, so sub_range is not a valid type. hmm...that appears to be an old file. There should be a newer version with color-coding an all. br Thorsten

From: David Abrahams <dave@boost-consulting.com>

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

...

The boost iterators new iterator traits has this naming scheme:

iterator_value<T>::type iterator_difference<T>::type

I have used this scheme (originally proposed by Peter Dimov)

iterator_of<T>::type value_type_of<T>::type.

The question is now if the range librray should do as the iterator library, ie, prefix everyhitng with "range_":

range_iterator<T>::type range_value_type<T>::type

We chose "iterator_value" et al because we couldn't be sure that someone wouldn't need to make another concept Q in boost that had its own, separate notion of an value_type. If you then had a type X that fulfilled both the Iterator and Q concepts, how would you specialize value_type_of?

It "iterator_of" and "value_type_of" were in separate namespaces for the separate concepts, then they could be qualified or not as the user sees fit using namespace aliases, using directives, and full qualification. That would yield common names across concepts with the qualification -- like much of the other related code for the concepts -- the differentiator. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:

| > We chose "iterator_value" et al because we couldn't be sure that | > someone wouldn't need to make another concept Q in boost that had its | > own, separate notion of an value_type. If you then had a type X that | > fulfilled both the Iterator and Q concepts, how would you specialize | > value_type_of? | | It "iterator_of" and "value_type_of" were in separate namespaces | for the separate concepts, then they could be qualified or not as | the user sees fit using namespace aliases, using directives, and | full qualification.

exactly. this at least one benefit of using namespace + _of postfix over prefixing with range_. If the namespace is hidiously long, the user can remove it or shorten it.

but I would like to hear more voices on this issue :-)

boost::iterators::value<I>::type boost::iterators::reference<I>::type boost::ranges::value<R>::type and so forth? -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

"Thorsten Ottosen" <nesotto@cs.auc.dk> wrote in message news:cfgf91$2l4$1@sea.gmane.org... | "David Abrahams" <dave@boost-consulting.com> wrote in message news:ullgkdxb0.fsf@boost-consulting.com... | | | | boost::iterators::value<I>::type | | boost::iterators::reference<I>::type | | | | boost::ranges::value<R>::type | | | | and so forth? | | good idea to rename value_type<I>::type value<T>::type :-) | I guess we should do that with | | range::size<R>::type | range::difference<R>::type | | too. I'm having second thoughts. It seems a little irritating to specify in a concept that the metafunctions reside in namespace X. I guess the issue boils down to these choices: typename range::value<T>::type typename range::iterator<T>::type typename range::const_iterator<T>::type typename range::difference<T>::type typename range::size<T>::type typename range::reverse_iterator<T>::type typename range::const_reverse_iterator<T>::type typename range::result_iterator<T>::type typename range::reverse_result_iterator<T>::type typename range_value<T>::type typename range_iterator<T>::type typename range_const_iterator<T>::type typename range_difference<T>::type typename range_size<T>::type typename range_reverse_iterator<T>::type typename range_const_reverse_iterator<T>::type typename range_result_iterator<T>::type typename range_reverse_result_iterator<T>::type or with full qualification typename boost::range::value<T>::type typename boost::range::iterator<T>::type typename boost::range::const_iterator<T>::type typename boost::range::difference<T>::type typename boost::range::size<T>::type typename boost::range::reverse_iterator<T>::type typename boost::range::const_reverse_iterator<T>::type typename boost::range::result_iterator<T>::type typename boost::range::reverse_result_iterator<T>::type typename boost::range_value<T>::type typename boost::range_iterator<T>::type typename boost::range_const_iterator<T>::type typename boost::range_difference<T>::type typename boost::range_size<T>::type typename boost::range_reverse_iterator<T>::type typename boost::range_const_reverse_iterator<T>::type typename boost::range_result_iterator<T>::type typename boost::range_reverse_result_iterator<T>::type I think my personal view would be that I think range_ reads better than range::. Too many :: and it seems a bit confusing. br Thorsten

Thorsten Ottosen wrote:

| | | | boost::iterators::value<I>::type | | boost::iterators::reference<I>::type | | | | boost::ranges::value<R>::type | | | | and so forth? | | good idea to rename value_type<I>::type value<T>::type :-) I guess we | should do that with | | range::size<R>::type | range::difference<R>::type | | too.

I'm having second thoughts. It seems a little irritating to specify in a concept that the metafunctions reside in namespace X.

I guess the issue boils down to these choices:

typename range::value<T>::type [snip]

typename range_value<T>::type [snip]

or with full qualification

typename boost::range::value<T>::type [snip]

typename boost::range_value<T>::type [snip]

I think my personal view would be that I think range_ reads better than range::. Too many :: and it seems a bit confusing.

I'm personally prefer to use namespaces to structurize the code, i.e. the typename range::value<T>::type notation. The range_value<T>::type notation unneededly clutters the 'global' boost namespace. Regards Hartmut

"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:cfi2an$4ed$1@sea.gmane.org... Hartmut Kaiser wrote:

Thorsten Ottosen wrote:

...

typename boost::range::value<T>::type

typename boost::range_value<T>::type

I think my personal view would be that I think range_ reads better than range::. Too many :: and it seems a bit confusing.

I'm personally prefer to use namespaces to structurize the code, i.e. the

typename range::value<T>::type

notation. The range_value<T>::type notation unneededly clutters the 'global' boost namespace.

| | I agree. Also, the user can use namespace aliases to shorten calls, | which doesn't work with range_. Ok, so there seem to be most people in favor of the namespace idea. Pavol Droba thinks so to. Matthew Wilson mentions we should see of any negative consequences. | 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. what algorithms? We cannot put size() in range:: since it will clash. I'm just wondering how the last details should be. I mean, now I have namespace boost { namespace range { template< class T > struct value; } } But would it not seem weird to specify a concept where the expression looks like boost::range::value<T>::type ?? I mean, the boost namespace should not be part of the concept. br Thorsten

"David Abrahams" <dave@boost-consulting.com> wrote in message news:ullgj9dly.fsf@boost-consulting.com... | Daniel Frey <daniel.frey@aixigo.de> 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. | 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. 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. br Thorsten

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? I'm not sure I see how. For example iterator traits don't have an iterator. . . . . . . . . . . . . -Thorsten

"David Abrahams" <dave@boost-consulting.com> wrote in message news:uacwy4qj8.fsf@boost-consulting.com... | | Isn't an iterator's value_type the same value_type a range or a | container has? yes, of course. Ditto for difference_type. br Thorsten

"Rob Stewart" <stewart@sig.com> wrote in message news:200408132026.i7DKQYL01956@entwistle.systems.susq.com... | From: David Abrahams <dave@boost-consulting.com> | > "Thorsten Ottosen" <nesotto@cs.auc.dk> writes: | > | > > The primary motivation for the namespace version seems to be | > > shortening of names. | > | > That doesn't seem very compelling to me. | | I thought it was to bring consistency to the template names | across the various namespaces. Remember value, iterator, | const_iterator, difference, size, etc. from Thorsten's list? The | same names could be used in different namespaces for the same | purpose. Whether such names were qualified, and whether the | qualification was shortened in any way, was up to the context | and user. I'm feeling less and less comfortable with the namespace version. Shorter names don't seem to be an issue. Namespaces on concepts seems to be an issue. We cannot use the same namespace for size as a function and metafuntion nor bring them into the same scope. The smallest change is not to change the iterator library and therefore I will use the prefix range_ for my metafunctions unless there are heavy objections. br Thorsten

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message news:cfpjrh$f65$1@sea.gmane.org... | 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 | 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 | have the easy-to-remember convention that the metafunction has the | same name as the traditional nested type. you could also say io_char<T>::type io_int<T>::type and put it in namespace boost? | > The smallest change is not to change the iterator library and | therefore I will | > use the prefix range_ for my metafunctions unless there are heavy | objections. | | 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' -- | although I don't have a better idea -- so perhaps I'd choose | range_xxx. ok. br Thorsten

"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