[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] [lmi-commits] master 8ee9eaf 1/7: Don't name unused template p
From: |
Greg Chicares |
Subject: |
Re: [lmi] [lmi-commits] master 8ee9eaf 1/7: Don't name unused template parameters |
Date: |
Tue, 19 Jan 2021 15:57:29 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
On 1/16/21 11:53 AM, Vadim Zeitlin wrote:
> On Sat, 16 Jan 2021 04:07:18 -0500 (EST) Greg Chicares
> <gchicares@sbcglobal.net> wrote:
>
> GC> branch: master
> GC> commit 8ee9eaf524604021b60b15018ac698529b816d1f
> GC> Author: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC> Commit: Gregory W. Chicares <gchicares@sbcglobal.net>
> GC>
> GC> Don't name unused template parameters
> GC>
> GC> Making up names for unused template parameters serves no purpose, and
> GC> creates a potential for conflict--for example:
> GC>
> GC> template<typename T> class foo
> GC> {
> GC> template<typename T> friend void bar();
> GC> ^ shadows 'T'
> GC> template<typename U> friend void baz();
> GC> ^ shadows 'U' if added later
> GC> template<typename> friend void bar();
> GC> ^ can never shadow anything
>
> While I agree that not using useless names like "T" or "U" is better than
> using them, I think the best solution could be to use meaningful names for
> the template parameters instead.
In some cases, I agree. OTOH, here:
template<typename ClassType, typename ValueType>
class holder final
:public placeholder
{
// Friendship is extended to class any_member only to support its
// cast operations.
- template<typename T> friend class any_member;
+ template<typename> friend class any_member;
I'm not sure there can be a more meaningful name than 'T'
(or the empty name, which I prefer). The intention is to befriend this:
template<typename ClassType> friend class any_member; // error
but if we write it that way, gcc rejects it:
template parameter ‘ClassType’ declared here
template<typename ClassType, typename ValueType>
^~~~~~~~
so what else could we name it? 'ClassType2' would suggest that
it's a different class than 'ClassType'. We could name it
'SameAsClassType' and write a comment explaining what that's
supposed to mean, but we'd only be fooling ourselves: the
string "SameAs" doesn't restrict the compiler to befriending
only that type, so if we want it to be the same as 'ClassType',
we need an assertion--no naming convention can accomplish that
(but a clever name might fool us into assuming that it does).
And if I were to criticize
template<typename F> class AliquotTimer
I might suggest
template<typename NullaryFunction> class AliquotTimer
instead. OTOH, a deliberately obscure single-letter template
parameter encourages maintainers to read the commentary:
/// Template parameter 'F' is the type of the first ctor parameter,
/// which either is a nullary function or behaves like one.
so I think that's fine as is. But if I were to change that
parameter to "NullaryFunction", it would just be a nuisance
to have to change it in the friend declaration too, yet
leaving the old parameter in the friend declaration would
introduce a gratuitous difference--whereas, with this change:
class LMI_SO Timer
{
friend class TimerTest;
- template<typename F> friend class AliquotTimer;
+ template<typename> friend class AliquotTimer;
that concern does not arise.