Arthur, for your last point raised, I point them to this table:
https://stackoverflow.com/a/47736813/2085626


בתאריך יום ד׳, 26 בינו׳ 2022, 23:38, מאת Arthur O'Dwyer via SG20 ‏<
sg20_at_[hidden]>:

> On Wed, Jan 26, 2022 at 3:03 PM Victor Eijkhout <eijkhout_at_[hidden]>
> wrote:
>
>> On , 2022Jan26, at 13:33, Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
>> wrote:
>>
>> FWIW, I teach
>> - pass-by-value
>> - problems: performance of all those copies; how to write an
>> out-parameter?
>> - C solution: pointers (a pointer holds a memory address)
>> - pass-by-pointer
>> - C++ enhancement: references (***)
>> - pass-by-reference
>>
>>
>> I agree with your sequence, and I use something very similar.
>>
>> But…..
>>
>> Why do you teach the “pass by pointer”? Maybe you and I have different
>> audiences.
>>
>
> I'm sure we do. :) At least three reasons come to mind:
> - My target audience is usually new-hire software engineers, who will have
> taken C in college and so they already know pointers are coming; they
> probably think they're scary and confusing (because their college professor
> did a terrible job explaining them); there's no point trying to hide the
> fact that C++ has pointers because the students are already aware of it.
> Give them a quick glimpse of the monster in the first five minutes. :)
> - Pass-by-pointer solves the technical machine-level problem of "how do I
> pass a Widget efficiently without copying?" You just pass its address;
> technical problem solved! The only problem with pointers is that they
> *look* ugly. So we immediately present C++'s solution to the *looking
> ugly *problem, which is to use references instead of pointers. But
> references aren't magic, and they aren't inscrutable; they behave exactly
> like pointers. Usually I'll fire up Godbolt at this point to show that we
> get the exact same x86-64 machine instructions for `int ptr(int *p) {
> return *p; }` and `int ref(int& r) { return r; }`. References *behave*
> like pointers, but *look* like values; and this is why they're so
> awesome. They let us write code that *looks* like it's taking a string by
> value, but *behaves* as efficiently as if it were taking just a pointer.
> (We have already introduced the phrase "zero-overhead abstraction" by this
> point.)
> - Most industry codebases pass out-parameters by pointer as a matter of
> style. This is a fine place to talk about that, since they'll be expected
> to do it on the job.
>
> I don't bring pointers back into the discussion until `new` and `delete`
> (which again are *relatively* quickly wrapped up in C++ clothing via
> `unique_ptr`, although not right away, because we have to get there via
> move semantics, and move semantics are justified by
> pilfering/taking-ownership, which is justified by talking about
> responsibilities of ownership, and the primary interesting responsibility
> to talk about is the responsibility to call `delete`).
>
>
> > Agree with describing a reference as “a new name”. I usually call it an
> alias. (And I stress how it is not a pointer, for the students that have
> learned C)
>
> I reserve "alias" for its technical meaning — type aliases, a.k.a.
> typedefs. I call references references. But I do implicitly analogize them
> to names, in that I talk about how when we assign `i = 1;` we're (of
> course) not actually assigning to the *letter* `i`; we're assigning to
> the object *referred to* by the name `i`. And when we assign `r = 1;`,
> we're not assigning anything to `r` *itself*; we're assigning to the
> object *referred to* by `r`.
>
>
> @Nico:
> > As with universal references become state of the art for ordinary
> programmers with C++20, I wonder whether we should now teach them early or
> even first.
>
> Hard no. Forwarding references are not ordinary-programmer material, nor
> should they ever be. (Ranges relies heavily on forwarding references, but
> essentially *nothing* in the average programmer's life is a Ranges-style
> range.)
> Tangentially related: I have recently run into multiple intermediate-level
> C++ programmers who knew just enough about value categories to be
> *surprised* to find that `const T&` will bind to an rvalue argument —
> they were, like, honestly trying to puzzle out the right way to refactor
> `void f(const string&)` so that it would accept rvalue strings! (It already
> does accept them, of course.)
> I've quipped that `const T&` is "the O.G. universal reference," in that it
> has bound to both lvalues and rvalues since C++98.
>
> –Arthur
> --
> SG20 mailing list
> SG20_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg20
>