[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [plasma-framework] /: Revert "Enabling C++11 flags for clang and gcc"
From:       Kevin Ottens <ervin () kde ! org>
Date:       2013-06-28 22:16:57
Message-ID: 2024044.kvPYsitZE8 () wintermute
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Friday 28 June 2013 23:58:21 Ivan Čukić wrote:
> > 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.
> 
> No misunderstanding - for the features that require gcc >=4.6 and clang
> >=3.2, it was decided to use the macros*. For the features available in 4.5
> and clang 3.1 (freebsd compiler iirc) no macros (auto, lambdas, variadic
> templates, move semantics)

OK, I see now.
 
> > 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...
>
> I don't agree that these /additional/ features are about the api.
> <algorithm> is an (IMO) immensely useful, especially with lambdas and
> std::bind for actual non exposed parts.

Well, yes that's all useful. That's the type of things I'd like to use 
everywhere too. I badly worded that above though. What I meant is that for the 
internals of a library you can spare their use in most cases (just to avoid 
blowing the complexity of your lib internals), still you probably want to 
provide extra API for C++11 users (and then limit your use there, also 
important from a BC standpoint). Now of course that's the library point of 
view, I wouldn't argue in the same way for an app (or an optional runtime 
dependency of a library).
 
Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

["signature.asc" (application/pgp-signature)]

_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]