[plasma-framework] /: Revert "Enabling C++11 flags for clang and gcc"

[Kevin Ottens]

On Friday 28 June 2013 23:13:34 Ivan Čukić wrote:
> > such a premise VS2012 has a very partial C++11 support, Android NDK uses
> > gcc 4.6 by default (apparently you can upgrade that to 4.7 but we can't
> > expect third parties to do it by default, means partial support in both
> > cases), BB10 cross- compiler doesn't properly support C++11. We're not
> 
> The agreement before was to use the features available in gcc 4.5 - nothing
> newer to be required (for example by using a bit ugly but useful
> replacements like Q_NULLPTR and Q_DECL_OVERRIDE)

OK, then we got a misunderstanding somewhere...

Using those Q_* macros is perfectly fine (and even encouraged, we already use 
Q_DECL_OVERRIDE and I'd like to see more Q_NULLPTR for instance). They enable 
exactly what I was describing earlier: works without C++11 support, you get 
extras otherwise.

You don't need to unconditionally force C++11 on the cmake side though 
(otherwise I don't see the point of using those macros and not the keywords 
directly).

auto, lambdas, functional or some of the new features around templates or 
ctors are another story, that's the ones which can be really troublesome for 
portability. Apart from auto, the other ones (from a library point of view) 
are generally about providing extra API and that's often inlined code... easy 
enough to #ifdef the relevant parts in the header file based on Q_COMPILER_* 
macros (e.g. Q_COMPILER_DECLTYPE, Q_COMPILER_VARIADIC_TEMPLATES).

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20130628/541e24d7/attachment.sig>