[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Various C++ m12ns
Re: [lmi] Various C++ m12ns
Tue, 7 Mar 2017 01:01:33 +0000
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:
> 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
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.