benjaminLindley

@Gary:

// After this next call, "t" holds the exception_ptr
// it's no longer in the union space.
auto t = std::move(rhs.spam);

No, it is in union space.  rhs.spam is still an exception_ptr at this point. It is until the destructor is called. t is also one.

// There is no guarantee that the space ham is built in is
// empty but that doesn't matter, it will just overwrite
// anything currently there.
new(&rhs.ham) T(std::move(ham));

Writing over what is currently there is the opposite of "doesn't matter".  It's undefined behavior.  That always matters.

But.. exception_ptr is a shared_ptr, so if he moves it first, there is nothing that will happen by calling the destructor, it's a null-op.

You can't know that, period.

3 hours ago, C64 wrote

*snip*

Sure. Just an example: I use STL classes like std::vector and std::map, and I almost completely ignore template metaprogramming (things like std::enable_if, etc.). I don't know if inside STL implementation it is used, but as an STL client, I can just ignore it.

You can ignore rvalue references as well, and your code will be as good as it was two years ago.  Better, infact.  Especially if you use the standard library.

If you tend to write classes which just use default copy semantics, and rely on internal, well written members (from the standard library, for example) to copy themselves, then your classes will automatically have correct move semantics.  They will be, infact, better than they were before this feature existed, through no effort of your own.  This is, in my opinion, how almost all classes should be written anyway.

If, however, you tend to write classes with specialized copy semantics, then your classes will be no worse than they were two years ago, and you can learn to use rvalue references at your own pace, when you feel like you want to supercharge your code.

@Vincent: You have another option actually.  Write one constructor, taking all of your parameters by value, then move them where they need to be.  This may result in additional moves, but never additional copies (unless there is no move constructor, which is not the case for strings).

Person(string f, string m, string l, string a)
    :firstName(move(f)),
     middleName(move(m)),
     lastName(move(l)),
     address(move(a))
{}

The quality of information in this talk was almost at STL's level.  Impressive.

@Int64: Sounds like it's modeled similarly to std::map, where operator[] inserts an element if one is not there, and so cannot be const.  Does it have an at() function?  Or a find() function? I can't check it myself at this time.

And speaking of that @Devs, is there any way for us to view the code online or off without having to run a setup program that only works on Windows?  Or at least a way to see the full interface even if we can't see the implementation?

7 hours ago

@bejamin: >Then you could choose between safe and efficient selectively with a typedef or a `using` statement.

Very bad idea. Especially for templates this could be a hazard. But Herb already mentioned the good solution. Have "restrict()" do the work, just as it is for C++.AMP right now.

@Luna: Could you please elaborate on why you believe it would be a hazard?

8 hours ago, hsutter wrote

It has made me think again about doing a scrub of all standard C++ language and library features and marking some as "unsafe" in some way (possibly that allows overloading, such as for vector::op[] overloads for safe and unsafe instead of the current hack of providing op[] and at() which almost nobody uses), then supporting a switch that enables only safe mode. I believe I know how to do that very efficiently now that we have C++11.

What about this idea.  Have a separate namespace within or beside std, call it safestd.  In there have safe substitutes for various functionality in the standard.  Then you could choose between safe and efficient selectively with a typedef or a `using` statement.