|
Boost : |
From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2002-12-31 09:24:52
>From: "David Abrahams" <dave_at_[hidden]>
> Lastly, I know that Aleksey will argue with me about this, but I have
> a strong preference for "class" rather than "typename" in template
> parameter lists. Aside from the fact that it's longer, "typename" is
> visually confusable because it can mean other multiple things when it
> appears between <...>:
I feel the same way. :) I'm glad I'm not the only one.
I know it may argued that "typename" describes it better than "class" (since
it may be any type, not just an UDT). However, as you say, for one thing,
"typename" is longer, and for another, since "typename" is also used to
disambiguate dependent types, then whenever you see "typename" in the
parameter list, it may be either a parameter, or disambiguating a dependent
name. "class" is not used for anything else in the parameter list, except
for template template parameters, but I find that doesn't make problems.
I realise that this is very subjective, of course, and that others may
prefer "typename".
Some may use "class" for types that can be only UDTs, and "typename" for
types that can be any type, but I tend to find such code confusing to read
and write, as I don't really find the distinction useful. When you have two
words, both meaning "type", then when you see sometimes one, sometimes the
other, it may slow you down unnecessarily, as the cause of the use of a
different name doesn't really matter to the code you're reading or writing.
Nor is it particularly helpful for client code. After all, C++ goes to great
lengths to ensure that UDTs and built-in types may be treated uniformly.
I guess this latter point, about use of both "class" and "typename", may
have something to do with what Bjarne Stroustrup says about aliases in D&E,
something like: "If something is called A in the code, B in the header, C in
the client code, and D in the documentation, then I have a problem." :)
Regards,
Terje
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk