Thread: new standard

Originally Posted by phantomotap

My prediction is that programmers who understand the intent and capabilities of "rvalue references" will always use them. (Providing at least move assignment and move construction operators for anything not trivially copied.)

The whole problem is one of what is a "trivial" copy versus a move essentially being a destructive copy. To use the example of a swap() function

Code:

template<class T> swap(T &a, T &b)
{
      T tmp(move(a));
      a = move(b);
      b = move(tmp);
}

Where move() essentially enables the move construction or assignment. The thing is, in the first line it effectively destroys the object a. The second line then reconstructs a, with the contents of b, and destroys b. The last line then reconstructs b with the data that was in a.

Granted, there are efficiency gains ... if everything goes right. But one of the common maintenance problems in classes with user-supplied copy constructors or assignment operators has been the problem of ensuring those functions work correctly (eg correctly copy all members). And what does the "move construction" introduce ..... a requirement to potentially maintain a larger set of such functions. Unless performance is highly critical - which it is in some applications, but not in many - that is, on the face of it, a maintenance burden.

All this is at odds with accepted best practices, that encourage getting code functionally right first in the simplest and most maintainable form, and then worrying about addressing any performance deficiencies - in other words, discouraging premature optimisation. Instead, what we have is an encouragement for programmers to perform premature optimisation. That will eventually yield a series of constraints and guidelines concerning whether a class should support move construction/assignment or not. We already have an example where constraints have to be imposed related to exceptions. A few more such constraints - particularly if they rely on losts of care and consideration by the programmer - and it will be easier for programmers (who, let's face it, are often careless and inclined to waste productive time with premature optimisation) to use other techniques.

Yeah, I'm sure others will make different predictions to mine. The proof will be in the practice down-track, I guess. As a matter of fact, I hope I'll be proven wrong, but don't think I will be.

Originally Posted by King Mir

Perhaps, if they depreciate throw declarations now, then ten years time it will make sense to replace it with something else, but no sooner.

There are only two possible circumstances I can see in which changing exception specifications will cause confusion.

1) Addition of new constructs, which fail to compile at present anyway. This will only cause confusion if new code is ported to old compilers, but that's a common problem with all new language features. Deprecation will not stop programmers from running new code through old compilers.

2) Practical problems associated with turning run-time checks (eg calling abort() when an unexpected exception is thrown) into compile time checks.

Would you care to characterise practical circumstances in which changing current run-time enforcement of exception specifications to compile time checks presents a real disadvantage?

Yes, it is true that some old code will fail to compile. I consider those circumstances are a non-issue. Firstly, the amount of such code is small (since exception specifications have been actively discouraged - to the extent there is consideration of deprecating exception specifications). Second, the cause of failure will, most likely, be related to existing undiagnosed faults in code.

Originally Posted by grumpy

Firstly, the amount of such code is small (since exception specifications have been actively discouraged - to the extent there is consideration of deprecating exception specifications).

Sure, the amount of code is small, but the committee decided to be extra conservative here. Better to not break any previously valid code at all.

Second, the cause of failure will, most likely, be related to existing undiagnosed faults in code.

No I think the greatest the cause of the failure will be due to inconsistent use of throws decelerations.

But one of the common maintenance problems in classes with user-supplied copy constructors or assignment operators has been the problem of ensuring those functions work correctly (eg correctly copy all members). And what does the "move construction" introduce ..... a requirement to potentially maintain a larger set of such functions. Unless performance is highly critical - which it is in some applications, but not in many - that is, on the face of it, a maintenance burden.

All this is at odds with accepted best practices, that encourage getting code functionally right first in the simplest and most maintainable form, and then worrying about addressing any performance deficiencies - in other words, discouraging premature optimisation. Instead, what we have is an encouragement for programmers to perform premature optimisation.

We have two types of classes that should have move constructors.

One is objects that aren't copyable, but where it would be an interface advantage to have them movable. Examples of this are unique_ptr and thread. There is no copy constructor there, so you maintain exactly one state transfer function. This is more than if there were no move constructors, but at the gain of interface expressiveness, so it's not about optimization.

The other is objects that are copyable, but where copying is very slow, while moving would be fast. In this case, the move constructor is a performance optimization, but at the same time, it's also easily added later. So it's not an encouragement to do premature optimization.

Another point is that moving an object is very well encapsulated in that object and thus easy to test, so libraries that provide movable types should be able to say with high confidence that these work.

I don't like the idea that we're forced to ensure move constructors are non-throwing. I don't know if a move constructor should throw or not, probably not, but to be on the safe side...
I also think the current suggestion is a mess.
First they suggest concepts. Then the noexcept specifier. Then implicit noexcept. Then throw specification (eg throw(...)), and finally a noexecpt block!
Come on!
Would it hurt to have just two types of keywords--one of throwing and one for not throwing? The exception specifications are there... they just need to be static. And the throw(...) exception extension already exist, so why not make it the universal may throw?
They are complicating this too much.

Originally Posted by Elysia

They are complicating this too much.

Bingo!

When programming language features become too complex, programmers tend to abuse them. The deliberate abuses tend to become problems for their successors (the poor suckers who must maintain the code) and accidental abuses create immediate problems of debugging and maintenance. Not to mention the burden for compiler vendors to get their compilers right, introduce particular interpretations of the grey areas, etc etc.....

The move construct, on it's own, strikes me as deceptively simple and elegant. But some of the associated consequences are pretty intrusive. And it is that wider picture that concerns me.

Originally Posted by phantomotap

O_o

So... you think "a lot of serious programmers will actively avoid rvalue references"... because it is easy to get it wrong the first time?

*shrug*

I said nothing of the sort.