lmi
[Top][All Lists]
Advanced

[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 20:26:36 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 1/19/21 5:51 PM, Vadim Zeitlin wrote:
> On Tue, 19 Jan 2021 15:57:29 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> On 1/16/21 11:53 AM, Vadim Zeitlin wrote:
[...empty vs. nonempty template-parameter names...]
> GC> In some cases, I agree. OTOH, here:
> GC> 
> GC>  template<typename ClassType, typename ValueType>
> GC>  class holder final
> GC>      :public placeholder
> GC>  {
> GC>      // Friendship is extended to class any_member only to support its
> GC>      // cast operations.
> GC> -    template<typename T> friend class any_member;
> GC> +    template<typename> friend class any_member;
> GC> 
> GC> I'm not sure there can be a more meaningful name than 'T'
> GC> (or the empty name, which I prefer). The intention is to befriend this:
> GC>     template<typename ClassType> friend class any_member; // error
> 
>  I was not totally sure about this, thanks for confirming it. However in
> this case I believe this friend declaration isn't the right thing to do at
> all, at least pedantically speaking, and we should use
> 
>       friend class any_member<ClassType>;
> 
> instead (after forward declaring any_member template previously, if
> necessary).

Done: dfdbf3c5..21d8d5ec  master -> master

Thanks, that idea didn't occur to me. That having been changed to:

    friend class any_member<ClassType>;

let's now consider these:

fenv_lmi_x86.hpp: template<typename> friend class control_word;
timer.hpp:        template<typename> friend class AliquotTimer;

which are less restrictive. But those do seem appropriate:

 - Class 'Timer' is not a template. It befriends AliquotTimer<F>
   for any 'F' we implement.

 - The other thing is an x87 control word. We wouldn't change it now,
   even if it were too permissive; and I think the idea was to let
   the orthodox control-word class befriend the msvc one, so it's
   probably correct anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]