Date: Mon, 16 Dec 2024 12:50:52 +0200
I failed to consider that it would still use default constructors.
Yes this very basic class would not work because the reference must not be
trivially copied
By defining our own copy and move constructors we can evade this issue
foo(const foo& other) : actual_value_(other.actual_value_) {}
foo(foo&& other) : actual_value_(other.actual_value_) {}
On Mon, 16 Dec 2024, 12:40 Robin Savonen Söderholm, <
robinsavonensoderholm_at_[hidden]> wrote:
> https://godbolt.org/z/YMMdaq3MM
>
> See for yourself. Here is the code if the godbolt link does not work:
> ```cpp
>
> #include <print>
>
> class foo {
> int actual_value_;
> public:
> int const& value_ref = actual_value_;
> foo(int i) : actual_value_(i) {}
>
> void set_value(int i) {
> actual_value_ = i;
> }
> };
>
> int main() {
> auto main_foo = foo(1);
> auto foo_copy = main_foo;
> foo_copy.set_value(2);
> std::print("And foo_copy should have value 2 and has '{}'\n",
> foo_copy.value_ref);
> }
> ``` . Spoiler alert, it prints 1.. Even worse if you return a foo from a
> function in which you may have a dangling reference (if you ain't "lucky"
> and RVO saves you... which just hides the problem for a while). // Robin
>
> On Mon, Dec 16, 2024 at 11:33 AM Oskars Putans <o.putaans_at_[hidden]>
> wrote:
>
>> I'm fairly certain this copies and moves don't break the reference as it
>> always references the local variable, not the other variable. Because both
>> the member and the reference have the same lifetime, it shouldn't under any
>> circumstances be dangling.
>>
>> Can you provide an example where this does break?
>>
>>
>> On Mon, 16 Dec 2024, 12:23 Robin Savonen Söderholm, <
>> robinsavonensoderholm_at_[hidden]> wrote:
>>
>>> First I have to apologize, I misunderstood the feature... You mean that
>>> you want to have something like the getter/setter decorators used in Python?
>>>
>>> Secondary, the ref thing is broken because it would be wrong or even
>>> dangling reference the moment Foo is copied/moved.
>>>
>>> // Robin
>>>
>>> On Mon, Dec 16, 2024, 11:11 Oskars Putans via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> What if you used
>>>>
>>>> class Foo {
>>>> private:
>>>> int value;
>>>> public:
>>>> const int& readOnlyValue = value;
>>>> };
>>>>
>>>> as a way of exposing a const version?
>>>>
>>>> It might not work in all use cases as it does remove
>>>> std::is_trivially_assignable trait from
>>>> the class, but this gets rid of an explicit getter and reduces
>>>> boilerplate. If you want to support assignment, you need to write your own
>>>> overloads. This method is slightly shady, however, as other developers
>>>> might make
>>>> the assumption that this value won't change. I would rather use getters
>>>> for this, but this is one alternative you can consider. Realistically, as a
>>>> proposal to core cpp, there's a very low likelihood that this would make
>>>> the cut.
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>
Yes this very basic class would not work because the reference must not be
trivially copied
By defining our own copy and move constructors we can evade this issue
foo(const foo& other) : actual_value_(other.actual_value_) {}
foo(foo&& other) : actual_value_(other.actual_value_) {}
On Mon, 16 Dec 2024, 12:40 Robin Savonen Söderholm, <
robinsavonensoderholm_at_[hidden]> wrote:
> https://godbolt.org/z/YMMdaq3MM
>
> See for yourself. Here is the code if the godbolt link does not work:
> ```cpp
>
> #include <print>
>
> class foo {
> int actual_value_;
> public:
> int const& value_ref = actual_value_;
> foo(int i) : actual_value_(i) {}
>
> void set_value(int i) {
> actual_value_ = i;
> }
> };
>
> int main() {
> auto main_foo = foo(1);
> auto foo_copy = main_foo;
> foo_copy.set_value(2);
> std::print("And foo_copy should have value 2 and has '{}'\n",
> foo_copy.value_ref);
> }
> ``` . Spoiler alert, it prints 1.. Even worse if you return a foo from a
> function in which you may have a dangling reference (if you ain't "lucky"
> and RVO saves you... which just hides the problem for a while). // Robin
>
> On Mon, Dec 16, 2024 at 11:33 AM Oskars Putans <o.putaans_at_[hidden]>
> wrote:
>
>> I'm fairly certain this copies and moves don't break the reference as it
>> always references the local variable, not the other variable. Because both
>> the member and the reference have the same lifetime, it shouldn't under any
>> circumstances be dangling.
>>
>> Can you provide an example where this does break?
>>
>>
>> On Mon, 16 Dec 2024, 12:23 Robin Savonen Söderholm, <
>> robinsavonensoderholm_at_[hidden]> wrote:
>>
>>> First I have to apologize, I misunderstood the feature... You mean that
>>> you want to have something like the getter/setter decorators used in Python?
>>>
>>> Secondary, the ref thing is broken because it would be wrong or even
>>> dangling reference the moment Foo is copied/moved.
>>>
>>> // Robin
>>>
>>> On Mon, Dec 16, 2024, 11:11 Oskars Putans via Std-Proposals <
>>> std-proposals_at_[hidden]> wrote:
>>>
>>>> What if you used
>>>>
>>>> class Foo {
>>>> private:
>>>> int value;
>>>> public:
>>>> const int& readOnlyValue = value;
>>>> };
>>>>
>>>> as a way of exposing a const version?
>>>>
>>>> It might not work in all use cases as it does remove
>>>> std::is_trivially_assignable trait from
>>>> the class, but this gets rid of an explicit getter and reduces
>>>> boilerplate. If you want to support assignment, you need to write your own
>>>> overloads. This method is slightly shady, however, as other developers
>>>> might make
>>>> the assumption that this value won't change. I would rather use getters
>>>> for this, but this is one alternative you can consider. Realistically, as a
>>>> proposal to core cpp, there's a very low likelihood that this would make
>>>> the cut.
>>>> --
>>>> Std-Proposals mailing list
>>>> Std-Proposals_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>>
>>>
Received on 2024-12-16 10:51:09