I personally use in_place_type_t whenever I want to pass a type into a constructor. My PolymorphicWrapper type uses it to allow you to construct an object in the owned storage “In Place” Also there is a std::in_place_type variable template.
One of the more obscure parts of the language - a parameter that literally serves as a bodge to select the correct constructor. IMO a bad design choice - though I admit that an alternative, taking into account limitations of the language, is hard to come up with.
It could have been auto x = std::variant::make_in_place (a, b, c); And depend on guaranteed copy elision. But it's not much difference here, and it's perhaps even worse to read. ;-)
I see that it optimized to mov a value of 6 but it still allocated the vector? or is the operator new for the 6? does std::optional prevent allocation elision?
std::optional is complex, and that video is old. It's very possible that a modern compiler or std::optional implementation would do something different there. But in any case, we are hoping/relying on the optimizer to do things.
I was thinking the other day on the bus, that it'd be nice if they added a layer of syntax sugaring ala c# for c++ (possibly between the parse tree and the preprocessor?) where things like in-place initialization could be replaced by this (or some other code) and possibly have some compile-time reflection maybe? And that it would be a compiler parameter that you can turn on/off?
Compile-time reflection has been in the works since July 2014, specifically for enums. [1] Lets hope it makes it to C++20. [1] www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4113.pdf
But is it really better than simply constructing an object from an rvalue? Can't compilers optimize calls like these so that their assembly would be identical to what's generated for "std::in_place[_...]"?
Both std::variant and std::any can take multiple types, so you have to specify which type you have in mind when initializing them. That's why you use std::in_place_type_t. And in variant you can specify which type you mean by indexing it, say std::variant you have 0 for int, 1, for double and 2 for Bleh.
Michał Gawron - I know. And this is meant to be a sort of tutorial video for people who want to learn C++ better. So I think being explicit about that in the video would've been a good idea.
And with C++17: `std::optional x(std::vector{1, 2, 3});`
Thanks to class template argument deduction.
Am I the only one who reads std as "standard?"
its better than reading it as sexually transmitted disease
I go between "standard" and "stud"
I personally use in_place_type_t whenever I want to pass a type into a constructor. My PolymorphicWrapper type uses it to allow you to construct an object in the owned storage “In Place”
Also there is a std::in_place_type variable template.
One of the more obscure parts of the language - a parameter that literally serves as a bodge to select the correct constructor. IMO a bad design choice - though I admit that an alternative, taking into account limitations of the language, is hard to come up with.
It could have been auto x = std::variant::make_in_place (a, b, c);
And depend on guaranteed copy elision. But it's not much difference here, and it's perhaps even worse to read. ;-)
@@michal.gawron Would it have been possible to just have it as std::make?
@@_RMSG_ What about other types : T2, T3, ..., Tn?
I see that it optimized to mov a value of 6 but it still allocated the vector? or is the operator new for the 6? does std::optional prevent allocation elision?
std::optional is complex, and that video is old. It's very possible that a modern compiler or std::optional implementation would do something different there. But in any case, we are hoping/relying on the optimizer to do things.
I was thinking the other day on the bus, that it'd be nice if they added a layer of syntax sugaring ala c# for c++ (possibly between the parse tree and the preprocessor?) where things like in-place initialization could be replaced by this (or some other code) and possibly have some compile-time reflection maybe? And that it would be a compiler parameter that you can turn on/off?
Compile-time reflection has been in the works since July 2014, specifically for enums. [1]
Lets hope it makes it to C++20.
[1] www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4113.pdf
Thanks for the info!
But is it really better than simply constructing an object from an rvalue? Can't compilers optimize calls like these so that their assembly would be identical to what's generated for "std::in_place[_...]"?
It would've been nice to see why plain old ::std::in_place wouldn't work for variant or any. Also, what the neck is the index one for?
Both std::variant and std::any can take multiple types, so you have to specify which type you have in mind when initializing them. That's why you use std::in_place_type_t. And in variant you can specify which type you mean by indexing it, say std::variant you have 0 for int, 1, for double and 2 for Bleh.
Michał Gawron - I know. And this is meant to be a sort of tutorial video for people who want to learn C++ better. So I think being explicit about that in the video would've been a good idea.