[Interest] Chasing a standard

[Jean-Michaël Celerier]

> As I said a couple of times, we do not intend to break APIs in any major
way when moving towards Qt 6. That also implies that our container API is
there to stay. But where we can streamline/align with standard C++ in good
ways, we probably should try to do that.

It's not only about breaking APIs but also breaking current observable
behaviour - i.e. performance. Currently if you're passing data across
threads - e.g. compute something in a thread and pass the result to the
main thread to display it - you generally pass a QVector / QList /
QWhatever that does implicit sharing, because the signal-slot mechanism
will do a copy of the object in any case across threads and doing two
atomic operations for a QVector copy is cheaper than creating a new
std::vector, calling malloc, and copying 500 ints however you look at it.
What is the option if Qt opts out from this ? put everything in shared_ptr
?

Best,
Jean-Michaël


On Sun, Nov 4, 2018 at 10:52 PM Lars Knoll <lars.knoll at qt.io> wrote:

> > On 4 Nov 2018, at 22:13, Roland Hughes <roland at logikalsolutions.com>
> wrote:
> >
> > Quoting Elvis Stansvik:
> >
> > ====
> > Sorry to say it, but welcome to C++
> >
> > No, mostly kidding. I think what you suggest sort of makes sense. If
> > Qt are to keep its containers, with a goal of offering an alternative
> > more convenient/Java-esque API, then a helper member function like you
> > suggest seems to fit that goal. Whether Qt still has this as a goal in
> > another matter. Maybe not to the extent that they once had?
> >
> > For the pattern above, I guess one could make a generic helper in a
> > header of the application. I know e.g. Qt Creator has a bunch of such
> > helpers in its headers.
> > ====
> >
> > I would like to weigh in a vote for Qt keeping its containers. The
> reason behind that vote is the ever present installed base.
>
> I think most people working on developing Qt are fully aware of this. As I
> said a couple of times, we do not intend to break APIs in any major way
> when moving towards Qt 6. That also implies that our container API is there
> to stay. But where we can streamline/align with standard C++ in good ways,
> we probably should try to do that.
>
> > We already lose droves of Qt developers every year when Qt keeps moving
> on but medical devices, border security systems like cargo x-ray, train
> control systems, etc. have to fork their own version of Qt because Qt keeps
> moving on without a 5-8 year LTS.
>
> Yes, the Open source and standard commercial versions come with a maximum
> of 3 years for LTS releases. But you can get longer support for Qt versions
> from The Qt Company though.
> >
> > At this point their are hundreds, thousands, perhaps millions of Qt
> example programs scattered around the Internet, many of which don't bother
> to name the Qt version they were written with, not to mention "official"
> texts which will now mostly not work.
> >
> >
> https://www.barnesandnoble.com/w/c-gui-programming-with-qt-4-2nd-edition-jasmin-blanchette/1101413840?ean=9780132354165
> >
> > Granted that one actually names Qt 4 but programming languages as wells
> as their libraries have a time honored tradition of just adding, not
> dropping major components.
>
> For the largest part. But it’s important to realise that sometimes
> dropping some parts is required to keep things maintainable (as the number
> of people working on Qt is not growing infinitely), and to be able to adapt
> to a changing world. Of course we’ll have to be careful doing that.
>
> Cheers,
> Lars
>
> >
> > Okay, BASIC dropped IRREGARDLESS and C++ has _finally_ dropped
> trigraphs, but neither were major components.
> >
> > Yes, I have heard various young guns in here chanting the mantra "why
> spend resources maintaining something std now does?" Well, the installed
> base is the reason. Under the hood feel free to change them dramatically,
> but, maintain the API. It doesn't matter if std:: is adopting many Qt-esque
> things, we have always had levels of compatability with std:: I mean
> QString has had it since I started with Qt, seriously, back at 4.0. My 3.x
> time was just dabbling.
> >
> > The second argument I will make in favor of keeping the containers is
> the mantra which drew so many to Qt so many years ago.
> >
> > All objects derived from QObject are cleaned up on exit.
> >
> > Yes, that is very Java like. When we start mixing and matching QObject
> containers with std:: we run the risk of going straight back to the dark
> ages writing programs for feeble PC based operating systems which cannot
> clean up behind a process. (Before anyone challenges that they need to read
> up on OpenVMS, MVS, and Z/OS.)
> >
> > I will cede the point that foreach will probably die a much deserved
> death in the near future, even if it remains in the package. Range-based
> for loops
> > https://en.cppreference.com/w/cpp/language/range-for
> > and especially for_each
> > https://en.cppreference.com/w/cpp/algorithm/for_each
> >
> > The dark side of Qt's foreach was making a copy to operate on. Yes,
> there were reasons for it, but, it was a stumbling block for more than one
> developer new to Qt and in the embedded systems world, that copy could be
> massively expensive.
> >
> > --
> > Roland Hughes, President
> > Logikal Solutions
> > (630) 205-1593
> >
> > http://www.theminimumyouneedtoknow.com
> > http://www.infiniteexposure.net
> > http://www.johnsmith-book.com
> > http://www.logikalblog.com
> > http://www.interestingauthors.com/blog
> > http://lesedi.us
> >
> > _______________________________________________
> > Interest mailing list
> > Interest at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/interest
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20181105/68715384/attachment.html>