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)
>

-- 
Yongwei Wu
URL: http://wyw.dcweb.cn/