Update. I have updated the post a bit, as it misled a number of people to think that you need to define the move constructor in a
cpp file. This is not so. I have now also highlighted another important feature of my solution: statically checked
I am not satisfied with the solution I gave in the previous post. The proposed interface was this:
// more resources
// Tools's interface
Tool(Tool &&) = default; // noexcept is deduced
Tool& operator=(Tool&&) = default; // noexcept is deduced
Tool(Tool const&) = delete;
Tool& operator=(Tool const&) = delete;
In a way, it is self contradictory. The whole idea behind departing from the Rule of Zero is to separate the interface from the current implementation. Yet, as the comments indicate, the exception specification is deduced from the current implementation, and thus unstable. Continue reading
Update. One remark in this post about compile-time messages was untrue. As K-ballo has pointed out, declaration
=default does not mean that we have a declared and usable member function. Ville Voutilainen also suggested how to fix the situation with a
static_assert. This section is now corrected.
Update. I no longer consider the advice given in this post a good one. I left it for reference, but I encourage you to also read this post.
You have probably already heard about the Rule of Zero formulated by R. Martinho Fernandes:
Classes that have custom destructors, copy/move constructors or copy/move assignment operators should deal exclusively with ownership. Other classes should not have custom destructors, copy/move constructors or copy/move assignment operators.
I have run into a certain problem when trying to apply it, and today I wanted to share my observations with you. I noted that Scott Meyers also expressed his concerns about some interpretations of the rule (see here); I came to a similar conclusion, however my problem is somewhat different. Continue reading
Posted in programming
Recently, I was hit by one C++11 gotcha. It is funny: I know about it, I have blogged about it, and nonetheless I still fell into the trap. Continue reading
Today an announcement about the code::dive conference for software developers hosted in Wrocław, Poland in November. The call for papers is still open. It may be your chance to share your experience with other programmers. I attended the conference last year and found it quite interesting.
In this post we will see a library for storing nullable/optional values that can in certain situations replace and outperform Boost.Optional. Continue reading
Recently as part of program run-time performance optimization effort, I was scanning through the code for occurrences of keyword
new. The goal was to find unnecessary memory allocations. I was surprised to find most of
news in the unit test module. Not that there was any particular need for memory allocation: it is just that the framework that was chosen (a fairly popular one) enforces on the programmers bad practices of manually controlling the life-time of their objects. Continue reading
Today, we will continue with the implementation of a type capable of storing short codes. For the previous post on the subject see here. This time, we will focus on type safety. Continue reading