Krita/C++11: Difference between revisions
Miabrahams (talk | contribs) |
Miabrahams (talk | contribs) unique_ptr needs bold instead of italic |
||
| Line 88: | Line 88: | ||
''Recommendation:'' | ''Recommendation:'' | ||
=== unique_ptr === | === unique_ptr === | ||
''Motivation:'' [http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 Here is a glowing review of unique_ptr]. This is really about a philosophy of C++ memory management, not just a particular smart pointer type. The idea is that whenever you create an object on the heap, you should ''always'' house it inside a smart pointer. The reason this philosophy had to wait for unique_ptr is that unique_ptr is the first time they 'got it right.' Most importantly, the class uses negligible overhead. In particular: sizeof(unique_ptr<T*>) = size_t, it can be passed as a function argument without copying, and dereferencing is inline. | '''Motivation:''' [http://www.drdobbs.com/cpp/c11-uniqueptr/240002708 Here is a glowing review of unique_ptr]. This is really about a philosophy of C++ memory management, not just a particular smart pointer type. The idea is that whenever you create an object on the heap, you should ''always'' house it inside a smart pointer. The reason this philosophy had to wait for unique_ptr is that unique_ptr is the first time they 'got it right.' Most importantly, the class uses negligible overhead. In particular: sizeof(unique_ptr<T*>) = size_t, it can be passed as a function argument without copying, and dereferencing is inline. | ||
[https://rmf.io/cxx11/rule-of-zero/ "Rule of Zero": more about the C++ design philosophy behind unique_ptr.] | [https://rmf.io/cxx11/rule-of-zero/ "Rule of Zero": more about the C++ design philosophy behind unique_ptr.] | ||
''Drawbacks:'' The philosophy mentioned above can be summarized like this: we should state up front what we are going to prohibit programmers from doing. Like the const keyword, unique_ptr puts restrictions on what can be done with the pointer, the main one being, it cannot be copied. Like enforcing const correctness, this can be annoying to get right throughout a codebase. | '''Drawbacks:''' The philosophy mentioned above can be summarized like this: we should state up front what we are going to prohibit programmers from doing. Like the const keyword, unique_ptr puts restrictions on what can be done with the pointer, the main one being, it cannot be copied. Like enforcing const correctness, this can be annoying to get right throughout a codebase. | ||
One particular limitation is that Qt container classes. For example QVector<std::unique_ptr> is invalid, because QVector requires its members can be copied. This makes converting to unique_ptr a bit slow, since QVector<T *> will have to be converted to std_array<unique_ptr<T*>>. If the owner was being copied before, it will become uncopiable. This can be a good thing, but it is work. | One particular limitation is that Qt container classes. For example QVector<std::unique_ptr> is invalid, because QVector requires its members can be copied. This makes converting to unique_ptr a bit slow, since QVector<T *> will have to be converted to std_array<unique_ptr<T*>>. If the owner was being copied before, it will become uncopiable. This can be a good thing, but it is work. | ||
| Line 98: | Line 98: | ||
[http://www.cplusplus.com/reference/memory/unique_ptr/operator=/ Moving a unique_ptr requires additional semantics.] | [http://www.cplusplus.com/reference/memory/unique_ptr/operator=/ Moving a unique_ptr requires additional semantics.] | ||
''Recommendation:'' | '''Recommendation:''' | ||
== Performance-related (rvalues) == | == Performance-related (rvalues) == | ||
Revision as of 04:00, 15 October 2015
General links about using C++11 in Qt
There have been a few links discussing mixing C++11 with Qt, and starting with Qt 5.6 C++11 support will be default. Note: as would be expected from those interested in hot new technology, the writers of most of these links demonstrate Silicon Valley levels of extreme optimism. Take this with a grain of salt: there is no such thing as a free lunch.
Here are some overviews of C++11 features.
- Bjarne Stroustrup's C++11 FAQ - the grand daddy
- An older, more balanced introduction to several topics
Qt's API design principles do not always overlap with the C++ Standards Committee design principles.
Particular Features
Under "drawbacks," every item should list: "Programmers will face another feature they must learn about."
Type Inference (auto)
Motivation:
Drawbacks:
Recommendation:
Range-based for loop
Motivation:
Drawbacks: Warning: c++11 range-based for may be slower
Recommendation:
General Initializer Lists
Motivation: Member Initializers Mixed uniform initialization
Drawbacks:
Recommendation:
Lambdas
Motivation: Lambda expressions for slots "C++11 lambdas are your friend"
Drawbacks:
Recommendation:
constexpr
Motivation: Can speed things up inside hot loops. KDAB: speed up your Qt 5 programs using C++11
Drawbacks:
Recommendation:
Override and final
Motivation:
Drawbacks:
Recommendation:
<algorithm>
Motivation:
Drawbacks:
Recommendation:
enum class
Motivation:
Drawbacks:
Recommendation:
nullptr
Motivation:
Drawbacks:
Recommendation:
Deleted and default class members
Motivation:
Drawbacks:
Recommendation:
unique_ptr
Motivation: Here is a glowing review of unique_ptr. This is really about a philosophy of C++ memory management, not just a particular smart pointer type. The idea is that whenever you create an object on the heap, you should always house it inside a smart pointer. The reason this philosophy had to wait for unique_ptr is that unique_ptr is the first time they 'got it right.' Most importantly, the class uses negligible overhead. In particular: sizeof(unique_ptr<T*>) = size_t, it can be passed as a function argument without copying, and dereferencing is inline.
"Rule of Zero": more about the C++ design philosophy behind unique_ptr.
Drawbacks: The philosophy mentioned above can be summarized like this: we should state up front what we are going to prohibit programmers from doing. Like the const keyword, unique_ptr puts restrictions on what can be done with the pointer, the main one being, it cannot be copied. Like enforcing const correctness, this can be annoying to get right throughout a codebase.
One particular limitation is that Qt container classes. For example QVector<std::unique_ptr> is invalid, because QVector requires its members can be copied. This makes converting to unique_ptr a bit slow, since QVector<T *> will have to be converted to std_array<unique_ptr<T*>>. If the owner was being copied before, it will become uncopiable. This can be a good thing, but it is work.
Moving a unique_ptr requires additional semantics.
Recommendation:
Using move constructors and rvalues are very subtle and advanced features, but widely celebrated as successes of C++11. In general these should be used inside hot paths and when we sling around objects from place to place. C++ programmers should already be aware that writing performant code inside hot paths will sometimes require slinging around ampersands. These features will naturally stay confined to the corners of the codebase where they belong, and should be introduced when they are useful.
Move Constructors
Motivation:
Drawbacks:
Recommendation:
Reference Qualifiers
Motivation:
Drawbacks:
Recommendation:
C++11 features mostly for template programming
Krita makes very light use of templates. These features are useful, coming across them in the code base will add complexity for new learners, and have not been necessary so far.
- decltype : this is the most likely to be useful, for example, in input handling teplates.
- static_assert
- std::function and std::bind
- variadic templates
Other C++11 features that probably cannot be used
- Threads (Qt/KDE use an incompatible threading model)
- shared_ptr and weak_ptr (Relies on C++ threading model; use KisSharedPointer)
- New literal types (already have QString)
- Extended Unions (already have QVariant)