Il 22/11/18 10:03, Dmitriy Purgin ha scritto:
On Thu, Nov 1, 2018 at 3:44 PM Giuseppe D'Angelo via Interest <[email protected] <mailto:[email protected]>> wrote:And every time you use C++ you have the Standard Library with you, which (crossing fingers) will have ranges in C++2a; why should Qt spend any time at all implementing something like that?I can't agree with this argument. I can't see why we can't have a Qt-way of processing containers/ranges in a more "functional" way because the standard will _maybe_ have it in future.
Side note: the One Ranges Proposal has been ratified in San Diego for inclusion in C++20:
There isn't a "why we can't", except of course that someone needs to do the work -- work that is already being done elsewhere, and that we could just use.https://herbsutter.com/2018/11/13/trip-report-fall-iso-c-standards-meeting-san-diego/
As you say yourself, we may or we may not have the ranges in C++2a. If we are lucky and we do, it will be 2020 at earliest that the standard is published, and another year or two until all the major compilers keep up and stop consider the C++2a features "experimental", which is, by the way, still the case for gcc and C++17 [1]. So we're looking at 2-4 years from now at best until all these features are "stable" and we can safely use them without risk of having to accidentally debug the standard library or a compiler bug for days.
That's correct, but this isn't an argument for not using ranges-v3 or Boost.Ranges, which are available today, work on all major platforms, are widely documented, tested, discussed, and so on.
The ranges-v3 library is fine and usable, but by using it in a customer project one has to consider additional dependencies, licenses, portability, maintainability, correctness of the library and its long-term support. The authors state themselves that the library is experimental and subject to change. One of the reasons Qt is so successful is that "it has it all", it's well documented, it generally can be seen as a single dependency, and you generally expect good quality and portability between supported platforms. If I'd see an implementation of ranges-like algorithms in the Qt framework I wouldn't hesitate to use it because I expect it to be at least Qt-grade quality.
This is an argument which is heard very often, and not just towards Qt -- for instance it's heard when trying to get $something into the Standard Library, so that one has high quality, no extra dependencies, (usually) same licensing than the compiler, and so on.
The other side of this argument is: Qt can't provide you with _everything_. The development bandwidth is finite, and therefore Qt's scope is limited. Which brings back the question: is it worth for the Qt project to invest efforts in areas that are being already covered (in an excellent way) by other libraries?
My 2 c, -- Giuseppe D'Angelo | [email protected] | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
