QtCS2015 ModernCpp: Difference between revisions
(First version of notes) |
No edit summary |
||
Line 31: | Line 31: | ||
=== When to use? === | === When to use? === | ||
Don’t go overboard. We need some guidelines. Creator 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. | 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. | 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 === | === Library use === |
Revision as of 22:35, 7 June 2015
C++ session notes
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: Yes:
- Auto
- decltype
- nullptr
- r-value ref
- lambda
- class enum
- explicit overrides
No:
- 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. Creator 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 :
- 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 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.