3 ms·
Re: the last paragraph, C++ has temporary materialization — space for temporary objects is not actually “allocated” until the object needs storage (commonly whe
by tylerhou 2y ago
Re: the last paragraph, C++ has temporary materialization — space for temporary objects is not actually “allocated” until the object needs storage (commonly when it binds to a reference). The problem is that push_back takes by rvalue reference, which forces a materialization of the temporary. I don’t see a way around forcing materialization because taking a reference requires some uniform representation for the reference — the temporary could have been constructed by any one of its possibly many constructors. Forwarding arguments makes the parameters explicit, and the language already has support for this, so I don’t see a huge need for adding more magic.
- _huayra_ 2y agoIs this true with respect to the ABI? I get how a temporary is blown away at the end of a statement with a `;` if it wasn't bound to a reference that extends its lifetime, but wouldn't the code need to allocate a return slot regardless? What I'm thinking of would be ```c++ struct MyBigClass { /* lots of members */ }; MyBigClass makeABigOne(); auto main() -> int { // We still need to construct a return slot here, even though we don't use the value, right? makeABigOne(); } ``` Perhaps this is tangential, but I'm wondering if maybe I'm missing a subtly based on what you mean by "allocated" (in the abstract machine, or in the ABI).
- tylerhou 2y agoApparently temporary materialization also occurs when “when a prvalue appears as a discarded-value expression.” https://en.cppreference.com/w/cpp/language/implicit_conversion#Temporary_materialization https://en.cppreference.com/w/cpp/language/implicit_conversi... So yes, storage for the (to-be discarded) object must be allocated, and the object is constructed into that storage. I don’t know enough about the ABI to comment about the last point.