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
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel