[Development] QtCS: Notes from Modern C++ session

André Somers andre at familiesomers.nl
Fri Jun 12 08:08:51 CEST 2015


Hi,

I made notes in the Modern C++ session. You can also find them on the 
Wiki here: https://wiki.qt.io/QtCS2015_ModernCpp but I was requested to 
also post them here on the ML. If you were there and remember things 
differently, please edit and post a reply with corrections.

======

Sunday June 7, 10:00 AM

Impact on supported compilers: VS2012 from 5.6. onwards and LTS release 
Discussed more in depth with the deprecation session
What kind of features do we want, and what version of C++? 11? 14? What 
are the minimum requirements, even if we don’t rely on the existance of 
the feature? Qt is 5-8 years behind on C++, due to its nature. Auto, 
constexpr, lambda’s, r-value ref, decltype, nullptr, … (missed the 
rest). From compiler detection Variadic templates? We don’t use too many 
templates at all… QNX is not a problem in terms of compatibility. Gcc 
needs 4.7 for decent support of modern cpp. OS/X on gcc is dead, use 
clang instead. For windows embedded (EC) rely on MSVC 2012.

Available for use then:
* Auto
* decltype
* nullptr
* r-value ref
* lambda
* class enum
* explicit overrides

Not available for use are:
* uniform initialization and constexpr (is broken in VS2013.)
* Explicit conversions,
* = default,
* = deleted,
* inheriting constructors,
* noexcept

C++/11 needed for user applications as well then. It also lightens the 
maintenance burden.

When to use?
============
Don’t go overboard. We need some guidelines. QtCreator team has 
experience. r-value, deltype are no-brainers. Class enums are a bit more 
of a discussion. It needs testing, and do we want that in the API? There 
is an inconsistency with existing API. The Qt:: scope is a big 
collection that would have been clearer. Auto is for use in code, not in 
API. Use auto where the type is (implicity) also on the right side. 
Iterators is a prime example. Creator may be used as a rule of thumb: if 
creator can’t follow them, don’t use them. Nullptr should be used in the 
headers, they need to be cleaner than the implementation. In source 
pointers: where it increases readability. Where it is not unclear, feel 
free to use 0 instead. It may cause some minor source incompatibilities. 
Don’t change existing code for the sake of this.

Library use
=========
We can’t detect the version, but we might require a minimum? Wishlist :
* std::initialize lists
* std::move
* std::function
* type traits (including enable_if),
* std::forward
* nulltpr_t
* std::chrono?
* shared_ptr
* unique_ptr. QScopedPointer might be made movable now.
New smart pointer session, or on the Mailing list?

TODO: We need to test this what is supported with the base line compilers.

No for now: std::for_each (issues with leaks)
For now, don’t put std lib ABI into Qt ABI, except for nulltpr_t.
For lambda’s: how to deal with captures? They are dangerous. Default to 
capture by value, capture by reference or pointer is problem.

We need to be a bit conservative in our public API for now, until we get 
some more experience. First learn, then slowly introduce.


André

-- 




More information about the Development mailing list