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@lists.isocpp.org>:
On Wed, Jan 26, 2022 at 10:40 PM Yongwei Wu <wuyongwei@gmail.com> wrote:
On Thu, 27 Jan 2022 at 04:03, Victor Eijkhout via SG20 <sg20@lists.isocpp.org> 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)