[Development] QtCS 2017 QtCore sessions

Jean-Michaël Celerier jeanmichael.celerier at gmail.com
Sun Dec 3 20:02:19 CET 2017


> . I would be fine having the same developer experience in C++
even if I had to change name spaces and includes, but doesn't seem usual
practice in C++.


uh... ? I have been polyfilling optional, string_view, any, and variant for
almost three years with boost, or std/experimental/. The API is 99%
compatible to what's in std.



-------
Jean-Michaël Celerier
http://www.jcelerier.name

On Sun, Dec 3, 2017 at 5:41 PM, Alejandro Exojo via Development <
development at qt-project.org> wrote:

> On Saturday 02 December 2017 19:11:23 Boudewijn Rempt wrote:
> > > > And, c'mon, std::optional's API is just not going to be topped by
> > > > QOptional. What should they do? snake_case vs. camelCase? That's what
> > > > we need to invest several man-days of development work in, to rename
> > > > the functions and stick a Q in front of the class name?
> > >
> > > There's one thing that a QOptional could do that std::optional can't:
> > > be available for all Qt users
> > > in a time span of a couple of months.
>
> True. And that, in my very humble opinion, highlights a common problem that
> people face in projects in all languages: wanting to use a standard
> functionality that is not yet available in the platforms that you have to
> support. Many other languages are able to "polyfill"/shim
> not-yet-standardized
> classes or functions (even members) in a clean way, by adding a 3rd party
> library and done. I would be fine having the same developer experience in
> C++
> even if I had to change name spaces and includes, but doesn't seem usual
> practice in C++.
>
> > And another thing: be properly documented in a way that people who
> > are not CS phd's can understand. std completely and utterly fails
> > in that. Parts of Qt's docs are bad enough, but there's nothing in
> > cppreference.com that would pass muster for my gsoc students.
>
> I wholeheartedly agree. I understand the argument of the lambda in find_if
> in a
> somewhat intuitive way, but the explanations that one finds there about it
> are
> hugely discouraging to me (full of standardese), even if it's been some
> years
> using C++. It's not rare to see pages documenting a class or function,
> that,
> instead of giving examples of its usage, show instead three possible
> implementations. When you are trying to understand how it's used, or why
> it's
> useful. :-(
>
> And a 3rd point, that not necessarily applies to QOptional if everything is
> templated and inline, but I think still the main blocker for using more
> standard API is the lack of ABI stability. Yes, that's misfeature for some,
> but it's the current rule, so ignoring it is not helping the conversation,
> IMHO.
>
> --
> Viking Software, Qt and C++ developers for hire
> http://www.vikingsoftware.com
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20171203/849d18f0/attachment.html>


More information about the Development mailing list