lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Various C++ m12ns


From: Greg Chicares
Subject: Re: [lmi] Various C++ m12ns
Date: Tue, 7 Mar 2017 01:01:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.6.0

On 2017-03-06 22:49, Vadim Zeitlin wrote:
> On Mon, 6 Mar 2017 22:28:53 +0000 Greg Chicares <address@hidden> wrote:
> 
> [...discussion of replacing lmi::uncopyable<> with "= delete" snipped...]
> 
> GC> Let's see if we can write a guideline for this....
> 
>  I did try to do this already earlier today, let me repost the link I had
> posted in the "Define special member functions inline?" thread:
> 
>       https://gist.github.com/vadz/3222ef957769f3a9415caa799113d640
> 
> The relevant guideline is at the bottom.

Par ma foi, il y a plus de vingt ans que je dis des X macros,
sans que j'en susse rien.

> GC> Already I have a question about the guideline. Would you also
> GC> always declare a destructor, with '= default' by default?
> 
>  This is really the edge case, isn't it. I ended up by including the dtor
> in my guideline at the link above too, but I'm not sure about it. On one
> hand, it's consistent with the other special member functions. OTOH, a
> non-default dtor should be very rarely needed in modern C++ code, where all
> resources should be handled by the wrapper classes, so it seems
> unnecessarily verbose to write "~X() = default" everywhere. Maybe it would
> be better to omit it...

I tend to think it's better to omit it.

Still, I'll state a possible argument in favor of writing it always: that it
compels the author to make an explicit choice between virtual and nonvirtual.
(I'm not moved by that argument. The absence of a virtual dtor says enough.)

>  OTOH I'm definitely for extending the same treatment to the default ctor,
> i.e. writing "X() = default", even if it's unnecessary, because it
> immediately shows that the class is default constructible, which might not
> be obvious otherwise

Or, similarly, writing "X() = delete;"? (I don't think I'd advocate that,
because it's obvious by its absence.)

> (contrast this with the dtor: all classes are
> "destructible", so writing it explicitly doesn't provide any new
> information).

Yes, good point.

> GC> And another question. At first I was going to recommend either
> GC>   public:
> GC>     X(X const&) = default;
> GC>     X& operator=(X const&) = default;
> GC> or
> GC>   private:
> GC>     X(X const&) = delete;
> GC>     X& operator=(X const&) = delete;
> GC> but then I figured that calling a deleted public function ought
> GC> to produce as clear a diagnostic as calling a deleted private one;
> 
>  Actually, it produces a more clear diagnostic: with the public deleted
> function you get just an error about "use of deleted function", while with
> a private one you get first several lines pertaining to "<function> is
> private" before the same error as you'd get with the public one.

Intriguing, but it makes sense when you think about it.




reply via email to

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