stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r668318 - in /stdcxx/branches/4.3.x: include/rw/_tuple.h include/rw/_tuple_traits.h include/tuple tests/utilities/20.tuple.cnstr.cpp
Date Mon, 23 Jun 2008 23:58:40 GMT
Eric Lemings wrote:
>  
[...]
>> Please follow the established convention and drop the spaces
>> before class and before the closing pointy brace. Thanks! :)
> 
> It would be a lot easier if these conventions were actually ESTABLISHED.
> Until they are established, we're going to be constantly running into
> this problem.  Don't you agree?

They are fully established (grep for "< class" vs "<class" in our
sources), they're just not formally documented. In the absence of
documentation I suggest you follow the style used in existing code.
It's not that different from the style used in most other projects
including those at Rogue Wave.

> 
> I can start a Wiki page for this unless you'd prefer to do it.

Starting a page on coding style sounds like a great idea.

> 
[...]
>>> +template < class _HeadT, class... _TailT >
>> In the interest of consistency we should adopt the same naming
>> convention for the names of variadic template parameters. We
>> have _TypeT and and Types in traits, _HeadT and _TailT here,
>> and TTypes and UTypes in the standard. Which one should it
>> be?
> 
> It is my opinion that the T and U prefixes/suffixes are only necessary
> in binary contexts; i.e. where there are two different types or type
> lists.

That may be the case but...

> Otherwise, we should use just a plain "Type" name.

...we have an established convention that has the T at the end.
I'm opposed to using different conventions for new vs existing
code and I see no compelling reason to change the thousands of
lines of existing code to conform to a different convention.

What I'd like us to do is establish a convention to use for
variadic templates. The convention that makes the most sense
to me is one that builds on the existing convention for
ordinary (non-variadic) templates. Of the three choices that
I gave initially:

   template <class _TypeT, class... _Types>     // in type traits
   template <class _HeadT, class... _TailT>     // in tuple
   template <class _TType, class... _UTypes>    // in the spec

the one that fits the bill is the first one:

   template <class _TypeT, class... _Types>

We can tweak the name of the parameter pack but I don't see
how we can change the name of the first parameter without
deviating from the current convention.

> 
> Furthermore, generic "Type" names should only be used in truly
> generic contexts; i.e. contexts where just about any type can be
> used.  Otherwise, the name should imply the restrictions/requirements
> on the type; e.g. _ScalarType, _IntConst.  In the recursive tuple
> case, using generic names would make the code much harder to follow
> IMHO.

For the non-variadic case this is quite elegantly handled by
concepts. For example, the new variadic function template
std::min() currently declared in the working paper like so:

   template <class T, ... Args>
   const T& min (const T& a, const Args&... args);

becomes:

   template <LessThanComparable T, LessThanComparable... Args>
   requires SameType<T, Args...>
   const T& min (const T& a , const Args&... args);

> 
> 
[...]
>>> +template <int _Index, class ... _Types>
>>> +_TYPENAME tuple_element<_Index, tuple<_Types...> >::type const&
>> The const should come before tuple_element.
> 
> For style?  They are semantically equivalent though, aren't they?
> BTW, this is how it is specified in the draft.

Yes, we discussed consistency at the last meeting. IIUC, the editor
is going to make the appropriate changes to bring the new text into
accord with the existing convention (i.e., change "T const&" to
"const T&").

Martin

Mime
View raw message