Implicit Move Won’t Go!

1991

Marshall Cline coins the term “Rule of Three“, referring to the practice of explicitly defining the C++ Copy Constructor, Copy Assignment Operator, and Destructor together as a unit (where one is needed, likely the others are, too).  The key reason for this rule was the implicit generation of copy even when they could cause harm.

2002

n1377 – A Proposal to Add Move Semantics Support to the C++ Language – is submitted for consideration for C++0x, adding two new implicit functions: a Move Constructor and Move Assignment Operator.

2010

Various Sources point out several significant problems with generating implicit move constructors and move assignment operators.  The problems occur for reasons related to the original raison d’etre of the “Rule of Three”, and I considered the need for a new “Rule of Five”.  If C++0x was to be a new language, a “Rule of Five” may have sufficed.  But it isn’t.  Current C++ code which is 100% correct could suddenly become broken due to implicit move generation.  A programming “rule of thumb” was clearly not sufficient this time around, and something had to change.

November 2010

The C++0x standards committee meeting had as its biggest issue the task of figuring out how to fix this problem, or otherwise completely remove implicit move.  Thankfully, the issue was resolved by putting strict (but coherent) limitations on when implicit move is generated, but without eliminating implicit move altogether.

I consider the new rules an enforcement of a milder version of the “rule of five” by the compiler.  Due to backwards compatibility the “rule of three” subset cannot be enforced, only deprecated.

Woot!

So we will still have implicit move in C++0x, with coherent compiler enforced limitations on generation which actually add value to boot.

I have created a diagram to outline the new dependencies, where a directed edge means “won’t be implicitly defined if this is explicitly defined”.  Green means “actually enforced”, blue means “merely deprecated”:

Notice that an implicit destructor is not dependent on anything.  In practice, move/copy constructor/assignment are so tightly coupled that they can be grouped together.

I find this easier to visualize in this form:

Note…

These diagrams only describe a subset of conditions which must be met before implicit functions will be generated.

You can read all the rules in the current Draft Standard, but my rule-of-thumb is:

• Copy Constructor: members and base classes must be copyable, and cannot have any rvalue reference members.
• Move Constructor: members and base classes must be movable or trivially copyable.
• Copy Assignment: members and base classes must be copy assignable, and cannot have any const or reference members.
• Move Assignment: members and base classes must be move assignable, and cannot have any const or reference members.

Final Thoughts

Rvalue references and move semantics are extremely powerful and cool features, and not only because of potential efficiency gains.

Copy can be hard (or impossible) to implement, and move gives us more expressiveness in designs, and that is a wonderful thing.

Implicit move is important for both consistency (why should copy be implicit and special?) and for making use of this outstanding feature far less tedious.

I congratulate the C++ standards committee on this conclusion.

Thus ends the quest for the topic of my first blog post ever..

Prologue: I was about to post this to my google buzz, but decided it was a bit too long.  I didn’t want to shorten it, but I didn’t want to trash it either.  Then a though occurs: “Thus ends the quest for the topic of my first blog post ever…”.  True story.

I just saw a cool sales pitch from a Latvian startup company.

They observed, as many have, that complaints about a product/service are often not unique, but  rather shared.   They then observed that most complaints can be resolved using already known solutions/workarounds or by correcting simple misuses/misunderstandings.  So, with some more effort, they implemented a system that integrates social communication (i.e., “twitter”) with language processing&machine learning (i.e., identify and categorize complaints) with various Q&A sources.

Their system strives to turn that frown, upside down.

Simple enough.  Common sense even:

1. While losing a customer may suck, its much worse if you don’t learn why, and worse yet if you don’t even notice (like in retail).  Unfortunately, most occurrences fall into that last category.  I hypothesize, however, that people would complain over twitter about things they would not complain about through direct correspondence.
2. By mapping a particular complaint against a set of known issues+solutions, and automatically (or semi autonomously) replying with a proposed solution, companies may be able to retain some customers, cut support costs, and maybe even get some good marketing.
3. If you can’t map a complaint to a known solution.. you should probably have support take a look at that.
4. If complaints over twitter start getting answered correctly and in a timely manner, customers may start praising how cool that is, and forget how terrible the original product/service is.

For these reasons, I think this concept has value, and every enterprise should not be expected to have to scrape all of twitter themselves, so I see the need for a good middleman here.

But then I thought something interesting.  On the off-chance that this concept really takes off, maybe customers would become conditioned, like Pavlov’s dog, to complain.  After all, they would get rewarded for it.  Maybe customers would start mentioning all those little things that were obviously just not worth mentioning before.  Sounds like that could lead to competitive advantage to me.

Now let me make an interesting analogy:

• complaints are really bug reports,
• products/services are just projects, and
• twitter is a global bug tracking repository for the whole world’s worth of projects.

Now instead of figuring out how to file a bug report for every project, making sure it’s not a duplicate, reading the rules/procedures, you just “file” straight to your own local feed while still in the moment, and let those who should care figure it out.

I would file more bug reports that way, wouldn’t you?