Hi,
On Thu, 27 Sep 2012, Lawrence Crowl wrote:
> > template <typename T>
> > struct D : B<T>
> > {
> > typedef typename B<T>::E E; // element_type
> > E getme (int index);
> > }
>
> Inside that struct, lets say we have a field of type E. Do we name
> it F or f?
IMHO only for types, not for any other decls.
> > > Do you have an alternate suggestion, one that does not confuse
> > > template parameters and dependent names?
> >
> > Upper last character? Just kidding :) Too many detailed rules
> > for conventions are the death of them, use rules of thumbs,
> > my one would be "somehow depends on template args -> has upper
> > character in name", where "somehow depends on" includes "is a".
>
> Ah, but there is a problem. That typedef name does not necessarily
> depend on a template parameter.
>
> It is common practice to have
>
> struct Q
> {
> typedef int E;
> E getme (int index);
> };
Easy: I wouldn't make a typedef for Q::E that merely is int. The reason
is that it makes knowing what getme really returns harder. You have to
look it up always (or know the class already). In fact that's one of my
gripes with the standard library, much too much indirection through
entities merely referring to other entities. Might be only important for
the libraries implementors but I sure hope that we don't start down that
road in GCC.
> In fact, one place is in the hash table code we are discussing.
> The hash descriptor type may not itself be a template. I believe
> that few of them will actually be templates.
Then I don't see the need for class-local typedefs.
> So, if E implies comes from template, the implication is wrong.
>
> If we were to follow C++ standard library conventions, we would call it
> value_type.
Well, but value_type surely does depend on the hashtables type argument,
doesn't it? After all it is a typedef from 'Key'.
I would expect that htab<tree>::value_type is tree, and
htab<int>::value_type is int, and I would like to see it named
htab<tree>::T or ::E.
> That would be my preference. However, if folks want a shorter name,
> I'll live with that too. But as it stands, the current name is very
> confusing.
I would even prefer 'e' over value_type. It's scoped, the context always
will be clear, no need to be verbose in that name. I find the long names
inelegant, as most of the standard libs conventions.
Ciao,
Michael.
