Date: Sat, 06 Sep 2025 22:03:15 +0100
Hello Frederick, I've read your paper, well organized. I just want to attract your attention that according to the standard, a type which is not an lvalue ref, or an rvalue ref, is by definition a prvalue. Which means a plain object of type T is a prvalue.T{args...}; // prvalue of type T constructed with args...So you don’t need a special token for prvalue. As for the example you mention in paragraph 3.2, Calling::new(p) T(arg);Will copy construct in-place, which is not viable for an atomic object type (Not moveable, not copyable)you can just use std::memcpy to transfer the atomic into the buffer of your class MyOptional, so instead of::new(p) T(arg);You will write:std::memcpy(p, &arg, sizeof(T));But this is not a correct solution for all cases.For expl if your temporary(=prvalue) T has an owning pointer as a member data, then after the closing scope of MyOptional::emplace, member function, the temporary is destroyed and the owning pointer will delete its resource.So basically your prvalue object type must be trivially destructible.So if I have to rewrite the implementation of MyOptional::emplace, it will be as followT& emplace(T val){ static_assert (std::is_trivally_destructible_v<T>); std::memcpy((void*)buf, &val, sizeof(T)); this->has_value_bool = true; return *static_cast<T*>(buf);}-----------My proposal is about the same subject as yours but on different side.It is mainly about effecient move operations, and compact assembly generation.
-------- Original message --------From: Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Date: 9/6/25 3:23 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]> Subject: Re: [std-proposals] Unlocking the potential of prvalue & xrvalue On Saturday, September 6, 2025, organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:Hello,Given the following function signature:RetType foo(T&& arg);There is no way to tell, from inside the function block, if the parameter passed to this function is a prvalue or an xrvalue, since both can bind to T&&.Despite there is a fundamental difference between prvalue and xrvalue, yet we are not taking advantage of that because we cannot differentiate between them.Is there any proposal talking about this problem?RegardsOgI toyed with this a while back: http://www.virjacode.com/papers/prvalue_params.htm
-------- Original message --------From: Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Date: 9/6/25 3:23 PM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]> Subject: Re: [std-proposals] Unlocking the potential of prvalue & xrvalue On Saturday, September 6, 2025, organicoman via Std-Proposals <std-proposals_at_[hidden]> wrote:Hello,Given the following function signature:RetType foo(T&& arg);There is no way to tell, from inside the function block, if the parameter passed to this function is a prvalue or an xrvalue, since both can bind to T&&.Despite there is a fundamental difference between prvalue and xrvalue, yet we are not taking advantage of that because we cannot differentiate between them.Is there any proposal talking about this problem?RegardsOgI toyed with this a while back: http://www.virjacode.com/papers/prvalue_params.htm
Received on 2025-09-06 21:03:20