Re: Updating our coding conventions and coding style for C++11
Hi, On 16/01/20 18:46, Kai Uwe Broulik wrote: > Hi, > > for "auto" I think we should always annotate it with const, *, and/or & > where appropriate: > > auto *something = new MyCustomType; > auto *keyEvent = static_cast(event); IMHO the * here is redundant and only adds noise. It's clear that `something` is a MyCustomType* and that `keyEvent` is a QKeyEvent*. > auto = foo[bar]; This could be helpful indeed. > Cheers > Kai Uwe Cheers, Elvis
Re: Updating our coding conventions and coding style for C++11
On 1/17/20 12:27 AM, David Faure wrote: > On jeudi 16 janvier 2020 18:29:11 CET Vlad Zahorodnii wrote: >> I would like us to copy Qt's policy [1] for consistency: > > OK, please do. Done. Please notice that I did not annotate auto keywords with '*'. Once we have an official policy, we can fix coding style in those code samples. Cheers, Vlad
Re: Updating our coding conventions and coding style for C++11
On 1/16/20 7:29 PM, Vlad Zahorodnii wrote: > The common practice used in KDE seems to be: > > for (a:b) Alright, it looks like we all agree on this one, so I'm going to update the Frameworks Coding Style.
Re: Updating our coding conventions and coding style for C++11
On 1/16/20 7:46 PM, Kai Uwe Broulik wrote:
> for "auto" I think we should always annotate it with const, *, and/or &
> where appropriate:
>
> auto *something = new MyCustomType;
> auto *keyEvent = static_cast(event);
> const auto myList = QStringList({QLatin1String("FooThing"),
> QLatin1String("BarThing")});
> auto = foo[bar];
I also prefer to do that. On the other hand, I'd like our code to be as
close as possible to Qt's code in terms of coding style. Perhaps, this
discussion must be moved to the Qt/Development mailing list unless the
question of annotating auto with const/*/& had been raised before there.
Cheers,
Vlad
Re: Updating our coding conventions and coding style for C++11
On 1/17/20 12:46 AM, Kai Uwe Broulik wrote: > It provides useful visual information. > > auto foo = bar(); > auto baz = I don't think that you should use auto in either case since it's not clear what type foo and baz have. Cheers, Vlad
Re: Updating our coding conventions and coding style for C++11
On Thu, 16 Jan 2020, 22:46 Kai Uwe Broulik, wrote: > > > Well, the * is completely redundant in those cases, so it doesn't bring > anything. > > I'd be tempted to say, let's not require it. > > But then it raises the question of consistency (without a guideline, > we'll have some places with * and some places without *). > > It provides useful visual information. > > auto foo = bar(); > auto baz = > Neither of those examples abide by the proposed Qt/Vlad rules, which I think would render your issue moot. I don't think I really understand your potential issue anyway, if you tried to use baz form and it wasn't the type I expected it just wouldn't compile? This is somewhat different to the case where have you have overloaded & and non& operators, such as [] where I do I understand why it's useful. I'll continue mandating that in code I maintain, even if it's not > official policy. > The context of this original email being sent was that I got extremely frustrated with per-project seemingly random rules. I can happily follow a global policy even if I don't agree with it, but we need to define things. Otherwise, we'll end up in this situation again. David
Re: Updating our coding conventions and coding style for C++11
Am Donnerstag, 16. Januar 2020, 23:27:57 CET schrieb David Faure: > On jeudi 16 janvier 2020 18:29:11 CET Vlad Zahorodnii wrote: > > I would like us to copy Qt's policy [1] for consistency: > OK, please do. +1, thanks for the initiative, Vlad. > Kai-Uwe wrote: > > for "auto" I think we should always annotate it with const, *, and/or & > > where appropriate: > > auto *something = new MyCustomType; > > auto *keyEvent = static_cast(event); > > Well, the * is completely redundant in those cases, so it doesn't bring > anything. I'd be tempted to say, let's not require it. > But then it raises the question of consistency (without a guideline, we'll > have some places with * and some places without *). By my own experience so far I would also settle to say, redundant but very helpful to human readers who try to understand some unknown code. So my +1 for requiring explicit pointer & reference & const with auto. This is information too often important for understanding the rest of the code to just rely on the human to extract that from the variable initialization code, code is much faster to read with that info being explicit. And sometimes it can also help the code writer to be more sure their intention/understanding it matched. And after all "const", "*" & "&" are not that expensive to type or bloating up the line :) More, if you always write them, you will not forget to do so where they are not redundant. Cheers Friedrich
Re: Updating our coding conventions and coding style for C++11
On Thursday 16 Jan 2020 18:46:06 Kai Uwe Broulik wrote:
> Hi,
>
> for "auto" I think we should always annotate it with const, *, and/or &
> where appropriate:
>
> auto *something = new MyCustomType;
> auto *keyEvent = static_cast(event);
> const auto myList = QStringList({QLatin1String("FooThing"),
> QLatin1String("BarThing")});
This is a bad example of the use of auto. It can be more simply written
without using auto:
const QStringList myList{QLatin1String("FooThing"),
QLatin1String("BarThing")};
> auto = foo[bar];
>
> > The common practice used in KDE seems to be:
> > for (a:b)
>
> +1
>
> Cheers
> Kai Uwe
--
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
Re: Updating our coding conventions and coding style for C++11
Well, the * is completely redundant in those cases, so it doesn't bring anything. I'd be tempted to say, let's not require it. But then it raises the question of consistency (without a guideline, we'll have some places with * and some places without *). It provides useful visual information. auto foo = bar(); auto baz = where's the pointer now? Sure, your IDE probably will autocomplete operator-> as needed but to me it just feels odd, visually. In any case, I'll continue mandating that in code I maintain, even if it's not official policy. Though I also thought the reference would be implied by auto but apparently it is not. Cheers Kai Uwe
Re: Updating our coding conventions and coding style for C++11
On jeudi 16 janvier 2020 18:29:11 CET Vlad Zahorodnii wrote:
> I would like us to copy Qt's policy [1] for consistency:
OK, please do.
> for (a:b)
+1
Kai-Uwe wrote:
> for "auto" I think we should always annotate it with const, *, and/or &
> where appropriate:
> auto *something = new MyCustomType;
> auto *keyEvent = static_cast(event);
Well, the * is completely redundant in those cases, so it doesn't bring
anything.
I'd be tempted to say, let's not require it.
But then it raises the question of consistency (without a guideline, we'll have
some places with * and some places without *).
>From Qt:
examples/widgets/gallery/widgetgallery.cpp:272:auto toolMenu = new
QMenu(menuToolButton);
tests/manual/cocoa/menurama/main.cpp:40:auto *dockMenu = new QMenu();
Personally, I can survive with this small discrepancy, just like the Qt
developers clearly can as well.
But if everyone feels strongly that we need to standardize on something
> const auto myList = QStringList({QLatin1String("FooThing"),
> QLatin1String("BarThing")});
> auto = foo[bar];
I agree about those, they are not redundant.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
Re: Updating our coding conventions and coding style for C++11
Hi,
for "auto" I think we should always annotate it with const, *, and/or &
where appropriate:
auto *something = new MyCustomType;
auto *keyEvent = static_cast(event);
const auto myList = QStringList({QLatin1String("FooThing"),
QLatin1String("BarThing")});
auto = foo[bar];
The common practice used in KDE seems to be:
for (a:b)
+1
Cheers
Kai Uwe
Updating our coding conventions and coding style for C++11
Hi,
I would like to update our coding conventions
https://community.kde.org/Policies/Library_Code_Policy.
The auto keyword is not mentioned leading to it being a common point of
contention in reviews as we can't point to a reference.
I would like us to copy Qt's policy [1] for consistency:
Optionally, you can use the auto keyword in the following cases. If in
doubt, for example if using auto could make the code less readable, do
not use auto. Keep in mind that code is read much more often than
written.
When it avoids repetition of a type in the same statement.
auto something = new MyCustomType;
auto keyEvent = static_cast(event);
auto myList = QStringList() << QLatin1String("FooThing") <<
QLatin1String("BarThing");
When assigning iterator types.
auto it = myList.const_iterator();
In addition to the coding conventions, I would like to update the KDE
Frameworks Coding Style to include a statement about whitespace before
range-based for loop colons.
The common practice used in KDE seems to be:
for (a:b)
Cheers,
vlad
[1] https://wiki.qt.io/Coding_Conventions#auto_Keyword
D7879: [KConfigGroup] reserve() more and add some C++11
This revision was automatically updated to reflect the committed changes. Closed by commit R237:fb15e56857ca: [KConfigGroup] reserve() more and add some C++11 (authored by broulik). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D7879?vs=19671=19727#toc REPOSITORY R237 KConfig CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D7879?vs=19671=19727 REVISION DETAIL https://phabricator.kde.org/D7879 AFFECTED FILES src/core/kconfiggroup.cpp To: broulik, kde-frameworks-devel, dfaure, davidedmundson, mwolff Cc: mwolff, #frameworks
D7879: [KConfigGroup] reserve() more and add some C++11
mwolff accepted this revision. mwolff added a comment. ah ok, and since we don't have a proper byte array view yet, there's nothing you can do (which is sad here!) the other comments from me where suggestions for further improvements, they don't need to hold up this patch REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D7879 To: broulik, kde-frameworks-devel, dfaure, davidedmundson, mwolff Cc: mwolff, #frameworks
D7879: [KConfigGroup] reserve() more and add some C++11
broulik planned changes to this revision. broulik added inline comments. INLINE COMMENTS > mwolff wrote in kconfiggroup.cpp:187 > use `splitRef` instead, also below Was my first reflex do to so but `string` confusingly is a `QByteArray` REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D7879 To: broulik, kde-frameworks-devel, dfaure, davidedmundson, mwolff Cc: mwolff, #frameworks
D7879: [KConfigGroup] reserve() more and add some C++11
mwolff requested changes to this revision.
mwolff added a comment.
This revision now requires changes to proceed.
it would probably be a good idea to rewrite
`KConfigGroupPrivate::serializeList` to not take a `QVariantList`, but rather
to use a streaming API. I.e. instead of:
void foo(myList)
{
varList = convertList(myList);
write(KConfigGroupPrivate::serializeList(list));
}
Do something like:
void foo(myList)
{
var value = KConfigGroupPrivate::serializeList(mylist)
write(value);
}
where `serializeList` is a template that does $magic internally to convert a
list of values to a serializeable format (i.e. iterate over values, then stream
them into QDataStream/QTextStream, wrap in QVariant only when needed). Note
that you can then use `initializer_list` for the "static" lists like for
`QPoint` et al.
INLINE COMMENTS
> kconfiggroup.cpp:185
>
> static QList asIntList(const QByteArray )
> {
can you make this (and the `QList` below) a `QVector` instead? Would
save 50% of memory on 64bit machines
> kconfiggroup.cpp:187
> {
> +const auto = string.split(',');
> +
use `splitRef` instead, also below
REPOSITORY
R237 KConfig
REVISION DETAIL
https://phabricator.kde.org/D7879
To: broulik, kde-frameworks-devel, dfaure, davidedmundson, mwolff
Cc: mwolff, #frameworks
D7879: [KConfigGroup] reserve() more and add some C++11
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D7879 To: broulik, kde-frameworks-devel, dfaure, davidedmundson Cc: #frameworks
D7879: [KConfigGroup] reserve() more and add some C++11
broulik created this revision. broulik added reviewers: kde-frameworks-devel, dfaure. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY Using initializer_lists for QList we reserve the right amount of memory in advance and also make for nicer code. Also uses range-for where code as touched and a const container was used. TEST PLAN Test still pass. `asRealList` is called 4200x on plasmashell startup for me, saves 2ms for me REPOSITORY R237 KConfig REVISION DETAIL https://phabricator.kde.org/D7879 AFFECTED FILES src/core/kconfiggroup.cpp To: broulik, kde-frameworks-devel, dfaure Cc: #frameworks
Re: To C++11 or not?
On Friday, 30 December 2016 15:29:52 CET Kevin Funk wrote: > On Friday, 30 December 2016 15:25:56 CET David Faure wrote: > > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > > > El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano > > > va > > > > > > escriure: > > > > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > > > > >Following-up on this thread, since I saw some more discussion about > > > > >C++11 > > > > > > > > > >usage in this RR: > > > > > https://git.reviewboard.kde.org/r/129724/ > > > > > > > > > >Let's put this into some concrete actions, finally. I think we all > > > > >agree > > > > >nullptr & override are probably the most apparent issues (since > > > > >compilers > > > > >started to warn about both), and *having* 'override' is actually > > > > >super > > > > >useful > > > > >for preventing programmer faults. > > > > > > > > > >Let's just speak about allowing nullptr & override, allowing the full > > > > >set of C > > > > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > > > > >available only > > > > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > > > > > > > > > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > > > > >That's > > > > >pretty ancient. 4.5.1 got released Jul 2010 [3] > > > > > > > > > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can > > > > >use > > > > > > > > > >'nullptr' unconditionally. ktexteditor already did that in public > > > > >headers for > > > > >quite some time -- no-one complained. > > > > > > > > > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can > > > > >use > > > > > > > > > >'override' unconditionally *. > > > > > > > > > >We already use MSVC2012 as min VS dep, this version has full nullptr > > > > >& > > > > >override support. I don't see anyone using MSVC2010 for compiling KF5 > > > > >to be > > > > >honest... > > > > > > > > > >Proposal for [1]: > > > > >- Raise min GCC version to 4.7 > > > > >- Allow to use override unconditionally > > > > >- Allow to use nullptr unconditonally > > > > > > > > > >ACK? > > > > > > > > > > > > > > >PS: I can do the work, I can script the refactoring with clang-tidy. > > > > > > > > > >Let's move forward please. > > > > > > > > Hi, this is a really good analysis (also for future reference). In > > > > order > > > > to > > > > complete it, given that the original idea was "follow Qt's > > > > requirement", > > > > and that we increased in time the required version of Qt, what is the > > > > current status regarding compilers and Qt? > > > > > > Our min requirement is Qt 5.5 which according to > > > http://doc.qt.io/qt-5/supported-platforms-and-configurations.html > > > compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > > > Then that's a no-brainer, we can require gcc 4.6 too. > > > > Qt 5.9 (currently "git dev branch") uses override rather than > > Q_DECL_OVERRIDE, but we're far from requiring 5.9. > > > > This leads to a different proposal: > > - Raise min GCC version to 4.6 > > - Allow to use nullptr unconditionally > > - Use Q_DECL_OVERRIDE. > > +1 from my side. I didn't know that we wanted to follow the Qt version's > minimum compiler requirements. Makes sense. > > Thanks for chiming in! > > I'll port KF5 (at least the (public) headers) to nullptr if this proposal is > accepted. Didn't see any objections thus I think we're good on the 'let's use nullptr' side. Here's my patch (just showing an excerpt): https://phabricator.kde.org/D3987 Cheers, Kevin > Cheers, > Kevin > > > I fully agree that "having 'override' is actually super useful for > > preventing programmer faults", but that also works if it's spelled out > > Q_DECL_OVERRIDE and only ineffective for people *using* frameworks on an > > older system with gcc 4.6. It's still effective for all of us who are > > working on frameworks, which is where the benefit of "override" is. > > > > BTW just to get a taste of the real world, I'm working with a customer > > right now who is using Qt 5 and gcc 4.4 in order for their binaries to > > work on the largest possible number of Linux distros out there (glibc > > version). They are not using KDE Frameworks, obviously, but this is just > > to point out that there are companies using older gcc versions still, > > this is not just hypothetical. > > > > Funny that I kept saying "MSVC is what's holding us back" when in fact > > it's > > GCC that is holding us back ;) > > > > > > PS: I disagree with the "nobody complained" approach. Many people will > > simply choose another library than complain about one library not being > > suited to their constraints (one of which being the supported compiler). -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: To C++11 or not?
On Wednesday, 4 January 2017 00:17:55 CET Stephen Kelly wrote: > On 01/03/2017 10:36 PM, Albert Astals Cid wrote: > > El divendres, 30 de desembre de 2016, a les 15:32:24 CET, Martin Gräßlin > > va > > > > escriure: > >> Am 2016-12-30 15:25, schrieb David Faure: > >>> I fully agree that "having 'override' is actually super useful for > >>> preventing > >>> programmer faults", but that also works if it's spelled out > >>> Q_DECL_OVERRIDE > >>> and only ineffective for people *using* frameworks on an older system > >>> with gcc > >>> 4.6. It's still effective for all of us who are working on frameworks, > >>> which > >>> is where the benefit of "override" is. > >> > >> What's the plan to enforce that? How is build.kde.org checking that we > >> don't use override instead of Q_DECL_OVERRIDE? > > > > I guess you can stop worrying. Stephen Kelly just reverted that change > > that > > had been approved in a review request without any discussion. > > Sorry. > > We need to have a way to enable that warning flag which is accompanied > by a way to resolve the huge amount warnings it generates. We can't just > add that much noise to all the builds indefinitely. > > clang-tidy seems to have a modernize-use-override feature. Can we run > that on at least all frameworks before enabling this flag? I can do that. Likely won't happen today though. Cheers, Kevin > Thanks, > > Steve. -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: To C++11 or not?
On 01/03/2017 10:36 PM, Albert Astals Cid wrote: > El divendres, 30 de desembre de 2016, a les 15:32:24 CET, Martin Gräßlin va > escriure: >> Am 2016-12-30 15:25, schrieb David Faure: >>> I fully agree that "having 'override' is actually super useful for >>> preventing >>> programmer faults", but that also works if it's spelled out >>> Q_DECL_OVERRIDE >>> and only ineffective for people *using* frameworks on an older system >>> with gcc >>> 4.6. It's still effective for all of us who are working on frameworks, >>> which >>> is where the benefit of "override" is. >> What's the plan to enforce that? How is build.kde.org checking that we >> don't use override instead of Q_DECL_OVERRIDE? > I guess you can stop worrying. Stephen Kelly just reverted that change that > had been approved in a review request without any discussion. Sorry. We need to have a way to enable that warning flag which is accompanied by a way to resolve the huge amount warnings it generates. We can't just add that much noise to all the builds indefinitely. clang-tidy seems to have a modernize-use-override feature. Can we run that on at least all frameworks before enabling this flag? Thanks, Steve.
Re: To C++11 or not?
El divendres, 30 de desembre de 2016, a les 15:32:24 CET, Martin Gräßlin va escriure: > Am 2016-12-30 15:25, schrieb David Faure: > > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > >> El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi > >> Toscano va > >> > >> escriure: > >> > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > >> > >Following-up on this thread, since I saw some more discussion about > >> > >C++11 > >> > > > >> > >usage in this RR: > >> > > https://git.reviewboard.kde.org/r/129724/ > >> > > > >> > >Let's put this into some concrete actions, finally. I think we all > >> > >agree > >> > >nullptr & override are probably the most apparent issues (since > >> > >compilers > >> > >started to warn about both), and *having* 'override' is actually super > >> > >useful > >> > >for preventing programmer faults. > >> > > > >> > >Let's just speak about allowing nullptr & override, allowing the full > >> > >set of C > >> > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > >> > >available only > >> > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > >> > > > >> > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > >> > >That's > >> > >pretty ancient. 4.5.1 got released Jul 2010 [3] > >> > > > >> > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can > >> > >use > >> > > > >> > >'nullptr' unconditionally. ktexteditor already did that in public > >> > >headers for > >> > >quite some time -- no-one complained. > >> > > > >> > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can > >> > >use > >> > > > >> > >'override' unconditionally *. > >> > > > >> > >We already use MSVC2012 as min VS dep, this version has full nullptr & > >> > >override support. I don't see anyone using MSVC2010 for compiling KF5 > >> > >to be > >> > >honest... > >> > > > >> > >Proposal for [1]: > >> > >- Raise min GCC version to 4.7 > >> > >- Allow to use override unconditionally > >> > >- Allow to use nullptr unconditonally > >> > > > >> > >ACK? > >> > > > >> > > > >> > >PS: I can do the work, I can script the refactoring with clang-tidy. > >> > > > >> > >Let's move forward please. > >> > > >> > Hi, this is a really good analysis (also for future reference). In > >> > order > >> > to > >> > complete it, given that the original idea was "follow Qt's > >> > requirement", > >> > and that we increased in time the required version of Qt, what is the > >> > current status regarding compilers and Qt? > >> > >> Our min requirement is Qt 5.5 which according to > >> http://doc.qt.io/qt-5/supported-platforms-and-configurations.html > >> compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > > > Then that's a no-brainer, we can require gcc 4.6 too. > > > > Qt 5.9 (currently "git dev branch") uses override rather than > > Q_DECL_OVERRIDE, > > but we're far from requiring 5.9. > > > > This leads to a different proposal: > > - Raise min GCC version to 4.6 > > - Allow to use nullptr unconditionally > > - Use Q_DECL_OVERRIDE. > > > > I fully agree that "having 'override' is actually super useful for > > preventing > > programmer faults", but that also works if it's spelled out > > Q_DECL_OVERRIDE > > and only ineffective for people *using* frameworks on an older system > > with gcc > > 4.6. It's still effective for all of us who are working on frameworks, > > which > > is where the benefit of "override" is. > > What's the plan to enforce that? How is build.kde.org checking that we > don't use override instead of Q_DECL_OVERRIDE? I guess you can stop worrying. Stephen Kelly just reverted that change that had been approved in a review request without any discussion. Very sad, Albert > > This is the point I disagree with. We define nice rules and have no > means at all to ensure that they are enforced. That's something I have > brought to the attention of this mailing list several times over the > last years. Unfortunately nothing has changed. > > In my opinion we are lying to ourself and to everybody who wants to use > frameworks if we say "can be compiled with gcc 4.6" when we aren't even > testing that. > > So please let's get the ordering right: ensure that it compiles with gcc > 4.6, then say we support that. The only other option is to say we > require whatever gcc version build.kde.org is using. > > Cheers > Martin
Re: To C++11 or not?
On vendredi 30 décembre 2016 16:26:53 CET David Faure wrote: > On vendredi 30 décembre 2016 16:02:17 CET Kevin Funk wrote: > > I agree it would be perfect to have GCC 4.6 for KF5 in place (or some > > other > > mechanism to make sure 'override' is not used). > > One solution is > add_definitions(-Doverride=ERROR) > ;-) > > (like qtbase does with a number of things, for its own compilation) Sorry that was nonsense, would break Q_DECL_OVERRIDE. qtbase is doing -Dsignals=int \ -Dslots=int \ -Demit=public: \ -Dforeach=public: \ -Dforever=public: but that's just its own macros. Commit hook? :-) Or I can just run a grep at release time. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: To C++11 or not?
On vendredi 30 décembre 2016 16:02:17 CET Kevin Funk wrote: > I agree it would be perfect to have GCC 4.6 for KF5 in place (or some other > mechanism to make sure 'override' is not used). One solution is add_definitions(-Doverride=ERROR) ;-) (like qtbase does with a number of things, for its own compilation) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: To C++11 or not?
Hi, >> Our min requirement is Qt 5.5 which according to >> http://doc.qt.io/qt-5/supported-platforms-and-configurations.html >> compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > Then that's a no-brainer, we can require gcc 4.6 too. > > Qt 5.9 (currently "git dev branch") uses override rather than Q_DECL_OVERRIDE, > but we're far from requiring 5.9. > > This leads to a different proposal: > - Raise min GCC version to 4.6 > - Allow to use nullptr unconditionally > - Use Q_DECL_OVERRIDE. > > I fully agree that "having 'override' is actually super useful for preventing > programmer faults", but that also works if it's spelled out Q_DECL_OVERRIDE > and only ineffective for people *using* frameworks on an older system with gcc > 4.6. It's still effective for all of us who are working on frameworks, which > is where the benefit of "override" is. > > BTW just to get a taste of the real world, I'm working with a customer right > now who is using Qt 5 and gcc 4.4 in order for their binaries to work on the > largest possible number of Linux distros out there (glibc version). They are > not using KDE Frameworks, obviously, but this is just to point out that there > are companies using older gcc versions still, this is not just hypothetical. > > Funny that I kept saying "MSVC is what's holding us back" when in fact it's > GCC that is holding us back ;) :=) Actually I wonder why somebody should do that given you get even from Red Hat (or CentOs) GCC 4.8 or now even 4.9 for the 6.x series that will allow you to deploy on any system that is really out there and able to run Qt 5 (For CentOS 5 you get similar new GCCs, but that has other issues) (and we do that for our customers since ever) Greetings Christoph -- - Dr.-Ing. Christoph Cullmann - AbsInt Angewandte Informatik GmbH Email: cullm...@absint.com Science Park 1 Tel: +49-681-38360-22 66123 Saarbrücken Fax: +49-681-38360-20 GERMANYWWW: http://www.AbsInt.com Geschäftsführung: Dr.-Ing. Christian Ferdinand Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
Re: To C++11 or not?
On Friday, 30 December 2016 15:32:24 CET Martin Gräßlin wrote: > Am 2016-12-30 15:25, schrieb David Faure: > > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > >> El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi > >> Toscano va > >> > >> escriure: > >> > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > >> > >Following-up on this thread, since I saw some more discussion about > >> > >C++11 > >> > > > >> > >usage in this RR: > >> > > https://git.reviewboard.kde.org/r/129724/ > >> > > > >> > >Let's put this into some concrete actions, finally. I think we all > >> > >agree > >> > >nullptr & override are probably the most apparent issues (since > >> > >compilers > >> > >started to warn about both), and *having* 'override' is actually super > >> > >useful > >> > >for preventing programmer faults. > >> > > > >> > >Let's just speak about allowing nullptr & override, allowing the full > >> > >set of C > >> > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > >> > >available only > >> > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > >> > > > >> > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > >> > >That's > >> > >pretty ancient. 4.5.1 got released Jul 2010 [3] > >> > > > >> > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can > >> > >use > >> > > > >> > >'nullptr' unconditionally. ktexteditor already did that in public > >> > >headers for > >> > >quite some time -- no-one complained. > >> > > > >> > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can > >> > >use > >> > > > >> > >'override' unconditionally *. > >> > > > >> > >We already use MSVC2012 as min VS dep, this version has full nullptr & > >> > >override support. I don't see anyone using MSVC2010 for compiling KF5 > >> > >to be > >> > >honest... > >> > > > >> > >Proposal for [1]: > >> > >- Raise min GCC version to 4.7 > >> > >- Allow to use override unconditionally > >> > >- Allow to use nullptr unconditonally > >> > > > >> > >ACK? > >> > > > >> > > > >> > >PS: I can do the work, I can script the refactoring with clang-tidy. > >> > > > >> > >Let's move forward please. > >> > > >> > Hi, this is a really good analysis (also for future reference). In > >> > order > >> > to > >> > complete it, given that the original idea was "follow Qt's > >> > requirement", > >> > and that we increased in time the required version of Qt, what is the > >> > current status regarding compilers and Qt? > >> > >> Our min requirement is Qt 5.5 which according to > >> http://doc.qt.io/qt-5/supported-platforms-and-configurations.html > >> compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > > > Then that's a no-brainer, we can require gcc 4.6 too. > > > > Qt 5.9 (currently "git dev branch") uses override rather than > > Q_DECL_OVERRIDE, > > but we're far from requiring 5.9. > > > > This leads to a different proposal: > > - Raise min GCC version to 4.6 > > - Allow to use nullptr unconditionally > > - Use Q_DECL_OVERRIDE. > > > > I fully agree that "having 'override' is actually super useful for > > preventing > > programmer faults", but that also works if it's spelled out > > Q_DECL_OVERRIDE > > and only ineffective for people *using* frameworks on an older system > > with gcc > > 4.6. It's still effective for all of us who are working on frameworks, > > which > > is where the benefit of "override" is. > > What's the plan to enforce that? How is build.kde.org checking that we > don't use override instead of Q_DECL_OVERRIDE? One instance that enforces this: code reviews. > This is the point I disagree with. We define nice rules and have no > means at all to ensure that they are enforced. That's something I have > brought to the attention of this maili
Re: To C++11 or not?
Am 2016-12-30 15:25, schrieb David Faure: On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va escriure: > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > >Following-up on this thread, since I saw some more discussion about > >C++11 > > > >usage in this RR: > > https://git.reviewboard.kde.org/r/129724/ > > > >Let's put this into some concrete actions, finally. I think we all > >agree > >nullptr & override are probably the most apparent issues (since > >compilers > >started to warn about both), and *having* 'override' is actually super > >useful > >for preventing programmer faults. > > > >Let's just speak about allowing nullptr & override, allowing the full > >set of C > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > >available only > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > > > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > >That's > >pretty ancient. 4.5.1 got released Jul 2010 [3] > > > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use > > > >'nullptr' unconditionally. ktexteditor already did that in public > >headers for > >quite some time -- no-one complained. > > > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use > > > >'override' unconditionally *. > > > >We already use MSVC2012 as min VS dep, this version has full nullptr & > >override support. I don't see anyone using MSVC2010 for compiling KF5 > >to be > >honest... > > > >Proposal for [1]: > >- Raise min GCC version to 4.7 > >- Allow to use override unconditionally > >- Allow to use nullptr unconditonally > > > >ACK? > > > > > >PS: I can do the work, I can script the refactoring with clang-tidy. > > > >Let's move forward please. > > Hi, this is a really good analysis (also for future reference). In order > to > complete it, given that the original idea was "follow Qt's requirement", > and that we increased in time the required version of Qt, what is the > current status regarding compilers and Qt? Our min requirement is Qt 5.5 which according to http://doc.qt.io/qt-5/supported-platforms-and-configurations.html compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) Then that's a no-brainer, we can require gcc 4.6 too. Qt 5.9 (currently "git dev branch") uses override rather than Q_DECL_OVERRIDE, but we're far from requiring 5.9. This leads to a different proposal: - Raise min GCC version to 4.6 - Allow to use nullptr unconditionally - Use Q_DECL_OVERRIDE. I fully agree that "having 'override' is actually super useful for preventing programmer faults", but that also works if it's spelled out Q_DECL_OVERRIDE and only ineffective for people *using* frameworks on an older system with gcc 4.6. It's still effective for all of us who are working on frameworks, which is where the benefit of "override" is. What's the plan to enforce that? How is build.kde.org checking that we don't use override instead of Q_DECL_OVERRIDE? This is the point I disagree with. We define nice rules and have no means at all to ensure that they are enforced. That's something I have brought to the attention of this mailing list several times over the last years. Unfortunately nothing has changed. In my opinion we are lying to ourself and to everybody who wants to use frameworks if we say "can be compiled with gcc 4.6" when we aren't even testing that. So please let's get the ordering right: ensure that it compiles with gcc 4.6, then say we support that. The only other option is to say we require whatever gcc version build.kde.org is using. Cheers Martin
Re: To C++11 or not?
On Friday, 30 December 2016 15:25:56 CET David Faure wrote: > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > > El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va > > > > escriure: > > > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > > > >Following-up on this thread, since I saw some more discussion about > > > >C++11 > > > > > > > >usage in this RR: > > > > https://git.reviewboard.kde.org/r/129724/ > > > > > > > >Let's put this into some concrete actions, finally. I think we all > > > >agree > > > >nullptr & override are probably the most apparent issues (since > > > >compilers > > > >started to warn about both), and *having* 'override' is actually super > > > >useful > > > >for preventing programmer faults. > > > > > > > >Let's just speak about allowing nullptr & override, allowing the full > > > >set of C > > > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > > > >available only > > > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > > > > > > > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > > > >That's > > > >pretty ancient. 4.5.1 got released Jul 2010 [3] > > > > > > > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use > > > > > > > >'nullptr' unconditionally. ktexteditor already did that in public > > > >headers for > > > >quite some time -- no-one complained. > > > > > > > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use > > > > > > > >'override' unconditionally *. > > > > > > > >We already use MSVC2012 as min VS dep, this version has full nullptr & > > > >override support. I don't see anyone using MSVC2010 for compiling KF5 > > > >to be > > > >honest... > > > > > > > >Proposal for [1]: > > > >- Raise min GCC version to 4.7 > > > >- Allow to use override unconditionally > > > >- Allow to use nullptr unconditonally > > > > > > > >ACK? > > > > > > > > > > > >PS: I can do the work, I can script the refactoring with clang-tidy. > > > > > > > >Let's move forward please. > > > > > > Hi, this is a really good analysis (also for future reference). In order > > > to > > > complete it, given that the original idea was "follow Qt's requirement", > > > and that we increased in time the required version of Qt, what is the > > > current status regarding compilers and Qt? > > > > Our min requirement is Qt 5.5 which according to > > http://doc.qt.io/qt-5/supported-platforms-and-configurations.html > > compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > Then that's a no-brainer, we can require gcc 4.6 too. > > Qt 5.9 (currently "git dev branch") uses override rather than > Q_DECL_OVERRIDE, but we're far from requiring 5.9. > > This leads to a different proposal: > - Raise min GCC version to 4.6 > - Allow to use nullptr unconditionally > - Use Q_DECL_OVERRIDE. +1 from my side. I didn't know that we wanted to follow the Qt version's minimum compiler requirements. Makes sense. Thanks for chiming in! I'll port KF5 (at least the (public) headers) to nullptr if this proposal is accepted. Cheers, Kevin > I fully agree that "having 'override' is actually super useful for > preventing programmer faults", but that also works if it's spelled out > Q_DECL_OVERRIDE and only ineffective for people *using* frameworks on an > older system with gcc 4.6. It's still effective for all of us who are > working on frameworks, which is where the benefit of "override" is. > > BTW just to get a taste of the real world, I'm working with a customer right > now who is using Qt 5 and gcc 4.4 in order for their binaries to work on > the largest possible number of Linux distros out there (glibc version). > They are not using KDE Frameworks, obviously, but this is just to point out > that there are companies using older gcc versions still, this is not just > hypothetical. > > Funny that I kept saying "MSVC is what's holding us back" when in fact it's > GCC that is holding us back ;) > > > PS: I disagree with the "nobody complained" approach. Many people will > simply choose another library than complain about one library not being > suited to their constraints (one of which being the supported compiler). -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: To C++11 or not?
On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va > > escriure: > > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > > >Following-up on this thread, since I saw some more discussion about > > >C++11 > > > > > >usage in this RR: > > > https://git.reviewboard.kde.org/r/129724/ > > > > > >Let's put this into some concrete actions, finally. I think we all > > >agree > > >nullptr & override are probably the most apparent issues (since > > >compilers > > >started to warn about both), and *having* 'override' is actually super > > >useful > > >for preventing programmer faults. > > > > > >Let's just speak about allowing nullptr & override, allowing the full > > >set of C > > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > > >available only > > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > > > > > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > > >That's > > >pretty ancient. 4.5.1 got released Jul 2010 [3] > > > > > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use > > > > > >'nullptr' unconditionally. ktexteditor already did that in public > > >headers for > > >quite some time -- no-one complained. > > > > > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use > > > > > >'override' unconditionally *. > > > > > >We already use MSVC2012 as min VS dep, this version has full nullptr & > > >override support. I don't see anyone using MSVC2010 for compiling KF5 > > >to be > > >honest... > > > > > >Proposal for [1]: > > >- Raise min GCC version to 4.7 > > >- Allow to use override unconditionally > > >- Allow to use nullptr unconditonally > > > > > >ACK? > > > > > > > > >PS: I can do the work, I can script the refactoring with clang-tidy. > > > > > >Let's move forward please. > > > > Hi, this is a really good analysis (also for future reference). In order > > to > > complete it, given that the original idea was "follow Qt's requirement", > > and that we increased in time the required version of Qt, what is the > > current status regarding compilers and Qt? > > Our min requirement is Qt 5.5 which according to > http://doc.qt.io/qt-5/supported-platforms-and-configurations.html > compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) Then that's a no-brainer, we can require gcc 4.6 too. Qt 5.9 (currently "git dev branch") uses override rather than Q_DECL_OVERRIDE, but we're far from requiring 5.9. This leads to a different proposal: - Raise min GCC version to 4.6 - Allow to use nullptr unconditionally - Use Q_DECL_OVERRIDE. I fully agree that "having 'override' is actually super useful for preventing programmer faults", but that also works if it's spelled out Q_DECL_OVERRIDE and only ineffective for people *using* frameworks on an older system with gcc 4.6. It's still effective for all of us who are working on frameworks, which is where the benefit of "override" is. BTW just to get a taste of the real world, I'm working with a customer right now who is using Qt 5 and gcc 4.4 in order for their binaries to work on the largest possible number of Linux distros out there (glibc version). They are not using KDE Frameworks, obviously, but this is just to point out that there are companies using older gcc versions still, this is not just hypothetical. Funny that I kept saying "MSVC is what's holding us back" when in fact it's GCC that is holding us back ;) PS: I disagree with the "nobody complained" approach. Many people will simply choose another library than complain about one library not being suited to their constraints (one of which being the supported compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5
Re: To C++11 or not?
El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va escriure: > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: > >Following-up on this thread, since I saw some more discussion about > >C++11 > > > >usage in this RR: > > https://git.reviewboard.kde.org/r/129724/ > > > >Let's put this into some concrete actions, finally. I think we all > >agree > >nullptr & override are probably the most apparent issues (since > >compilers > >started to warn about both), and *having* 'override' is actually super > >useful > >for preventing programmer faults. > > > >Let's just speak about allowing nullptr & override, allowing the full > >set of C > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only > >available only > >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > > > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. > >That's > >pretty ancient. 4.5.1 got released Jul 2010 [3] > > > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use > > > >'nullptr' unconditionally. ktexteditor already did that in public > >headers for > >quite some time -- no-one complained. > > > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use > > > >'override' unconditionally *. > > > >We already use MSVC2012 as min VS dep, this version has full nullptr & > >override support. I don't see anyone using MSVC2010 for compiling KF5 > >to be > >honest... > > > >Proposal for [1]: > >- Raise min GCC version to 4.7 > >- Allow to use override unconditionally > >- Allow to use nullptr unconditonally > > > >ACK? > > > > > >PS: I can do the work, I can script the refactoring with clang-tidy. > > > >Let's move forward please. > > Hi, this is a really good analysis (also for future reference). In order to > complete it, given that the original idea was "follow Qt's requirement", > and that we increased in time the required version of Qt, what is the > current status regarding compilers and Qt? Our min requirement is Qt 5.5 which according to http://doc.qt.io/qt-5/supported-platforms-and-configurations.html compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) Cheers, Albert > > Ciao
Re: To C++11 or not?
Il 30 dicembre 2016 10:30:22 CET, Kevin Funk <kf...@kde.org> ha scritto: >Following-up on this thread, since I saw some more discussion about >C++11 >usage in this RR: > https://git.reviewboard.kde.org/r/129724/ > >Let's put this into some concrete actions, finally. I think we all >agree >nullptr & override are probably the most apparent issues (since >compilers >started to warn about both), and *having* 'override' is actually super >useful >for preventing programmer faults. > >Let's just speak about allowing nullptr & override, allowing the full >set of C >++11 is *not* feasible. Reason: Lot's of C++11 feature are only >available only >in MSVC2015, so we'd just be able to support the latest VS. See [2]. > >Looking at [1] I still see we list GCC 4.5 as minimum requirement. >That's >pretty ancient. 4.5.1 got released Jul 2010 [3] > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use > >'nullptr' unconditionally. ktexteditor already did that in public >headers for >quite some time -- no-one complained. > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use > >'override' unconditionally *. > >We already use MSVC2012 as min VS dep, this version has full nullptr & >override support. I don't see anyone using MSVC2010 for compiling KF5 >to be >honest... > >Proposal for [1]: >- Raise min GCC version to 4.7 >- Allow to use override unconditionally >- Allow to use nullptr unconditonally > >ACK? > > >PS: I can do the work, I can script the refactoring with clang-tidy. > >Let's move forward please. Hi, this is a really good analysis (also for future reference). In order to complete it, given that the original idea was "follow Qt's requirement", and that we increased in time the required version of Qt, what is the current status regarding compilers and Qt? Ciao -- Luigi
Re: To C++11 or not?
On Monday, 14 November 2016 10:45:07 CET Martin Gräßlin wrote: > Hi framework devs, > > recently we started to see the first patches for frameworks to silence > warnings for not used features of C++11. In particular to add override > to methods of inheriting classes. > > Now I find this weird from the perspective of our C++ requirements. On > the one side we say that we are not allowed to use these features to > still support non-C++11 compilers on the other side we see that > compilers already generate warnings if you don't use the C++11 features. > > In that particular case I do not think that Q_DECL_OVERRIDE is a > solution. It's an ugly hack and for the frameworks I maintain I gave a > -2 on the review. I think this needs a general solution of either not > adding or adding override, but not the Qt hack. > > I think this is a sign that we need to move on. We cannot continue with > the state we are in. It's too much a hassle for developers: > * false-positive compile warnings > * no way to check which features are allowed or not > * no warnings if a not allowed feature is used > * no CI system in place to ensure our rules > > Given that I want to suggest that we remove all compiler restrictions > and allow the full feature set of C++11. If someone still thinks we need > to support the compilers not supporting C++11, I would like to see a > plan on how we can improve the developer story, especially how to > address the last two points in my list above. > > Opinions? Heya, Following-up on this thread, since I saw some more discussion about C++11 usage in this RR: https://git.reviewboard.kde.org/r/129724/ Let's put this into some concrete actions, finally. I think we all agree nullptr & override are probably the most apparent issues (since compilers started to warn about both), and *having* 'override' is actually super useful for preventing programmer faults. Let's just speak about allowing nullptr & override, allowing the full set of C ++11 is *not* feasible. Reason: Lot's of C++11 feature are only available only in MSVC2015, so we'd just be able to support the latest VS. See [2]. Looking at [1] I still see we list GCC 4.5 as minimum requirement. That's pretty ancient. 4.5.1 got released Jul 2010 [3] If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use 'nullptr' unconditionally. ktexteditor already did that in public headers for quite some time -- no-one complained. If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use 'override' unconditionally *. We already use MSVC2012 as min VS dep, this version has full nullptr & override support. I don't see anyone using MSVC2010 for compiling KF5 to be honest... Proposal for [1]: - Raise min GCC version to 4.7 - Allow to use override unconditionally - Allow to use nullptr unconditonally ACK? PS: I can do the work, I can script the refactoring with clang-tidy. Let's move forward please. Cheers, Kevin [1] https://community.kde.org/Frameworks/ Policies#Frameworks_compiler_requirements_and_C.2B.2B11 [2] http://en.cppreference.com/w/cpp/compiler_support [3] https://gcc.gnu.org/releases.html [4] https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#History > Cheers > Martin -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: To C++11 or not?
On Mon, Nov 14, 2016 at 7:21 PM, Dominik Haumann <dhaum...@kde.org> wrote: > Hi, > > On Mon, Nov 14, 2016 at 10:45 AM, Martin Gräßlin <mgraess...@kde.org> wrote: >> Hi framework devs, >> >> recently we started to see the first patches for frameworks to silence >> warnings for not used features of C++11. In particular to add override to >> methods of inheriting classes. >> >> Now I find this weird from the perspective of our C++ requirements. On the >> one side we say that we are not allowed to use these features to still >> support non-C++11 compilers on the other side we see that compilers already >> generate warnings if you don't use the C++11 features. >> >> In that particular case I do not think that Q_DECL_OVERRIDE is a solution. >> It's an ugly hack and for the frameworks I maintain I gave a -2 on the >> review. I think this needs a general solution of either not adding or adding >> override, but not the Qt hack. >> >> I think this is a sign that we need to move on. We cannot continue with the >> state we are in. It's too much a hassle for developers: >> * false-positive compile warnings >> * no way to check which features are allowed or not >> * no warnings if a not allowed feature is used >> * no CI system in place to ensure our rules >> >> Given that I want to suggest that we remove all compiler restrictions and >> allow the full feature set of C++11. If someone still thinks we need to >> support the compilers not supporting C++11, I would like to see a plan on >> how we can improve the developer story, especially how to address the last >> two points in my list above. >> >> Opinions? > > The KTextEditor framework already uses e.g. override and nullptr in > some places, and no one complained so far. > > Given that even in old distros like CentOS 6 with dev-toolset-3 you > get a gcc 4.9.3 with full C++11 support, I also think we should allow > all of C++11. > > Greetings > Dominik >From a practical point of view, there's no c++11, there's what compilers support, and what we allow is what our compilers support. As far as I remember, our biggest restrictions were due to MSVC, I'd say that as soon as we can revisit the compilers, we'll get to adopt more features. That said, I'm pretty sure we aren't testing these, so we have rules but no ways to enforce them. I'm more concerned about that. Aleix
Re: To C++11 or not?
Hi, On Mon, Nov 14, 2016 at 10:45 AM, Martin Gräßlin <mgraess...@kde.org> wrote: > Hi framework devs, > > recently we started to see the first patches for frameworks to silence > warnings for not used features of C++11. In particular to add override to > methods of inheriting classes. > > Now I find this weird from the perspective of our C++ requirements. On the > one side we say that we are not allowed to use these features to still > support non-C++11 compilers on the other side we see that compilers already > generate warnings if you don't use the C++11 features. > > In that particular case I do not think that Q_DECL_OVERRIDE is a solution. > It's an ugly hack and for the frameworks I maintain I gave a -2 on the > review. I think this needs a general solution of either not adding or adding > override, but not the Qt hack. > > I think this is a sign that we need to move on. We cannot continue with the > state we are in. It's too much a hassle for developers: > * false-positive compile warnings > * no way to check which features are allowed or not > * no warnings if a not allowed feature is used > * no CI system in place to ensure our rules > > Given that I want to suggest that we remove all compiler restrictions and > allow the full feature set of C++11. If someone still thinks we need to > support the compilers not supporting C++11, I would like to see a plan on > how we can improve the developer story, especially how to address the last > two points in my list above. > > Opinions? The KTextEditor framework already uses e.g. override and nullptr in some places, and no one complained so far. Given that even in old distros like CentOS 6 with dev-toolset-3 you get a gcc 4.9.3 with full C++11 support, I also think we should allow all of C++11. Greetings Dominik
Re: To C++11 or not?
Hi all, I find it strange (not to say disappointing) that we are even talking about C++11 in 2016. +1 for the proposal. I wanted to start discussions about C++14 (the "bugfix" release of C++), but I'll wait until this discussion is finished. :) Cheers, Ivan
Re: To C++11 or not?
On 14 November 2016 at 10:45, Martin Gräßlin <mgraess...@kde.org> wrote: > Hi framework devs, > > recently we started to see the first patches for frameworks to silence > warnings for not used features of C++11. In particular to add override to > methods of inheriting classes. > > Now I find this weird from the perspective of our C++ requirements. On the > one side we say that we are not allowed to use these features to still > support non-C++11 compilers on the other side we see that compilers already > generate warnings if you don't use the C++11 features. > > In that particular case I do not think that > > Q_DECL_OVERRIDE is a solution. It's an ugly hack and for the frameworks I > maintain I gave a -2 on the review. I think this needs a general solution > of either not adding or adding override, but not the Qt hack. > > I think this is a sign that we need to move on. We cannot continue with > the state we are in. It's too much a hassle for developers: > * false-positive compile warnings > * no way to check which features are allowed or not > * no warnings if a not allowed feature is used > * no CI system in place to ensure our rules > > Given that I want to suggest that we remove all compiler restrictions and > allow the full feature set of C++11. If someone still thinks we need to > support the compilers not supporting C++11, I would like to see a plan on > how we can improve the developer story, especially how to address the last > two points in my list above. > > Opinions? > +1 I think it's time to move on for non-KF5 repos as well just to be consistent. Mayb a hint on kde-devel or a blog entry could help with that. PS: TODO: update the requirements at https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 and remove the suggestion to use Q_DECL_OVERRIDE. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
To C++11 or not?
Hi framework devs, recently we started to see the first patches for frameworks to silence warnings for not used features of C++11. In particular to add override to methods of inheriting classes. Now I find this weird from the perspective of our C++ requirements. On the one side we say that we are not allowed to use these features to still support non-C++11 compilers on the other side we see that compilers already generate warnings if you don't use the C++11 features. In that particular case I do not think that Q_DECL_OVERRIDE is a solution. It's an ugly hack and for the frameworks I maintain I gave a -2 on the review. I think this needs a general solution of either not adding or adding override, but not the Qt hack. I think this is a sign that we need to move on. We cannot continue with the state we are in. It's too much a hassle for developers: * false-positive compile warnings * no way to check which features are allowed or not * no warnings if a not allowed feature is used * no CI system in place to ensure our rules Given that I want to suggest that we remove all compiler restrictions and allow the full feature set of C++11. If someone still thinks we need to support the compilers not supporting C++11, I would like to see a plan on how we can improve the developer story, especially how to address the last two points in my list above. Opinions? Cheers Martin
Re: C++11 & friends
On Monday, 12 September 2016 09:10:46 CEST Jaroslaw Staniek wrote: > On 12 September 2016 at 08:04, Kevin Funk <kf...@kde.org> wrote: > > On Sunday, 11 September 2016 03:21:21 CEST Dominik Haumann wrote: > > > Hi all, > > > > > > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the > > > comment that Visual Studio 2012 does not support nullptr. > > > > > > While this change is trivial for obvious reasons, do we really need to > > > do > > > that? > > > > I don't think so. > > > > nullptr is actually supported since VS2010 [1]. > > > > Some other remark: I think noone's using anything below VS2015 for testing > > KDE > > on Windows anyway. I'm expecting compilation to be broken on earlier > > versions > > of VS. > > I am not only testing but also using/depend on 2013, which has quite some > C++11 features already. Alright, thanks for letting us know. > The builds of KF5 just work (this is not a CI, this > is building from time to time). Sometimes patching is needed here and there > because of completely unnecessary - for my context - dependency of > kdoctools. Things improved here in 2016 anyway. > > If not for other reasons, please note that people may depend on < 2015 > because some other component is not supported on 2015 or because od the > boss'/customer's request. > > I think fixing on a 'beeding edge' compiler may be not the best strategy, > yet I see no reason to be much less flexible in this regard than Qt is. VS2015 is no longer 'bleeding edge', it's at Update 3 already and in my experience it's a highly reliable version of VS to this date. That said, depending on VS2013 sounds fine to me of course. Cheers, Kevin > > Cheers, > > Kevin > > > > [1] http://en.cppreference.com/w/cpp/compiler_support for evidence > > > > > I am raising this question especially since KTextEditor seems to use > > > 'nullptr' in several locations now for several releases - and noone > > > complained. > > > > > > Are we supposed to turn nullptr in KTextEditor also into nullptr, or > > > can we take the liberty and ditch Q_NULLPTR completely for all > > > frameworks? > > > > > > Same also applies to 'override'. > > > > > > Best, > > > Dominik > > > > -- > > Kevin Funk | kf...@kde.org | http://kfunk.org -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: C++11 & friends
On 12 September 2016 at 09:10, Jaroslaw Staniek <stan...@kde.org> wrote: > > > On 12 September 2016 at 08:04, Kevin Funk <kf...@kde.org> wrote: > >> On Sunday, 11 September 2016 03:21:21 CEST Dominik Haumann wrote: >> > Hi all, >> > >> > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the >> > comment that Visual Studio 2012 does not support nullptr. >> > >> > While this change is trivial for obvious reasons, do we really need to >> do >> > that? >> >> I don't think so. >> >> nullptr is actually supported since VS2010 [1]. >> >> Some other remark: I think noone's using anything below VS2015 for >> testing KDE >> on Windows anyway. I'm expecting compilation to be broken on earlier >> versions >> of VS. >> > > I am not only testing but also using/depend on 2013, which has quite some > C++11 features already. The builds of KF5 just work (this is not a CI, this > is building from time to time). Sometimes patching is needed here and there > because of completely unnecessary - for my context - dependency of > kdoctools. Things improved here in 2016 anyway. > > If not for other reasons, please note that people may depend on < 2015 > because some other component is not supported on 2015 or because od the > boss'/customer's request. > > I think fixing on a 'beeding edge' compiler may be not the best > strategy, yet I see no reason to be much less flexible in this regard than > Qt is. > That said, I'd be OK to set coding standard to use nullptr and override keywords directly without macros as these are both supported since 2012. > >> >> Cheers, >> Kevin >> >> [1] http://en.cppreference.com/w/cpp/compiler_support for evidence >> >> > I am raising this question especially since KTextEditor seems to use >> > 'nullptr' in several locations now for several releases - and noone >> > complained. >> > >> > Are we supposed to turn nullptr in KTextEditor also into nullptr, or >> > can we take the liberty and ditch Q_NULLPTR completely for all >> > frameworks? >> > >> > Same also applies to 'override'. >> > >> > Best, >> > Dominik >> >> >> -- >> Kevin Funk | kf...@kde.org | http://kfunk.org > > > > > -- > regards, Jaroslaw Staniek > > KDE: > : A world-wide network of software engineers, artists, writers, translators > : and facilitators committed to Free Software development - http://kde.org > Calligra Suite: > : A graphic art and office suite - http://calligra.org > Kexi: > : A visual database apps builder - http://calligra.org/kexi > Qt Certified Specialist: > : http://www.linkedin.com/in/jstaniek > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: C++11 & friends
On 12 September 2016 at 08:04, Kevin Funk <kf...@kde.org> wrote: > On Sunday, 11 September 2016 03:21:21 CEST Dominik Haumann wrote: > > Hi all, > > > > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the > > comment that Visual Studio 2012 does not support nullptr. > > > > While this change is trivial for obvious reasons, do we really need to do > > that? > > I don't think so. > > nullptr is actually supported since VS2010 [1]. > > Some other remark: I think noone's using anything below VS2015 for testing > KDE > on Windows anyway. I'm expecting compilation to be broken on earlier > versions > of VS. > I am not only testing but also using/depend on 2013, which has quite some C++11 features already. The builds of KF5 just work (this is not a CI, this is building from time to time). Sometimes patching is needed here and there because of completely unnecessary - for my context - dependency of kdoctools. Things improved here in 2016 anyway. If not for other reasons, please note that people may depend on < 2015 because some other component is not supported on 2015 or because od the boss'/customer's request. I think fixing on a 'beeding edge' compiler may be not the best strategy, yet I see no reason to be much less flexible in this regard than Qt is. > > Cheers, > Kevin > > [1] http://en.cppreference.com/w/cpp/compiler_support for evidence > > > I am raising this question especially since KTextEditor seems to use > > 'nullptr' in several locations now for several releases - and noone > > complained. > > > > Are we supposed to turn nullptr in KTextEditor also into nullptr, or > > can we take the liberty and ditch Q_NULLPTR completely for all > > frameworks? > > > > Same also applies to 'override'. > > > > Best, > > Dominik > > > -- > Kevin Funk | kf...@kde.org | http://kfunk.org -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: C++11 & friends
On Sunday, September 11, 2016 3:21:21 AM CEST Dominik Haumann wrote: > Hi all, > > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the > comment that Visual Studio 2012 does not support nullptr. > > While this change is trivial for obvious reasons, do we really need to do > that? > > I am raising this question especially since KTextEditor seems to use > 'nullptr' in several locations now for several releases - and noone > complained. I have said so in the past and I will continue to say this: as long as we don't have a CI system which can verify the C++11 subset we are allowed to use, it's pointless to try to restrict the usage. We are humans and no compilers. Nobody can expect that we remember which calls are allowed and which not if we have C++14 compliant compilers. To me the only relevant and allowed subset of C++ is the one which compiles on build.kde.org. Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: C++11 & friends
On Sunday, 11 September 2016 03:21:21 CEST Dominik Haumann wrote: > Hi all, > > I just saw a commit by Volker turning nullptr into Q_NULLPTR with the > comment that Visual Studio 2012 does not support nullptr. > > While this change is trivial for obvious reasons, do we really need to do > that? I don't think so. nullptr is actually supported since VS2010 [1]. Some other remark: I think noone's using anything below VS2015 for testing KDE on Windows anyway. I'm expecting compilation to be broken on earlier versions of VS. Cheers, Kevin [1] http://en.cppreference.com/w/cpp/compiler_support for evidence > I am raising this question especially since KTextEditor seems to use > 'nullptr' in several locations now for several releases - and noone > complained. > > Are we supposed to turn nullptr in KTextEditor also into nullptr, or > can we take the liberty and ditch Q_NULLPTR completely for all > frameworks? > > Same also applies to 'override'. > > Best, > Dominik -- Kevin Funk | kf...@kde.org | http://kfunk.org signature.asc Description: This is a digitally signed message part.
Re: kactivities: C++11 feature test broken
Hi David, That is quite strange, since I'm regularly building more than a few projects with clang. I guess I'll remove the checks now that frameworks require compilers with basic c++11 support. Cheers Cheerio, Ivan -- KDE, ivan.cu...@kde.org, http://cukic.co/ gpg key id: 850B6F76 On 3 April 2016 at 17:22, David Faure <fa...@kde.org> wrote: > kactivities doesn't build for me with clang: > > $ clang --version > clang version 3.5.0 (tags/RELEASE_350/final 216961) > > cmake output : > > -- Checking C++ support for auto > -- Checking C++ support for auto -- not supported > -- Checking C++ support for nullptr > -- Checking C++ support for nullptr -- works > -- Checking C++ support for lambda > -- Checking C++ support for lambda -- not supported > -- Checking C++ support for override > -- Checking C++ support for override -- works > -- Checking C++ support for unique_ptr > -- Checking C++ support for unique_ptr -- works > -- Checking C++ support for variadic-templates > -- Checking C++ support for variadic-templates -- works > -- Checking C++ support for initializer-lists > -- Checking C++ support for initializer-lists -- works > CMake Error at src/CMakeLists.txt:37 (message): > You need a C++ compiler that supports the following C++11 features: auto, > lambdas and move semantics. > > > -- Configuring incomplete, errors occurred! > See also "/s/kde/build/5/frameworks/kactivities/CMakeFiles/CMakeOutput.log". > Makefile:342: recipe for target 'cmake_check_build_system' failed > gmake: *** [cmake_check_build_system] Error 1 > > -- > David Faure, fa...@kde.org, http://www.davidfaure.fr > Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Our C++11 policy?
Here's the list of features for KF5: https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 I propose to refer to that. It seems that Q_NULLPTR is used (this is violated in the current KF5 master, a JJ patch welcome). On 13 August 2015 at 10:02, Jaroslaw Staniek stan...@kde.org wrote: Hi, What would be the C++11 policy for Calligra code, at least new one? First easier thing. There's nullptr is used in KF5 (so is Q_NULLPTR). I am asking because it's important to be consistent across the Calligra code and follow the policy in code reviews. -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
On Feb. 9, 2015, 12:59 a.m., Mark Gaiser wrote: -1 You use C-Style casts. Oke, the frameworks coding style doesn't seem to explicitly forbid it (casts are not mentioned), but if i recall correctly we use the Qt style + some of our own which means we should obey the Qt style [1] which does mention casts and forbids the C-Sytle cast. Secondly, you seem to be trying to get this working on a compiler that isn't supported [2]. If one of those compilers have issues with std::lround (which i seriously doubt) then we should perhaps look into replacing it with qRound. However, Qt is also moving away from it's own algorithms in favor of the stl ones so we should stick to the std:: versions. Cheers [1] http://qt-project.org/wiki/Qt_Coding_Style [2] https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 Ivan Čukić wrote: I'm torn on this one. This is a minor edit (mainly thinking about the potential qRound version) that would fix the current master to work with an old platform. Without having any downsides (apart from possible future depreciacion of qRound). But, on the other hand, something else will probably be brought in soon that will require some more essential c++11 things, and break on osx 10.7. So, one wonders whether a patch that just prolongs the inevitable has a purpose. :) Kevin Funk wrote: Not sure if it's worth discussion this issue a lot... `qRound` isn't deprecated yet, used a lot throughout frameworks, and it doesn't look like it will be deprecated (I've yet to see a discussion on the Qt ML about this). Yet `qRound` is way more pleasant to read than `static_castint(...)`. ok for using qRound for now if it fixes build on old platforms - Marco --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75648 --- On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use qRound rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 9, 2015, 8:31 a.m.) Review request for KDE Frameworks and Marco Martin. Changes --- Changed to qRound Summary (updated) - Use qRound rather than C++11 std::lround. Repository: kdeclarative Description (updated) --- Use qRound rather than C++11 std::lround. Removes dependency on C++11. Diffs (updated) - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use qRound rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 9, 2015, 7:26 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use qRound rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
On Feb. 9, 2015, 12:59 a.m., Mark Gaiser wrote: -1 You use C-Style casts. Oke, the frameworks coding style doesn't seem to explicitly forbid it (casts are not mentioned), but if i recall correctly we use the Qt style + some of our own which means we should obey the Qt style [1] which does mention casts and forbids the C-Sytle cast. Secondly, you seem to be trying to get this working on a compiler that isn't supported [2]. If one of those compilers have issues with std::lround (which i seriously doubt) then we should perhaps look into replacing it with qRound. However, Qt is also moving away from it's own algorithms in favor of the stl ones so we should stick to the std:: versions. Cheers [1] http://qt-project.org/wiki/Qt_Coding_Style [2] https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 I'm torn on this one. This is a minor edit (mainly thinking about the potential qRound version) that would fix the current master to work with an old platform. Without having any downsides (apart from possible future depreciacion of qRound). But, on the other hand, something else will probably be brought in soon that will require some more essential c++11 things, and break on osx 10.7. So, one wonders whether a patch that just prolongs the inevitable has a purpose. :) - Ivan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75648 --- On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
On Feb. 9, 2015, 12:59 a.m., Mark Gaiser wrote: -1 You use C-Style casts. Oke, the frameworks coding style doesn't seem to explicitly forbid it (casts are not mentioned), but if i recall correctly we use the Qt style + some of our own which means we should obey the Qt style [1] which does mention casts and forbids the C-Sytle cast. Secondly, you seem to be trying to get this working on a compiler that isn't supported [2]. If one of those compilers have issues with std::lround (which i seriously doubt) then we should perhaps look into replacing it with qRound. However, Qt is also moving away from it's own algorithms in favor of the stl ones so we should stick to the std:: versions. Cheers [1] http://qt-project.org/wiki/Qt_Coding_Style [2] https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 Ivan Čukić wrote: I'm torn on this one. This is a minor edit (mainly thinking about the potential qRound version) that would fix the current master to work with an old platform. Without having any downsides (apart from possible future depreciacion of qRound). But, on the other hand, something else will probably be brought in soon that will require some more essential c++11 things, and break on osx 10.7. So, one wonders whether a patch that just prolongs the inevitable has a purpose. :) Not sure if it's worth discussion this issue a lot... `qRound` isn't deprecated yet, used a lot throughout frameworks, and it doesn't look like it will be deprecated (I've yet to see a discussion on the Qt ML about this). Yet `qRound` is way more pleasant to read than `static_castint(...)`. - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75648 --- On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use qRound rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75723 --- Ship it! Ship It! - Marco Martin On Feb. 9, 2015, 3:31 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 9, 2015, 3:31 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use qRound rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use qRound rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75724 --- Yes, this lets it build on OSX/CI. Thanks, Jeremy! - Marko Käning On Feb. 9, 2015, 4:31 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 9, 2015, 4:31 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use qRound rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use qRound rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75725 --- Ship it! Ship It! - Marko Käning On Feb. 9, 2015, 4:31 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 9, 2015, 4:31 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use qRound rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use qRound rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75719 --- Ship it! Seems ok to me - Ivan Čukić On Feb. 9, 2015, 3:31 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 9, 2015, 3:31 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use qRound rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
On Sunday 08 February 2015 18:18:48 Aleix Pol wrote: On Sun, Feb 8, 2015 at 5:55 PM, Jeremy Whiting jpwhit...@kde.org wrote: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? The policy so far has been, AFAIK, that it needs to work on Qt supported platforms: http://doc.qt.io/qt-5/supported-platforms.html Officially, our requirements are documented at: https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 However, I seem to remember an email about moving to require MSVC 2012, so it's not necessarily entirely up-to-date. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
That page was the result of the first discussion we had on C++11. More recently, there was a discussion on raising MSVC requirement. And, I'd say it was agreed to raise it to MSVC11 (VS12). At least, it was green-lighted by Kevin, Milian (I don't recall who else). I guess I should have updated the wiki afterwards... The strange thing here is that we don't usually mention clang (and stdlib versions) since it is considered 'good enough'. Cheerio, Ivan On 8 February 2015 at 18:25, Alex Merry alex.me...@kde.org wrote: On Sunday 08 February 2015 18:18:48 Aleix Pol wrote: On Sun, Feb 8, 2015 at 5:55 PM, Jeremy Whiting jpwhit...@kde.org wrote: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? The policy so far has been, AFAIK, that it needs to work on Qt supported platforms: http://doc.qt.io/qt-5/supported-platforms.html Officially, our requirements are documented at: https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 However, I seem to remember an email about moving to require MSVC 2012, so it's not necessarily entirely up-to-date. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
On Sun, Feb 8, 2015 at 5:55 PM, Jeremy Whiting jpwhit...@kde.org wrote: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? The policy so far has been, AFAIK, that it needs to work on Qt supported platforms: http://doc.qt.io/qt-5/supported-platforms.html Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
Yeah it's using the newest xcode for is x 10.7 so the libc++ is probably older, Qt supports 10.7 though so maybe we shouldn't be using these newer c++11 methods in frameworks just yet right? On Feb 8, 2015 2:04 PM, Ivan Čukić ivan.cu...@kde.org wrote: thought this was clang 3.7 maybe I'm confused though This is (should not) be a problem with the compiler version - this is a library function. Which version of libc++ is it using? (it might be using the old system's one instead of the latest release or something) Cheerio, Ivan On 8 February 2015 at 21:59, Jeremy Whiting jpwhit...@kde.org wrote: https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
thought this was clang 3.7 maybe I'm confused though This is (should not) be a problem with the compiler version - this is a library function. Which version of libc++ is it using? (it might be using the old system's one instead of the latest release or something) Cheerio, Ivan On 8 February 2015 at 21:59, Jeremy Whiting jpwhit...@kde.org wrote: https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
Qt supports 10.7 though so maybe we shouldn't be using these newer c++11 methods in frameworks just yet right? As seen on the 'policies' page, we are not tied to all the platforms that are supported by Qt. This was decided in the thread named Supported Compilers / C++11 Support in KF5, started by Volker on 21/07/2013. I'd say that, by specifying the compiler versions, we have implicitly stated that the requirements are also their respective standard library implementations. That is, if gcc 4.5 is a requirement, one should not try to compile with gcc 4.5 and a version of libstdc++ that was released a few years before gcc 4.5 went gold. The same goes for clang and msvcc. Cheers, Ivan Cheerio, Ivan On 8 February 2015 at 22:45, Jeremy Whiting jpwhit...@kde.org wrote: Yeah it's using the newest xcode for is x 10.7 so the libc++ is probably older, Qt supports 10.7 though so maybe we shouldn't be using these newer c++11 methods in frameworks just yet right? On Feb 8, 2015 2:04 PM, Ivan Čukić ivan.cu...@kde.org wrote: thought this was clang 3.7 maybe I'm confused though This is (should not) be a problem with the compiler version - this is a library function. Which version of libc++ is it using? (it might be using the old system's one instead of the latest release or something) Cheerio, Ivan On 8 February 2015 at 21:59, Jeremy Whiting jpwhit...@kde.org wrote: https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75648 --- -1 You use C-Style casts. Oke, the frameworks coding style doesn't seem to explicitly forbid it (casts are not mentioned), but if i recall correctly we use the Qt style + some of our own which means we should obey the Qt style [1] which does mention casts and forbids the C-Sytle cast. Secondly, you seem to be trying to get this working on a compiler that isn't supported [2]. If one of those compilers have issues with std::lround (which i seriously doubt) then we should perhaps look into replacing it with qRound. However, Qt is also moving away from it's own algorithms in favor of the stl ones so we should stick to the std:: versions. Cheers [1] http://qt-project.org/wiki/Qt_Coding_Style [2] https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 - Mark Gaiser On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75646 --- `qRound`? - Kevin Funk On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Nov. 2, 2013, 11:32 a.m.) Status -- This change has been marked as submitted. Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113583: Fix build after enabling C++11 standard
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- The standard says for C++ this is a function, I hope this is not a macro on some compilers... Diffs - khtml/src/xpath/predicate.cpp 3180fe5 Diff: http://git.reviewboard.kde.org/r/113583/diff/ Testing --- Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113583: Fix build after enabling C++11 standard
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/#review42837 --- Oh wait... the function has been moved to the std:: namespace for C++11, so it would break on older compilers. Is there a standard way to check if we have a C++11 compiler? - Christoph Feck On Nov. 2, 2013, 3:55 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/ --- (Updated Nov. 2, 2013, 3:55 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- The standard says for C++ this is a function, I hope this is not a macro on some compilers... Diffs - khtml/src/xpath/predicate.cpp 3180fe5 Diff: http://git.reviewboard.kde.org/r/113583/diff/ Testing --- Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113583: Fix build after enabling C++11 standard
On Nov. 2, 2013, 5:03 p.m., Christoph Feck wrote: Oh wait... the function has been moved to the std:: namespace for C++11, so it would break on older compilers. Is there a standard way to check if we have a C++11 compiler? How about using namespace std; inside that function? That should work in both cases - Alexander --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/#review42837 --- On Nov. 2, 2013, 4:55 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/ --- (Updated Nov. 2, 2013, 4:55 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- The standard says for C++ this is a function, I hope this is not a macro on some compilers... Diffs - khtml/src/xpath/predicate.cpp 3180fe5 Diff: http://git.reviewboard.kde.org/r/113583/diff/ Testing --- Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113583: Fix build after enabling C++11 standard
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/ --- (Updated Nov. 2, 2013, 7:04 p.m.) Review request for KDE Frameworks. Changes --- Alexander's suggestion. Repository: kdelibs Description --- The standard says for C++ this is a function, I hope this is not a macro on some compilers... Diffs (updated) - khtml/src/xpath/predicate.cpp 3180fe5 Diff: http://git.reviewboard.kde.org/r/113583/diff/ Testing --- Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113583: Fix build after enabling C++11 standard
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/ --- (Updated Nov. 2, 2013, 7:38 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- The standard says for C++ this is a function, I hope this is not a macro on some compilers... Diffs - khtml/src/xpath/predicate.cpp 3180fe5 Diff: http://git.reviewboard.kde.org/r/113583/diff/ Testing --- Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113583: Fix build after enabling C++11 standard
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/#review42872 --- Ship it! Ship It! - Volker Krause On Nov. 2, 2013, 7:38 p.m., Christoph Feck wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113583/ --- (Updated Nov. 2, 2013, 7:38 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- The standard says for C++ this is a function, I hope this is not a macro on some compilers... Diffs - khtml/src/xpath/predicate.cpp 3180fe5 Diff: http://git.reviewboard.kde.org/r/113583/diff/ Testing --- Thanks, Christoph Feck ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42649 --- Ship it! As discussed earlier today on IRC. This patch will do for now. - Kevin Ottens On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
Kevin Ottens wrote: Stephen Kelly wrote: It's not my decision either. It's just a recommendation. Aleix Pol Gonzalez wrote: I object. What's the big impediment of releasing ECM? If there's an impediment, let's fix it. I agree with Aleix here. I think it's important that the first frameworks we'll release are as close as possible to the final situation, ECM should be releasable by then. If something blocks that, we should try to solve it. ReviewBoard is not suited for non-patch discussion. One problem is that we have a CMakePackageConfigHelpers.cmake fork in ECM. That fork is no longer needed as of cmake master. Things like http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7994/focus=6969 could also be solved by teaching CMake something more about tests (not done yet, but I see no reason why worthwhile improvements there would not be accepted). That could obsolete ecm_mark_as_test etc. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Friday 25 October 2013 11:22:26 Stephen Kelly wrote: Kevin Ottens wrote: Stephen Kelly wrote: It's not my decision either. It's just a recommendation. Aleix Pol Gonzalez wrote: I object. What's the big impediment of releasing ECM? If there's an impediment, let's fix it. I agree with Aleix here. I think it's important that the first frameworks we'll release are as close as possible to the final situation, ECM should be releasable by then. If something blocks that, we should try to solve it. ReviewBoard is not suited for non-patch discussion. One problem is that we have a CMakePackageConfigHelpers.cmake fork in ECM. That fork is no longer needed as of cmake master. Things like http://thread.gmane.org/gmane.comp.kde.devel.buildsystem/7994/focus=6969 could also be solved by teaching CMake something more about tests (not done yet, but I see no reason why worthwhile improvements there would not be accepted). That could obsolete ecm_mark_as_test etc. Sure, I don't see how that's different from classes or methods we have in our libraries at the moment which will get obsoleted by some later Qt version. With that line of thinking we'd never release. Just mark modules which gets obsoleted as deprecated... Or I'm missing something? Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
Kevin Ottens wrote: That could obsolete ecm_mark_as_test etc. Sure, I don't see how that's different from classes or methods we have in our libraries at the moment which will get obsoleted by some later Qt version. With that line of thinking we'd never release. Just mark modules which gets obsoleted as deprecated... Or I'm missing something? /shrug/ It's your call. My opinion is that releasing a fork of something that's already in cmake master is not a good idea. Will the CMake version override the fork when it is released? That file will be in a CMake release early next year I guess. Sure, that's after you want to release karchive and threadweaver, but before everything else. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Friday 25 October 2013 11:38:40 Stephen Kelly wrote: Kevin Ottens wrote: That could obsolete ecm_mark_as_test etc. Sure, I don't see how that's different from classes or methods we have in our libraries at the moment which will get obsoleted by some later Qt version. With that line of thinking we'd never release. Just mark modules which gets obsoleted as deprecated... Or I'm missing something? /shrug/ It's your call. My opinion is that releasing a fork of something that's already in cmake master is not a good idea. Will the CMake version override the fork when it is released? That file will be in a CMake release early next year I guess. Well, yes, I agree exact forks are a problem... They should at least have a different name IMO. For instance ecm_mark_as_test is doing the right thing, there's no risk of clash later on. So if we have things which present this risk of clash, we probably need to rename them ASAP. Sure, that's after you want to release karchive and threadweaver, but before everything else. I think that we just disagree on the timing really, by its nature I think ECM should go first, even though at the last possible moment... so that'd be with the tp1 containing karchive and threadweaver. I've no problem with that particular release of ECM being marked as TP or Alpha if you want. That still leaves you free to change the interface until we get to release more of KF5... it could follow a similar cycle. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. Volker Krause wrote: while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). Ivan Čukić wrote: +1 Fair enough. I don't recommend releasing ecm with this though. I don't see any reason to release ecm when releasing KArchive and Threadweaver. I recommend just copying needed files into the first release of those instead. - Stephen --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. Volker Krause wrote: while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). Ivan Čukić wrote: +1 Stephen Kelly wrote: Fair enough. I don't recommend releasing ecm with this though. I don't see any reason to release ecm when releasing KArchive and Threadweaver. I recommend just copying needed files into the first release of those instead. I.e. both will have copies of ECMSetupVersion.cmake, ECMVersionHeader.h.in, KDEInstallDirs.cmake, KDECompilerSettings.cmake and KDECMakeSettings.cmake ? This is just so much against what was originally, at least my, idea of e-c-m: make cmake stuff we have in KDE, but which can be useful also in other projects, easier and quicker available to others (instead of not being able to release it when the first frameworks are released). But I don't object, it's your decision. - Alexander --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. Volker Krause wrote: while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). Ivan Čukić wrote: +1 Stephen Kelly wrote: Fair enough. I don't recommend releasing ecm with this though. I don't see any reason to release ecm when releasing KArchive and Threadweaver. I recommend just copying needed files into the first release of those instead. Alexander Neundorf wrote: I.e. both will have copies of ECMSetupVersion.cmake, ECMVersionHeader.h.in, KDEInstallDirs.cmake, KDECompilerSettings.cmake and KDECMakeSettings.cmake ? This is just so much against what was originally, at least my, idea of e-c-m: make cmake stuff we have in KDE, but which can be useful also in other projects, easier and quicker available to others (instead of not being able to release it when the first frameworks are released). But I don't object, it's your decision. Stephen Kelly wrote: It's not my decision either. It's just a recommendation. I object. What's the big impediment of releasing ECM? If there's an impediment, let's fix it. - Aleix --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 8:06 p.m., Stephen Kelly wrote: As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. while the CMake 3 solution is obviously much nicer, what are our alternatives until then? The current solution is adding -std=c++0x without proper compiler checks ad-hoc where needed, I think that's far worse than this change. Also, it wont detect incompatibilities with C++11 in currently C++98-only code paths. And changes here are needed anyway, since -ansi effectively prevents you from enabling C++11 (which also suggests ICC hasn't been tested in quite a while). - Volker --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/#review42081 --- Ship it! Ship It! - Kevin Ottens On Oct. 15, 2013, 6:43 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- (Updated Oct. 15, 2013, 6:43 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- (Updated Oct. 21, 2013, 6:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/#review42122 --- This review has been submitted with commit a959675fb3ca4d936cd6f8aeff437a1a444b7c38 by Volker Krause to branch frameworks. - Commit Hook On Oct. 15, 2013, 6:43 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- (Updated Oct. 15, 2013, 6:43 p.m.) Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42126 --- As the next CMake release will have a better solution which works for all compilers: set(CMAKE_CXX_STANDARD 11) I'm not in favor of adding and having to support this flag. I don't consider it my decision though. - Stephen Kelly On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
On Oct. 21, 2013, 7:18 p.m., Stephen Kelly wrote: As the next CMake release will have a better solution which works for all compilers: set(CMAKE_CXX_STANDARD 11) I'm not in favor of adding and having to support this flag. I don't consider it my decision though. Are we going to be able to depend on that version of cmake for the initial kf5 release? - Ivan --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42126 --- On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 113373: Enable C++11 support by default.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/#review42130 --- As far as I know, only threadweaver and karchive will be released in December. The rest of the frameworks won't be released until summer. By summer, CMake 3.0.0 will most likely be out. - Stephen Kelly On Oct. 21, 2013, 6:51 p.m., Volker Krause wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113373/ --- (Updated Oct. 21, 2013, 6:51 p.m.) Review request for Extra Cmake Modules, KDE Frameworks and Stephen Kelly. Repository: extra-cmake-modules Description --- Enable C++11 support by default. Diffs - kde-modules/KDECompilerSettings.cmake b745ec3c52fe66b3cfb89a334c99a5ea8ef71d4d Diff: http://git.reviewboard.kde.org/r/113373/diff/ Testing --- Compiles, all required fixes have been integrated into the frameworks branch by now (at least for the subset I have the required dependencies for). Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 113258: Fix compilation with C++11 enabled.
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/113258/ --- Review request for KDE Frameworks. Repository: kdelibs Description --- Fix compilation with C++11 enabled. QStringLiteral expands to code containing a lambda with C++11 support enabled, which then ends up in a typeof expression as part of the Q_FOREACH macro, which must not contain lambdas (similar to decltype and some other template stuff). Diffs - kded/vfolder_menu.cpp 3f7cf790bc1dd06339b67237c716fe943f6a369e tier1/kconfig/src/kconf_update/kconf_update.cpp 41923888690671d9dfd6bafc0341284796c13088 tier3/kinit/src/klauncher/autostart.cpp e0f2c74f4b935994e5d3422d8abdfa1bd955d418 tier4/kcmutils/src/ksettings/dialog.cpp 376075541c74f56ceeeb3b640cd9b791b04d32ad Diff: http://git.reviewboard.kde.org/r/113258/diff/ Testing --- Thanks, Volker Krause ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New test with C++11 and lambda (UDSEntry testcase)
On Saturday 21 September 2013 19:18:01 Mark wrote: I've just created a quite complicated testcase for frameworks which uses the new signal/slot connection syntax (since Qt 5.0) and uses a lambda as slot. The reason i did this is so that i can keep then entire testcase (minus the initialization) contained in one testcase method. Otherwise i would have to make signal/slot connections to member functions which is probably not something you want for testcases.. You can find the patch here: http://paste.kde.org/p9f82c70a/ Would this be OK to commit? This testcase would obviously have to be extended a bit to test the different detail states for UDSEntry. This test only tests the case where UDSEntry is filled with details set to 0. The default is details set to 2 which this test doesn't test (yet). I guess the question really is: - Can i use C++11 for testcases? - Can i use Lambda? The Lambda spec is supported since GCC 4.5. http://gcc.gnu.org/projects/cxx0x.html yes: http://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 Unconditionally adding -std=c++0x as you did it will probably break MSVC though. There it's on by default, so a if(NOT MSVC) should fix that. This might be something we want to set globally together with other compiler flags, ecm's KDECompilerSettings.cmake comes to mind. Looking in there, I see we still set -ansi in some cases (ICC only, probably too rare for anyone to notice), we had fun with that in Akonadi since it sets the standard back to C++98... regards, Volker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
New test with C++11 and lambda (UDSEntry testcase)
Hi, I've just created a quite complicated testcase for frameworks which uses the new signal/slot connection syntax (since Qt 5.0) and uses a lambda as slot. The reason i did this is so that i can keep then entire testcase (minus the initialization) contained in one testcase method. Otherwise i would have to make signal/slot connections to member functions which is probably not something you want for testcases.. You can find the patch here: http://paste.kde.org/p9f82c70a/ Would this be OK to commit? This testcase would obviously have to be extended a bit to test the different detail states for UDSEntry. This test only tests the case where UDSEntry is filled with details set to 0. The default is details set to 2 which this test doesn't test (yet). I guess the question really is: - Can i use C++11 for testcases? - Can i use Lambda? The Lambda spec is supported since GCC 4.5. http://gcc.gnu.org/projects/cxx0x.html Note: the test currently fails which i expected. It passes if i patch another part in UDSEntry where i'm waiting for a final OK to push. Cheers, Mark ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New test with C++11 and lambda (UDSEntry testcase)
On Saturday, 2013-09-21, Mark wrote: Hi, I've just created a quite complicated testcase for frameworks which uses the new signal/slot connection syntax (since Qt 5.0) and uses a lambda as slot. The reason i did this is so that i can keep then entire testcase (minus the initialization) contained in one testcase method. Otherwise i would have to make signal/slot connections to member functions which is probably not something you want for testcases.. Wouldn't it also be possible to use QSignalSpy? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New test with C++11 and lambda (UDSEntry testcase)
On Sat, Sep 21, 2013 at 8:39 PM, Kevin Krammer kram...@kde.org wrote: On Saturday, 2013-09-21, Mark wrote: Hi, I've just created a quite complicated testcase for frameworks which uses the new signal/slot connection syntax (since Qt 5.0) and uses a lambda as slot. The reason i did this is so that i can keep then entire testcase (minus the initialization) contained in one testcase method. Otherwise i would have to make signal/slot connections to member functions which is probably not something you want for testcases.. Wouldn't it also be possible to use QSignalSpy? Yes, that would probably remove the need for a direct lamba connection and with some more fiddling around i can probably also remove the other lambda in there with auto findFilename ... which would remove the need for C++11.. But this is kinda short as it is for what it does, it will get bigger in code if i work around it which i like to prevent. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 support on Frameworks
Le dimanche 23 juin 2013 02:16:01 Luiz Romário Santana Rios a écrit : Will the Frameworks allow C++11? How much of it will be allowed? The KDE frameworks are extensions to Qt, so same rules as in Qt, to give the frameworks the same potential audience as the Qt libraries themselves : * Can't require C++11 -- neither while compiling the framework neither while using it * Can add optional C++11 features in the headers only, in case apps use C++11. You can use the Q_COMPILER_* macros to check for available features in the compiler. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 support on Frameworks
Ignore that bit about foreach not being allowed in tier1, my ECM were just outdated. But the question about C++11 being allowed or not remains. 2013/6/23 Luiz Romário Santana Rios luizroma...@gmail.com: Hello list. I just started contributing to the Frameworks recently (I'm R_Rios on IRC) and I didn't finda thread about it in the ML archives, so I'll just ask it myself. Will the Frameworks allow C++11? How much of it will be allowed? One example of its usefulness could be the replacement of foreach by range-based for loops where moc macros aren't allowed (I think tier1 libraries don't allow it anymore, but I might be wrong, so please correct me if I'm wrong). It works in just the same way and it has the advantage of being an actual construct of the language, not a macro. Any comments will be appreciated. -- Luiz Romário Santana Rios -- Luiz Romário Santana Rios ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
