Re: [Development] Notes from "C++17 language and std library features for Qt 6"
On Wednesday, 20 November 2019 20:20:29 CET Kari Oikarinen wrote: > ## Parallel STL algorithms > > We could allow parallel execution tags in our API to let users ask for > use of parallel algorithms. > > But what are the places in Qt API that actually need these? More data > analysis stuff (if developed) would find it helpful. But often users > get to choose their own algorithms and so can use parallel algorithms > without our containers needing to know about it. > > If a parallel STL implementation is not available, falling back to > single-threaded implementation is always an option. So support could > be utilized only when available and not demanded from all platforms. > Or the platfrom support can be a shim that still always processes > everything without parallelism. > > One problem with this is that it is a very recent addition in the standard libraries, and isn't even in any released version of libc++ yet. So using it would require MSVC 2019 and gcc 9, and a future version of clang. It could be useful for image handling though, and theoretically also for raster painting if for some reason the GPU isn't used. It could be opportunistically used when available though. It would be entirely internal, and just split some operations over multiple threads. But the things it would optimize are operations that would be even faster if done on the GPU instead. 'Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Notes from "C++17 language and std library features for Qt 6"
I managed to mangle copy pasting to the mail, so probably better to read from the wiki page rather than read everything twice in a tricky order. On 20.11.2019 21.20, Kari Oikarinen wrote: > Hi! > > Here are the notes for the C++17 related session held today at QtCS. I > tried my best to capture the discussion, but there might still be a lot > of errors. > > Notes are also in the wiki at > https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes > > # Language > > > ## if constexpr > > # Language > > > ## if constexpr > > Very useful for our containers. > > > ## Fold expressions > > Shortcut for handling parameter packs of vadiadic templates. No need > to write recursive template helpers. > > > ## Inline variable > > Volker: What is the impact of using inline variables to static data > initialization? How do we deal with `Q_GLOBAL_STATIC`? > > Inline variables are safer than static globals. Compiler and linker > guarantee that there will be just one definition. > > `Q_GLOBAL_STATIC` still provides lazy initialization. So inline > variables are not a full replacement. Any big globals that aren't > necessarily used should be gated by lazy initialization to avoid > constructing them unnecessarily. > > > ## Polymorphic lambdas > > What is it? It has auto as its parameter type. So the same lambda can > be used with multiple invocations with parameters of different types. > > Most common use is just for brevity. It gives you perfect forwarding > as well, if you use auto && as the type. > > But these are not API visible, just perhaps useful inside the > implementation. > > > ## Structured bindings > > QRect and QPoint might be possible candidates. But there will not be > many that this makes sense for. > > Some of these will already be aggregates and work automatically. But > perhaps they for example have user-defined constructors and so don't > fulfill the requirements of that. > > > ## Language attributes > > There are macros for many standard attributes, like nodiscard, > deprecated, fallthrough, likely and unlikely. > > When is the right point to remove this macros and use the attributes > directly? When all compilers support it. Although that causes pain > when backporting to older branches. > > That applies to all language features, though. Some backporting is > really hairy, like converting if constexpr solutions back to template > specializations. > > > ## Modules (C++20) > > Properly modularizing Qt is going to be a huge undertaking. There > should be some prototyping done by an energetic volunteer. > > There are rumors that moc generated code leads to some issues here. > > How will `QT_CONFIG()` macros work together with modules? Every > permutation would need to be shipped as a separate module. But they > are going to be constant within a built Qt. Not something the user of > the library can change. > > Modules are not supported by build systems (including qmake and CMake) > yet. CMake developer Kitware is working on it, though. > > > ## Coroutines (C++20) > > QDialog::call/exec() are already coroutines, but stackful ones. So > converting to them stackless is not really possible. But there might > be better candidates in networking or elsewhere with callbacks. > > Standard coroutines are quite cumbersome to use. Would we use an > external helper library with that or would Qt provide their own helper > for coroutines? Having Qt-friendly coroutine helpers would be nice. > > Test data supplying is currently a huge matrix of QVariants and is > actually a performance bottleneck for our tests. Using generators for > these might be helpful? They are not going to make a difference > compared to a good hand-written generator. So the performance issues > might be fixed with other approaches. > > > # Library > > Contributions to any of these would be welcome. > > > ## std::any > > std::any is like a QVariant that does not need registration. > > Could there be conversions between QVariant and std::any? Ville is > skeptical about how to do that. Olivier suggested adding support for > conversion from std::any to QVariant into QMetatype. But can that be > done with just a reference to `std::type_info`? > > std::any is a replacement for void\*. It knows the type that it holds. > > > ## std::filesystem > > Giuseppe: Should be use std::filesystem::path types consistently in > our APIs instead of QString? Ville: There should be a prototype patch > to see how big the effect is. I'm concerned that the impact would be > too big. > > Is std::filesystem::path API stable enough? Standard committee cares > about API stability a lot, so that's not a worry. Although some want a > new version of the API that uses std::expected. > > > ## Parallel STL algorithms > > We could allow parallel execution tags in our API to let users ask for > use of parallel algorithms. > > But what are the places in Qt API that actually need these? More data > analysis stuff (if
[Development] Notes from "C++17 language and std library features for Qt 6"
Hi! Here are the notes for the C++17 related session held today at QtCS. I tried my best to capture the discussion, but there might still be a lot of errors. Notes are also in the wiki at https://wiki.qt.io/Qt_Contributor_Summit_2019_-_C%2B%2B17_Features_Notes # Language ## if constexpr # Language ## if constexpr Very useful for our containers. ## Fold expressions Shortcut for handling parameter packs of vadiadic templates. No need to write recursive template helpers. ## Inline variable Volker: What is the impact of using inline variables to static data initialization? How do we deal with `Q_GLOBAL_STATIC`? Inline variables are safer than static globals. Compiler and linker guarantee that there will be just one definition. `Q_GLOBAL_STATIC` still provides lazy initialization. So inline variables are not a full replacement. Any big globals that aren't necessarily used should be gated by lazy initialization to avoid constructing them unnecessarily. ## Polymorphic lambdas What is it? It has auto as its parameter type. So the same lambda can be used with multiple invocations with parameters of different types. Most common use is just for brevity. It gives you perfect forwarding as well, if you use auto && as the type. But these are not API visible, just perhaps useful inside the implementation. ## Structured bindings QRect and QPoint might be possible candidates. But there will not be many that this makes sense for. Some of these will already be aggregates and work automatically. But perhaps they for example have user-defined constructors and so don't fulfill the requirements of that. ## Language attributes There are macros for many standard attributes, like nodiscard, deprecated, fallthrough, likely and unlikely. When is the right point to remove this macros and use the attributes directly? When all compilers support it. Although that causes pain when backporting to older branches. That applies to all language features, though. Some backporting is really hairy, like converting if constexpr solutions back to template specializations. ## Modules (C++20) Properly modularizing Qt is going to be a huge undertaking. There should be some prototyping done by an energetic volunteer. There are rumors that moc generated code leads to some issues here. How will `QT_CONFIG()` macros work together with modules? Every permutation would need to be shipped as a separate module. But they are going to be constant within a built Qt. Not something the user of the library can change. Modules are not supported by build systems (including qmake and CMake) yet. CMake developer Kitware is working on it, though. ## Coroutines (C++20) QDialog::call/exec() are already coroutines, but stackful ones. So converting to them stackless is not really possible. But there might be better candidates in networking or elsewhere with callbacks. Standard coroutines are quite cumbersome to use. Would we use an external helper library with that or would Qt provide their own helper for coroutines? Having Qt-friendly coroutine helpers would be nice. Test data supplying is currently a huge matrix of QVariants and is actually a performance bottleneck for our tests. Using generators for these might be helpful? They are not going to make a difference compared to a good hand-written generator. So the performance issues might be fixed with other approaches. # Library Contributions to any of these would be welcome. ## std::any std::any is like a QVariant that does not need registration. Could there be conversions between QVariant and std::any? Ville is skeptical about how to do that. Olivier suggested adding support for conversion from std::any to QVariant into QMetatype. But can that be done with just a reference to `std::type_info`? std::any is a replacement for void\*. It knows the type that it holds. ## std::filesystem Giuseppe: Should be use std::filesystem::path types consistently in our APIs instead of QString? Ville: There should be a prototype patch to see how big the effect is. I'm concerned that the impact would be too big. Is std::filesystem::path API stable enough? Standard committee cares about API stability a lot, so that's not a worry. Although some want a new version of the API that uses std::expected. ## Parallel STL algorithms We could allow parallel execution tags in our API to let users ask for use of parallel algorithms. But what are the places in Qt API that actually need these? More data analysis stuff (if developed) would find it helpful. But often users get to choose their own algorithms and so can use parallel algorithms without our containers needing to know about it. If a parallel STL implementation is not available, falling back to single-threaded implementation is always an option. So support could be utilized only when available and not demanded from all platforms. Or the platfrom support can be a shim that still always processes everything without parallelism. ##
