[Development] Upgrading the sources to C++11 keywords (Q_NULLPTR, etc.)

Matthew Woehlke mw_triad at users.sourceforge.net
Wed Feb 4 18:47:42 CET 2015


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




More information about the Development mailing list