2014-10-23 12:38 GMT+03:00 Cristian Oneț <onet.crist...@gmail.com>: > 2014-07-03 16:32 GMT+03:00 Christian Dávid <christian-da...@web.de>: >> Am Mittwoch, 2. Juli 2014, 21:43:29 schrieb Fernando Vilas: >>> I think I remember reading that for either Qt5 or KF5, that C++11 was a >>> requirement. Even as far back as RHEL5, you could get the gcc44 toolchain >>> installed and use "-std=c++0x" for most of what they use. Based on the >>> state of affairs with GCC, LLVM, and MSVC, I have no problem with c++11 >>> being a requirement. This is further supported if I am remembering >>> correctly above. >> >> Both, Qt5 and KF5 do not require C++11. I do not about KF5, but Qt5 has C++11 >> support. If you build it with C++11 enabled some classes contain constexpr, >> move constructors, initialization lists and other nice improvements. >> >> But I do not know if we can make use of it, as the distributions decide if >> the >> shared libraries are compiled with C++11 enabled or not. >> >> Anyway we should enable C++11 because *we* can make our lives easier with it. >> I am sure KF5 will require it in near future (Qt probably not). Also I want >> it >> enabled because it is more fun for me :) >> >> With the compilers you are right, most features are supported by the main >> compilers for all systems (gcc, clang and MS Visual Studio) for a long time. >> >> Also I think it is questionable if someone who has a distribution which is >> several years old is interested in compiling a new (and quite untested) >> version of KMyMoney — which will be released at the end of 2014. She/he needs >> to compile huge packages like Qt5, KF5 and further dependencies as well. Who >> is willing to do that cannot be stopped with an old compiler. > > I've started to do some profiling again and found another argument for > the case that enabling C++11 would be a great benefit to the project. > > 1. We could really benefit from move semantics, our API is a perfect > fit for that (think about all the MyMoney* objects) > For example while loading a file the method which takes most CPU > cycles in the file storage object is MyMoneySeqAccessMgr::price [1]. > You might ask why is that, well... read [2] (I know it's long) and > you'll notice that the compiler can't perform RVO [3]. We need to > improve the performance of the code we write but we should not > sacrifice the readability to do this. We can fix stuff using our > current C++03 but to do it properly without hurting readability I > would suggest switching to C++11.
More about this. Since MyMoneyFile return several const objects by value (not const references) [1] it basically forces a copy of the temporary in the caller code. I think as a first step we should remove all const qualifiers from temporary values to allow compilers to perform optimizations and skip copying. Regards, Cristian [1] https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/master/entry/kmymoney/mymoney/mymoneyfile.h#L1251 > > 2. We could benefit from auto, range-based for and other stuff to > improve readability > Line like [4] would simply go away. > > 3. It would allow us (the developers) to learn new stuff and write better code > Although I'm a C++ developer I didn't write a single line of C++11 > code yet. We should be learning and having fun while working in our > free time. > > So, I totally agree with you Chris, let's enable C++11 in KMyMoney, I > know that KDevelop already needs C++11 so it shouldn't restrict us > from distributing KMyMoney in any way. I'll take care of the necessary > build system changes. > > Regards, > Cristian > > [1] > https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/master/entry/kmymoney/mymoney/storage/mymoneyseqaccessmgr.cpp#L1773 > [2] http://www.drdobbs.com/move-constructors/184403855 > [3] http://en.wikipedia.org/wiki/Return_value_optimization > [4] > https://projects.kde.org/projects/extragear/office/kmymoney/repository/revisions/master/entry/kmymoney/mymoney/storage/mymoneyseqaccessmgr.cpp#L1568 > >> >> Greetings >> Chris >> _______________________________________________ >> KMyMoney-devel mailing list >> KMyMoney-devel@kde.org >> https://mail.kde.org/mailman/listinfo/kmymoney-devel _______________________________________________ KMyMoney-devel mailing list KMyMoney-devel@kde.org https://mail.kde.org/mailman/listinfo/kmymoney-devel
