On 2015-02-02 17:51, Thiago Macieira wrote:
> On Monday 02 February 2015 14:29:21 Matthew Woehlke wrote:
>>> * Q_DECL_EQ_DEFAULT - really discouraged
>>>
>>> I can't think of any case where you could use this and let the code still
>>> compile in C++98, so don't use it
>>
>> I'd actually like to see this used where possible and sensible, as the
>> compiler may be able to optimize better (or it can make POD types that
>> otherwise wouldn't be POD).
>>
>> You can use it like:
>>
>> class QFoo { QFoo(const QFoo&) Q_DECL_EQ_DEFAULT; }
>> #if // '= default' not supported
>> QFoo::QFoo(const QFoo& other) { ... }
>> #endif
>>
>> ...that is, provide a definition conditional on Q_DECL_EQ_DEFAULT
>> expanding to empty. (This will also make it easy to rip out the old code
>> if/when C++11 becomes a requirement for Qt.)
>
> This class is better written as:
>
> class QFoo
> {
> // implicit copy constructor is fine
> };
Ah, right, it's a move constructor that prevents generating the default
copy constructor... and if you have one of those it's a fair assumption
that you can '= default' the copy ctor to get it back...
(Although I could've sworn I've run into cases where I needed to
explicitly declare a copy constructor that ought to be default but the
default one was being suppressed... maybe I'm imagining it though.)
However, explicit defaulting is still interesting for the *default*
constructor. (See
https://msdn.microsoft.com/en-us/library/dn457344.aspx; apparently in
MSVC at least there are advantages to an explicitly defaulted default
constructor vs. an empty-bodied default constructor.)
--
Matthew
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
