Date: Thu, 27 Jan 2022 17:25:48 +0800
std::optional<Obj&> is not valid C++ code. :-)
I really was comparing BigObj& (not allowing null), BigObj* (allowing
null), and optional<BigObj> (not a reference). It was not a grammar
comparison, but a usage comparison. For I have seen code that uses
optional<Obj> where an Obj* suffices—if the parameter was not optional, I
believe people would have used const Obj& instead.
On Thu, 27 Jan 2022 at 15:37, Nico Josuttis <nico_at_[hidden]> wrote:
> This was a general comment about pass by pointer.
>
> However, I wonder :
> Can we really not use std::optional for that?
> I really don't know what effect an optional reference or an optional
> passed by reference has...
>
>
> Am 27. Januar 2022 07:45:55 MEZ schrieb Yongwei Wu <wuyongwei_at_[hidden]>:
>>
>> My point is that using a pointer can be an efficient _implementation_ for
>> ‘passing an optional parameter by reference’. Just that, no more, no less.
>>
>> On Thu, 27 Jan 2022 at 14:15, Nico Josuttis <nico_at_[hidden]> wrote:
>>
>>> yes, there is no real concepts such as pass-by-pointer. I teach that
>>> only as workaround for pass-by-reference (especialky used in C).
>>>
>>> But this leads to two topics also important to teach :
>>> - pointers versus references as members
>>> - pass by value always decays, PBR does never do that
>>>
>>>
>>>
>>> Am 27. Januar 2022 05:43:57 MEZ schrieb Arthur O'Dwyer via SG20 <
>>> sg20_at_[hidden]>:
>>>>
>>>> On Wed, Jan 26, 2022 at 10:40 PM Yongwei Wu <wuyongwei_at_[hidden]>
>>>> wrote:
>>>>
>>>>> On Thu, 27 Jan 2022 at 04:03, Victor Eijkhout via SG20 <
>>>>> sg20_at_[hidden]> wrote:
>>>>>
>>>>>>
>>>>>> Why do you teach the “pass by pointer”?
>>>>>>
>>>>>
>>>>> My 2 cents here (in addition to Arthur’s good reply). I think there is
>>>>> a use in daily programming to describe ‘potentially null’. Some people
>>>>> prefer std::optional, but it has a bad performance impact, especially on
>>>>> large objects, and it can only be used on an ‘in’ parameter, but not an
>>>>> ‘out’ or ‘in-out’ parameter. If there is no ownership involved and the
>>>>> argument can be ‘missing’, I would recommend using a pointer (as versus a
>>>>> reference that is not allowed to be null).
>>>>>
>>>>
>>>> It's certainly important to teach that pointers *can be null* (and
>>>> that C++ has a keyword for this — `nullptr`!), but I don't think that's
>>>> relevant to out-parameters or "pass by pointer" per se. When we're passing
>>>> by pointer, we're always passing *some thing* by pointer:
>>>> f(x, &y); // x is passed by value or const&, we don't care which;
>>>> y is passed by pointer, indicating an out-parameter
>>>> In my particular motivating example, where we're just trying to invent
>>>> a way to pass a std::string efficiently without copying, there's obviously
>>>> no reason to ever pass a null pointer there; the pointer we pass points to *the
>>>> string*, by definition. Likewise for an out-parameter, the pointer we
>>>> pass points to *the place the result is going to go*, by definition.
>>>> Sure, hypothetically someone might call
>>>> int x;
>>>> f(x, nullptr);
>>>> passing garbage for the first parameter and null for the second; but
>>>> that's obviously foolish and we don't need to go there.
>>>> (If a student brings it up, there's lots of philosophically interesting
>>>> stuff around invariants that aren't actually invariant, especially now that
>>>> we have C++20 Concepts. For example, C++20 defines
>>>> `std::totally_ordered<float> == true`, despite the existence of `NaN`; with
>>>> basically the same rationale I gave above: "[comparing things against NaN]
>>>> is obviously foolish and we don't need to go there." C++ is full of corner
>>>> cases where something is *physically* possible but *semantically* a
>>>> bad idea. variant::valueless_by_exception() also comes to mind (but I would
>>>> rather tell a student about NaN than tell them about
>>>> valueless_by_exception! :D)
>>>>
>>>> –Arthur
>>>>
>>>>> --
>>> Nico Josuttis
>>> (sent from my mobile phone)
>>>
>>
>> --
> Nico Josuttis
> (sent from my mobile phone)
>
I really was comparing BigObj& (not allowing null), BigObj* (allowing
null), and optional<BigObj> (not a reference). It was not a grammar
comparison, but a usage comparison. For I have seen code that uses
optional<Obj> where an Obj* suffices—if the parameter was not optional, I
believe people would have used const Obj& instead.
On Thu, 27 Jan 2022 at 15:37, Nico Josuttis <nico_at_[hidden]> wrote:
> This was a general comment about pass by pointer.
>
> However, I wonder :
> Can we really not use std::optional for that?
> I really don't know what effect an optional reference or an optional
> passed by reference has...
>
>
> Am 27. Januar 2022 07:45:55 MEZ schrieb Yongwei Wu <wuyongwei_at_[hidden]>:
>>
>> My point is that using a pointer can be an efficient _implementation_ for
>> ‘passing an optional parameter by reference’. Just that, no more, no less.
>>
>> On Thu, 27 Jan 2022 at 14:15, Nico Josuttis <nico_at_[hidden]> wrote:
>>
>>> yes, there is no real concepts such as pass-by-pointer. I teach that
>>> only as workaround for pass-by-reference (especialky used in C).
>>>
>>> But this leads to two topics also important to teach :
>>> - pointers versus references as members
>>> - pass by value always decays, PBR does never do that
>>>
>>>
>>>
>>> Am 27. Januar 2022 05:43:57 MEZ schrieb Arthur O'Dwyer via SG20 <
>>> sg20_at_[hidden]>:
>>>>
>>>> On Wed, Jan 26, 2022 at 10:40 PM Yongwei Wu <wuyongwei_at_[hidden]>
>>>> wrote:
>>>>
>>>>> On Thu, 27 Jan 2022 at 04:03, Victor Eijkhout via SG20 <
>>>>> sg20_at_[hidden]> wrote:
>>>>>
>>>>>>
>>>>>> Why do you teach the “pass by pointer”?
>>>>>>
>>>>>
>>>>> My 2 cents here (in addition to Arthur’s good reply). I think there is
>>>>> a use in daily programming to describe ‘potentially null’. Some people
>>>>> prefer std::optional, but it has a bad performance impact, especially on
>>>>> large objects, and it can only be used on an ‘in’ parameter, but not an
>>>>> ‘out’ or ‘in-out’ parameter. If there is no ownership involved and the
>>>>> argument can be ‘missing’, I would recommend using a pointer (as versus a
>>>>> reference that is not allowed to be null).
>>>>>
>>>>
>>>> It's certainly important to teach that pointers *can be null* (and
>>>> that C++ has a keyword for this — `nullptr`!), but I don't think that's
>>>> relevant to out-parameters or "pass by pointer" per se. When we're passing
>>>> by pointer, we're always passing *some thing* by pointer:
>>>> f(x, &y); // x is passed by value or const&, we don't care which;
>>>> y is passed by pointer, indicating an out-parameter
>>>> In my particular motivating example, where we're just trying to invent
>>>> a way to pass a std::string efficiently without copying, there's obviously
>>>> no reason to ever pass a null pointer there; the pointer we pass points to *the
>>>> string*, by definition. Likewise for an out-parameter, the pointer we
>>>> pass points to *the place the result is going to go*, by definition.
>>>> Sure, hypothetically someone might call
>>>> int x;
>>>> f(x, nullptr);
>>>> passing garbage for the first parameter and null for the second; but
>>>> that's obviously foolish and we don't need to go there.
>>>> (If a student brings it up, there's lots of philosophically interesting
>>>> stuff around invariants that aren't actually invariant, especially now that
>>>> we have C++20 Concepts. For example, C++20 defines
>>>> `std::totally_ordered<float> == true`, despite the existence of `NaN`; with
>>>> basically the same rationale I gave above: "[comparing things against NaN]
>>>> is obviously foolish and we don't need to go there." C++ is full of corner
>>>> cases where something is *physically* possible but *semantically* a
>>>> bad idea. variant::valueless_by_exception() also comes to mind (but I would
>>>> rather tell a student about NaN than tell them about
>>>> valueless_by_exception! :D)
>>>>
>>>> –Arthur
>>>>
>>>>> --
>>> Nico Josuttis
>>> (sent from my mobile phone)
>>>
>>
>> --
> Nico Josuttis
> (sent from my mobile phone)
>
-- Yongwei Wu URL: http://wyw.dcweb.cn/
Received on 2022-01-27 09:26:00