Date: Mon, 21 Aug 2023 19:22:58 +0400
it was a pseudocode, not std::optional, just something which is declared as
inline struct optional {
T value;
bool b;
};
and all methods in fact are expression aliases, like macro
пн, 21 авг. 2023 г. в 19:15, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]>:
> As far as I understood, 'stores all fields separatelly',
>
> the class layout is dissolved,
>
> and all member variables are stored individually as local variables.
>
>
>
> So the storage for o.value is provided by the caller, the other member
> variables are stored on the stack (local to the function).
>
>
>
> Besides a lot of issues with class encapsulation (and the restrictions for
> which class types it would be allowed and whether one would want such a
> feature, even if it would be implementable),
>
> it would be really difficult for the member functions of std::optional to
> find their member variables. They would not be a constant index within the
> object memory storage, but each member variable would have its individual
> pointer.
>
>
>
> It would not be any longer a single *this pointer. Besides problems with
> calling the member variables, you would get problems with identity of
> objects and with storing references and pointers to objects.
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 21.08.2023 17:09
> *Betreff:* Re: [std-proposals] Copy-construct, move-construct, and
> PR-construct
> *An:* std-proposals_at_[hidden];
> *CC:* Jason McKesson <jmckesson_at_[hidden]>;
> On Mon, Aug 21, 2023 at 11:04 AM Nikl Kelbon via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Hmm, may this problem be solved by 'inline' structs/ variables?
> > Like
> >
> > inline optional o = foo(); // stores all fields separatelly
> > return o.value; // return 'field' which is local value
> really here, so NRVO possible
>
> That's not how NRVO works. It is only permitted in the case of `return
> <local_variable>;`, not `return <local_variable>.<member>;`. It would
> be impossible to implement it in the way you're talking about, since
> it is the caller who provides storage for the return value. And thus,
> the caller would have to know to provide enough storage for `o`.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
inline struct optional {
T value;
bool b;
};
and all methods in fact are expression aliases, like macro
пн, 21 авг. 2023 г. в 19:15, Sebastian Wittmeier via Std-Proposals <
std-proposals_at_[hidden]>:
> As far as I understood, 'stores all fields separatelly',
>
> the class layout is dissolved,
>
> and all member variables are stored individually as local variables.
>
>
>
> So the storage for o.value is provided by the caller, the other member
> variables are stored on the stack (local to the function).
>
>
>
> Besides a lot of issues with class encapsulation (and the restrictions for
> which class types it would be allowed and whether one would want such a
> feature, even if it would be implementable),
>
> it would be really difficult for the member functions of std::optional to
> find their member variables. They would not be a constant index within the
> object memory storage, but each member variable would have its individual
> pointer.
>
>
>
> It would not be any longer a single *this pointer. Besides problems with
> calling the member variables, you would get problems with identity of
> objects and with storing references and pointers to objects.
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> *Von:* Jason McKesson via Std-Proposals <std-proposals_at_[hidden]>
> *Gesendet:* Mo 21.08.2023 17:09
> *Betreff:* Re: [std-proposals] Copy-construct, move-construct, and
> PR-construct
> *An:* std-proposals_at_[hidden];
> *CC:* Jason McKesson <jmckesson_at_[hidden]>;
> On Mon, Aug 21, 2023 at 11:04 AM Nikl Kelbon via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > Hmm, may this problem be solved by 'inline' structs/ variables?
> > Like
> >
> > inline optional o = foo(); // stores all fields separatelly
> > return o.value; // return 'field' which is local value
> really here, so NRVO possible
>
> That's not how NRVO works. It is only permitted in the case of `return
> <local_variable>;`, not `return <local_variable>.<member>;`. It would
> be impossible to implement it in the way you're talking about, since
> it is the caller who provides storage for the return value. And thus,
> the caller would have to know to provide enough storage for `o`.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
Received on 2023-08-21 15:23:11