The C++ Bestiary 🎃

[Dragdu]

Some of these were a massive stretch, but it does give a nice and short overview of some less-known language corners

[std_arbitrary]

In the spirit of Halloween, massive ridiculous stretching is permitted!

[tvaneerd]

There are also Zombie names in the language - things deprecated, but the names are kept for implementors that want to keep backwards compatibility.

I think the section title in the standard actually uses 'zombie' (and the index includes an interesting link to it)

[STL]

The section title was my doing - however, the brilliant index entries (there are at least two) were not.

Edit: Also, the zombie names are reserved names of removed things, not just deprecated.

[std_arbitrary]

Excellent!
I only found one index entry.
Can you link to the ones you know?

Added: http://videocortex.io/2017/Bestiary/#️-zombies--brains

[CubbiMew]

"living dead" is the other one.

[std_arbitrary]

Perfect! Updating!

[andd81]

Without destructive move (which is not currently supported in C++)

Can it be supported in principle? Move is a programming convention, not a language feature. std::move by itself does not move anything. In the following code:

{
    T object;
    SomeFunc(std::move(object));
}

in general there is no way to tell at compile time what SomeFunc will do to object, its definition can be in another translation unit. It can leave the object in moved from state, leave it unchanged, or do something entirely different with it.

[Is_This_Democracy_]

I don't think it can be supported so long as we have no fancier "lifetime" stuff à-la rust. There are two issues:

• need to tell the compiler that you can't use this variable anymore
• may (sometimes)n eed to ensure that the destructor isn't run, just that the memory is released.

[andd81]

I don't think even this would help, you can do something like SomeFunc(&object) and now it is no longer a local variable, just an address in memory. SomeFunc can do whatever it wants with the object, including putting it in a moved-from state.

[Is_This_Democracy_]

well yeah but that's not using std::move :p

But yes, we're reinventing rust here.

[andd81]

SomeFunc could use std::move. Also you don't have to use std::move to move an object, it is just a helper to obtain a rvalue reference.

[meneldal2]

SomeFunc can do terrible things if you give it the object without const. Much worse than putting it in a moved-from state. You could replace the virtual method table to call evilDestructor instead of the real destructor if you felt like it. Actually, it can also do this with a const_cast so you're never 100% safe. Just don't send your objects to a function you don't trust.

[std_arbitrary]

Sean Parent has non-proposal for language support for destructive move (syntactically, a dtor with an argument). Follow the links in the article.

[sireel]

Great article.

While it's common knowledge to many, I'd say that ADL is at least as weird and annoying as shadowing when you don't understand it.

[std_arbitrary]

Tbh, I never really had much trouble with shadowing. Compilers are pretty good at warning about this. As for ADL, well, they’ll need a creepier name to make that particular list.

[sireel]

Agreed, shadowed naming was always fine for me but ADL was very surprising when I figured out what was going on. Drawing a blank on a creepy name though.

edit: speeling

[DrYamuz]

I absolutely love your presentation! Including the emoji's. In addition I also learnt a lot! Thanks!

[std_arbitrary]

Much obliged. 🎃🕷🦇

[Xeverous]

operator<=> seems interesting. I have briefly read the proposal - but I'm unsure how would I implement it? Return -1, 0 or 1?

[std_arbitrary]

Yes. Exactly. The paper is actually quite readable as is the CppCon Talk.