So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

We started writing our Windows user interface in the Windows 1.0 era
using plain old C. I converted it to C++ back in 2001 or so but I never
used references since I just brought the C code mostly in. I converted
all of the Smalltalk code to C++ but I did not use references there either.

Lynn


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

W dniu 5.06.2026 oÿ05:20, Lynn McGuire pisze:

So which do you prefer for your method parameters that you modify,
address of or reference ?

References have well known "return problem" (which is an crash error).
For eg.:

Obj& Class1::function1( /* params here */ )
{
Obj lResult;

/* code here */

return lResult; // Code valid, but crash guaranteed!
}

The other problem is lack "nullptr" for references.

Probably the only advantage is that you can use references in many
places where pointers are required, and you can still use "normal" type operators (without overload operators). There was huge difference in the
past, because in C you can not overload operators. But nova days in C++
it is easy to write:

Obj& Class1::operator=(const Obj* b) { /* code here */ }
or:
Obj& operator=(Obj* a, const Obj* b) { /* code here */ }
Obj& operator=(Obj& a, const Obj* b) { /* code here */ }

So, references seems to be ugly C compiler hack.

--
Z totaliztycznym salutem!
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, UE ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

W dniu 5.06.2026 oÿ06:26, ??Jacek Marcin Jaworski?? pisze:

Obj& Class1::operator=(const Obj* b) { /* code here */ }

Sorry, should be:

Obj& Obj::operator=(const Obj* b) { /* code here */ }

--
Z totaliztycznym salutem!
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, UE ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them. They
are a little more subtle than the dereference operator.

Have you considered multiple return values? They are not suitable for everything, but can be a good alternative to passing a pointer (or
reference) to an output parameter.

Otherwise first consider if the parameter could be null. If that is
possible, you need to use a pointer.

Then consider the clarity of the caller code. Passing by reference
looks a lot like passing by value. Indeed, if the function is not
modifying the parameter, prefer to pass by const reference if it is too
big (or otherwise expensive to copy) to pass conveniently by value.

If the function is called as "x = modify_this_thing(ys);", a reference
could be fine. If it is called as "x = make_a_thing(ys);", then it
looks like the parameter is being used by value - making the parameter a pointer so that the caller must use "&ys" makes it clearer that it might
be modified.

I don't think there is a single "right" answer here - think primarily
about how easy it would be for people to misunderstand what the code does.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/5/2026 6:20 AM, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

Please do not use references for "output parameters". If you have not
used them, then you don't have any such legacy, which is good, you can
skip that stage and be happier than many of us:

Instead, return multiple values in a pack (std::tuple or std::pair).

std::tuple<int, std::string, double> foo() {
// ...
return {x, y, z};
// or return std::make_tuple(x, y, z);
// if your compiler does not support the better syntax.
}

auto [x, y, z] = foo();

or if your compiler does not support that,

int x;
std::string y;
double z;
std::tie(x, y, z) = foo();

which is still better than

int x;
std::string y;
double z;
foo(x, y, z); // no hint that x, y, z are modified by foo().



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/5/2026 1:58 AM, David Brown wrote:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?ÿ They are not suitable for everything, but can be a good alternative to passing a pointer (or reference) to an output parameter.

Yeah. Fwiw, I was pondering on that for a function of mine for my field
based DLA algo:
________________
ct::vector_field::vector_point const*
hit_test(
glm::vec2 const& p0,
float hit_eps
) {
for (auto const& f0 : m_field.m_point_vec)
{
glm::vec2 pdif = p0 - f0.m_origin;
float pdis = glm::length(pdif);

if (pdis < hit_eps)
{
return &f0;
}
}

return nullptr;
}
________________

It returns a pointer to the field vector. So, its rather dangerous, but
I know how to use it fine. The point is that I am using a pointer to
gain the data _and_ show success and failure.

std::optional<std::reference_wrapper<T>>?

Otherwise first consider if the parameter could be null.ÿ If that is possible, you need to use a pointer.

Then consider the clarity of the caller code.ÿ Passing by reference
looks a lot like passing by value.ÿ Indeed, if the function is not
modifying the parameter, prefer to pass by const reference if it is too
big (or otherwise expensive to copy) to pass conveniently by value.

If the function is called as "x = modify_this_thing(ys);", a reference
could be fine.ÿ If it is called as "x = make_a_thing(ys);", then it
looks like the parameter is being used by value - making the parameter a pointer so that the caller must use "&ys" makes it clearer that it might
be modified.

I don't think there is a single "right" answer here - think primarily
about how easy it would be for people to misunderstand what the code does.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/5/2026 3:58 AM, David Brown wrote:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?ÿ They are not suitable for everything, but can be a good alternative to passing a pointer (or reference) to an output parameter.

Otherwise first consider if the parameter could be null.ÿ If that is possible, you need to use a pointer.

Then consider the clarity of the caller code.ÿ Passing by reference
looks a lot like passing by value.ÿ Indeed, if the function is not
modifying the parameter, prefer to pass by const reference if it is too
big (or otherwise expensive to copy) to pass conveniently by value.

If the function is called as "x = modify_this_thing(ys);", a reference
could be fine.ÿ If it is called as "x = make_a_thing(ys);", then it
looks like the parameter is being used by value - making the parameter a pointer so that the caller must use "&ys" makes it clearer that it might
be modified.

I don't think there is a single "right" answer here - think primarily
about how easy it would be for people to misunderstand what the code does.

Yes, passing function parameters by reference is subtle. And that is
what I worry about.

I have been trying it in a few places to see if I like it. Such as:
int uniout5 (doublereal val [], const longint n, doublereal *sum, std::string & names, const longint key, const longint ksp);

Lynn


Lynn




--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever! In math valid function has the only one
value for each valid arg (even for very big and for very small numbers).
C lang authors follow this great design! Please do not break the root C
lang rules!

--
Z totaliztycznym salutem!
Jacek Marcin Jaworski, Pruszcz Gd., woj. Pomorskie, Polska ??, UE ??;
tel.: +48-609-170-742, najlepiej w godz.: 5:00-5:55 lub 16:00-17:25; <jmj@energokod.gda.pl>, gpg: 4A541AA7A6E872318B85D7F6A651CC39244B0BFA;
Domowa s. WWW: <https://energokod.gda.pl>;
Mini Netykieta: <https://energokod.gda.pl/MiniNetykieta.html>;
Mailowa Samoobrona: <https://emailselfdefense.fsf.org/pl>.
UWAGA:
NIE ZACI?GAJ "UKRYTEGO D?UGU"! P?A? ZA PROG. FOSS I INFO. INTERNETOWE!
CZYTAJ DARMOWY: "17. Raport Totaliztyczny - Patroni Kontra Bankierzy": <https://energokod.gda.pl/raporty-totaliztyczne/17.%20Patroni%20Kontra%20Bankierzy.pdf>


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 6 Jun 2026 15:28:01 +0200 =?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?= gabbled:

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever! In math valid function has the only one
value for each valid arg (even for very big and for very small numbers).
C lang authors follow this great design! Please do not break the root C
lang rules!

A C function is not a mathematical function. Anyway , C++ still only ever returns a single object from a function but recent syntax updates allows it
to seem as if multiple items are being returned.

eg: auto [a,b,c] = func();

If you have a problem with that bear in mind you've already been able to
return a structure in C too.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/06/2026 01:28, Lynn McGuire wrote:

On 6/5/2026 3:58 AM, David Brown wrote:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?ÿ They are not suitable for
everything, but can be a good alternative to passing a pointer (or
reference) to an output parameter.

Otherwise first consider if the parameter could be null.ÿ If that is
possible, you need to use a pointer.

Then consider the clarity of the caller code.ÿ Passing by reference
looks a lot like passing by value.ÿ Indeed, if the function is not
modifying the parameter, prefer to pass by const reference if it is
too big (or otherwise expensive to copy) to pass conveniently by value.

If the function is called as "x = modify_this_thing(ys);", a reference
could be fine.ÿ If it is called as "x = make_a_thing(ys);", then it
looks like the parameter is being used by value - making the parameter
a pointer so that the caller must use "&ys" makes it clearer that it
might be modified.

I don't think there is a single "right" answer here - think primarily
about how easy it would be for people to misunderstand what the code
does.

Yes, passing function parameters by reference is subtle.ÿ And that is
what I worry about.

It's an issue worth considering carefully. I don't think anyone can
give you a clear answer, because it depends too much on the code and the developers working on it.

I have been trying it in a few places to see if I like it.ÿ Such as:
ÿÿ int uniout5 (doublereal val [], const longint n, doublereal *sum, std::string & names, const longint key, const longint ksp);

That "doublereal * sum" parameter looks like a good candidate for
change. Big in/out parameters, and sometimes big out parameters, can
often be best handled by references or pointers. But you should
consider the "take a pointer for the real return value and return a
status int" idiom as an anti-pattern. Return either a std::pair,
std::tuple, or a struct, or consider std::expected or even exceptions if
the "int" return is a error status, and put the "sum" bit in the return.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/06/2026 15:28, ??Jacek Marcin Jaworski?? wrote:

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever!

I'm pretty confident that I have had more stupid ideas on occasion.

In math valid function has the only one
value for each valid arg (even for very big and for very small numbers).

Did you do any maths beyond primary school? Vectors provide a
convenient way to hold multiple values together, and functions can map
to vectors - that corresponds very closely to C or C++ functions
returning a struct. (Mathematical functions can have any "type" for
their "return" - including other functions.)

And as has been pointed out already, C++ functions are not directly
equivalent to maths functions, unless they are "pure" functions (such as
an [[unsequenced]] function in C23).

C lang authors follow this great design! Please do not break the root C
lang rules!

C++ is not C.

And even in C, struct returns are allowed - composing multiple
sub-values into one value.



--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/5/2026 2:04 PM, Chris M. Thomasson wrote:

On 6/5/2026 1:58 AM, David Brown wrote:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?ÿ They are not suitable for
everything, but can be a good alternative to passing a pointer (or
reference) to an output parameter.

Yeah. Fwiw, I was pondering on that for a function of mine for my field based DLA algo:
________________
ÿÿÿ ct::vector_field::vector_point const*
ÿÿÿ hit_test(
ÿÿÿÿÿÿÿ glm::vec2 const& p0,
ÿÿÿÿÿÿÿ float hit_eps
ÿÿÿ ) {
ÿÿÿÿÿÿÿ for (auto const& f0 : m_field.m_point_vec)
ÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿ glm::vec2 pdif = p0 - f0.m_origin;
ÿÿÿÿÿÿÿÿÿÿÿ float pdis = glm::length(pdif);

ÿÿÿÿÿÿÿÿÿÿÿ if (pdis < hit_eps)
ÿÿÿÿÿÿÿÿÿÿÿ {
ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ return &f0;
ÿÿÿÿÿÿÿÿÿÿÿ }
ÿÿÿÿÿÿÿ }

ÿÿÿÿÿÿÿ return nullptr;
ÿÿÿ }
________________

It returns a pointer to the field vector. So, its rather dangerous, but
I know how to use it fine. The point is that I am using a pointer to
gain the data _and_ show success and failure.

Fwiw, here is why its very dangerous! Check out my walk function.

________________
// might as well be a custom line integrator
// for my existing field... Ponder...
void
walk(
ct::plot::cairo::plot_2d& scene,
glm::vec2 const& p0,
float walk_eps,
float hit_eps,
unsigned long n
) {
ct::vector_field::vector_calc vcalc = { };
ct::vector_field::settings::calc vcalc_iset = { 2.f };
//ct::vector_field::settings::calc vcalc_iset = { 1.f };

glm::vec2 pcur = p0;

for (unsigned long i = 0; i < n; ++i)
{
glm::vec2 g0 = vcalc.calc(m_field, vcalc_iset, pcur, { });

if (glm::isnan(g0.x))
{
return;
}

float pangle0 = glm::atan(g0.y, g0.x);
float pangle1 = pangle0 + 0; // curve?

glm::vec2 p0 = { glm::cos(pangle1), glm::sin(pangle1) };
glm::vec2 pnext = pcur + p0 * walk_eps;

// test for a hit...
{
ct::vector_field::vector_point const* phit =
hit_test(pnext, hit_eps);

// render path
{
scene.line(pcur, pnext, CT_RGBF(1, 0, 0), 2);
}

// Did we hit?
if (phit)
{
std::cout << "HIT at " << pcur << "\n";

scene.circle_filled(pcur, .01, CT_RGBF(0, 0, 1));
scene.line(pcur, phit->m_origin, CT_RGBF(0, 1, 0), 2);

// Place landmine... ;^D
m_field.m_point_vec.push_back({ pcur, 1, { 1, 0, 0, 0} });

// Well now... phit is FOOBAR! Never Use! :^)

return;
}
}

pcur = pnext;
}
}
________________

[...]

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/6/2026 7:49 AM, boltar@caprica.universe wrote:

On Sat, 6 Jun 2026 15:28:01 +0200 =?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?= gabbled:

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever! In math valid function has the only one
value for each valid arg (even for very big and for very small
numbers). C lang authors follow this great design! Please do not break
the root C lang rules!

A C function is not a mathematical function. Anyway , C++ still only ever returns a single object from a function but recent syntax updates allows it to seem as if multiple items are being returned.

Well, what about a function returning a single object with multiple ways
to examine the return state of the function?

struct foo
{
int m_bar;
int m_baz;
double m_wizzbar;
};

Objecting to multiple return values because "math functions only have
one value" completely misses how actual computer hardware implements activation records and calling conventions. It's all just data layout?

eg: auto [a,b,c] = func();

Sugar?

If you have a problem with that bear in mind you've already been able to return a structure in C too.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/6/2026 12:21 PM, David Brown wrote:

On 06/06/2026 15:28, ??Jacek Marcin Jaworski?? wrote:

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever!

I'm pretty confident that I have had more stupid ideas on occasion.

In math valid function has the only one value for each valid arg (even
for very big and for very small numbers).

Did you do any maths beyond primary school?ÿ Vectors provide a
convenient way to hold multiple values together, and functions can map
to vectors - that corresponds very closely to C or C++ functions
returning a struct.ÿ (Mathematical functions can have any "type" for
their "return" - including other functions.)

Bingo, Tango, target acquired!

And as has been pointed out already, C++ functions are not directly equivalent to maths functions, unless they are "pure" functions (such as
an [[unsequenced]] function in C23).

C lang authors follow this great design! Please do not break the root
C lang rules!

C++ is not C.

And even in C, struct returns are allowed - composing multiple sub-
values into one value.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/6/2026 4:28 PM, ??Jacek Marcin Jaworski?? wrote:

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever! In math valid function has the only one
value for each valid arg (even for very big and for very small numbers).
C lang authors follow this great design! Please do not break the root C
lang rules!

That's funny, but you missed a smiley or a </sarcasm> tag.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 06/06/2026 16:49, boltar@caprica.universe wrote:

On Sat, 6 Jun 2026 15:28:01 +0200 =?UTF-8?B?8J+HtfCfh7FKYWNlayBNYXJjaW4gSmF3b3Jza2nwn4e18J+HsQ==?= gabbled:

W dniu 5.06.2026 oÿ10:58, David Brown pisze:

On 05/06/2026 05:20, Lynn McGuire wrote:

So which do you prefer for your method parameters that you modify,
address of or reference ?

I am trying out the references and trying to decide if I like them.
They are a little more subtle than the dereference operator.

Have you considered multiple return values?

This is most stupid idea ever! In math valid function has the only one
value for each valid arg (even for very big and for very small
numbers). C lang authors follow this great design! Please do not break
the root C lang rules!

A C function is not a mathematical function. Anyway , C++ still only ever returns a single object from a function but recent syntax updates allows it to seem as if multiple items are being returned.

eg: auto [a,b,c] = func();

Exactly.

If you have a problem with that bear in mind you've already been able to return a structure in C too.

And returning class instances in C++ is not unusual either!


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 05.06.26 um 05:20 schrieb Lynn McGuire:

So which do you prefer for your method parameters that you modify,
address of or reference ?

For obligatory parameters I prefer references.

There is also a slight performance benefit in case of multiple
inheritance (e.g. interfaces): since references must not be null the
null check for upcasts and downcasts can be omitted.

We started writing our Windows user interface in the Windows 1.0 era
using plain old C.ÿ I converted it to C++ back in 2001 or so but I never used references since I just brought the C code mostly in.

Another dark chapter. Raw pointers are one of the most risky objects in
C++ code (with a few reasonable exceptions, of course). Basically they
are just an anachronism for compatibility reasons. C++ programmers that
still prefer raw pointers are behind the times.


Marcel

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sat, 6 Jun 2026 12:25:49 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:

On 6/6/2026 7:49 AM, boltar@caprica.universe wrote:

A C function is not a mathematical function. Anyway , C++ still only ever
returns a single object from a function but recent syntax updates allows it >> to seem as if multiple items are being returned.

Well, what about a function returning a single object with multiple ways
to examine the return state of the function?

What about it?

Objecting to multiple return values because "math functions only have
one value" completely misses how actual computer hardware implements >activation records and calling conventions. It's all just data layout?

Dunno, it wasn't me objecting to it.

eg: auto [a,b,c] = func();

Sugar?

Of course, but then a lot of C++ is just sugared C, some of it useful, some
of it not to much.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/7/2026 7:42 AM, boltar@caprica.universe wrote:

On Sat, 6 Jun 2026 12:25:49 -0700
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> gabbled:

On 6/6/2026 7:49 AM, boltar@caprica.universe wrote:

A C function is not a mathematical function. Anyway , C++ still only
ever
returns a single object from a function but recent syntax updates
allows it
to seem as if multiple items are being returned.

Well, what about a function returning a single object with multiple
ways to examine the return state of the function?

What about it?

Objecting to multiple return values because "math functions only have
one value" completely misses how actual computer hardware implements
activation records and calling conventions. It's all just data layout?

Dunno, it wasn't me objecting to it.

Oh sorry.

eg: auto [a,b,c] = func();

Sugar?

Of course, but then a lot of C++ is just sugared C, some of it useful, some of it not to much.

Well, kind of... Use only what you need. :^)

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/7/2026 9:30 AM, Marcel Mueller wrote:

Am 05.06.26 um 05:20 schrieb Lynn McGuire:

So which do you prefer for your method parameters that you modify,
address of or reference ?

For obligatory parameters I prefer references.

There is also a slight performance benefit in case of multiple
inheritance (e.g. interfaces): since references must not be null the
null check for upcasts and downcasts can be omitted.

We started writing our Windows user interface in the Windows 1.0 era
using plain old C.ÿ I converted it to C++ back in 2001 or so but I
never used references since I just brought the C code mostly in.

Another dark chapter. Raw pointers are one of the most risky objects in
C++ code (with a few reasonable exceptions, of course). Basically they
are just an anachronism for compatibility reasons. C++ programmers that still prefer raw pointers are behind the times.

Marcel

Raw pointers are good for speed, speed, speed.

Lynn


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 07.06.2026 um 16:30 schrieb Marcel Mueller:

There is also a slight performance benefit in case of multiple
inheritance (e.g. interfaces): since references must not be null
the null check for upcasts and downcasts can be omitted.

That's only necessary with multiple *and* virtual inheritance.

Another dark chapter. Raw pointers are one of the most risky objects in
C++ code (with a few reasonable exceptions, of course). Basically they
are just an anachronism for compatibility reasons. C++ programmers that still prefer raw pointers are behind the times.

I also use iterators by 95%, but sometimes pointers pointers
are inevitable.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Am 09.06.2026 um 08:08 schrieb Lynn McGuire:

Raw pointers are good for speed, speed, speed.

Iterators have the same performance.


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/9/2026 1:56 AM, Bonita Montero wrote:

Am 09.06.2026 um 08:08 schrieb Lynn McGuire:

Raw pointers are good for speed, speed, speed.

Iterators have the same performance.

I am talking about pointers going across function calls.

Lynn


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Lynn McGuire <lynnmcguire5@gmail.com> writes:

On 6/9/2026 1:56 AM, Bonita Montero wrote:

Am 09.06.2026 um 08:08 schrieb Lynn McGuire:

Raw pointers are good for speed, speed, speed.

Iterators have the same performance.

I am talking about pointers going across function calls.

How are pointers faster than references? In most cases, they're
likely to result in the same or very similar generated code.

I'm sure that's not always the case. Do you have examples?

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/9/2026 4:05 PM, Lynn McGuire wrote:

On 6/9/2026 1:56 AM, Bonita Montero wrote:

Am 09.06.2026 um 08:08 schrieb Lynn McGuire:

Raw pointers are good for speed, speed, speed.

Iterators have the same performance.

I am talking about pointers going across function calls.

References should be rather identical to pointers. But, you are going to
have to alter your existing code? That might be a royal PITA...

void foo(bar const& p)
{

}

vs:

void foo(bar const* const p)
{

}

Should be the same wrt the underlying code the compiler spits out...

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/9/2026 6:42 PM, Keith Thompson wrote:

Lynn McGuire <lynnmcguire5@gmail.com> writes:

On 6/9/2026 1:56 AM, Bonita Montero wrote:

Am 09.06.2026 um 08:08 schrieb Lynn McGuire:

Raw pointers are good for speed, speed, speed.

Iterators have the same performance.

I am talking about pointers going across function calls.

How are pointers faster than references? In most cases, they're
likely to result in the same or very similar generated code.

I'm sure that's not always the case. Do you have examples?

Bonita was talking about iterators. I was talking about pointers versus references. I was trying to clarify things.

Thanks,
Lynn


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 10/06/2026 02:37, Lynn McGuire wrote:

On 6/9/2026 6:42 PM, Keith Thompson wrote:

Lynn McGuire <lynnmcguire5@gmail.com> writes:

On 6/9/2026 1:56 AM, Bonita Montero wrote:

Am 09.06.2026 um 08:08 schrieb Lynn McGuire:

Raw pointers are good for speed, speed, speed.

Iterators have the same performance.

I am talking about pointers going across function calls.

How are pointers faster than references?ÿ In most cases, they're
likely to result in the same or very similar generated code.

I'm sure that's not always the case.ÿ Do you have examples?

Bonita was talking about iterators.ÿ I was talking about pointers versus references.ÿ I was trying to clarify things.

To repeat Keith's points - references in C++ are, under the hood,
pointers. There are semantic and syntactic differences, and pros and
cons of both solutions (such as whether null pointers are allowed or
not). But for the generated code, there is no difference. The
generated code for "void foo1(int * p) { *p = ... }" and the same
function as "void foo2(int &x) { x = ... }" will be identical.



Iterators can have more baggage - they sometimes encode more
information. But often they too are just pointers under the hood, with
the rest of the information carried as part of their type, rather than run-time values. And when they have additional run-time information,
you would probably need to pass that along with a raw pointer anyway
(such as additional parameters for the count of data, etc.)

The C++ standard library designers, and the implementers of individual toolchain implementations, put a great deal of effort into minimising
any possible overheads in commonly used iterators precisely so that
people don't feel the need to use raw pointers "for efficiency".

If you are in doubt, measure and see. (Or where your samples are small enough, put the code in godbolt.org and look at the generated code.)


--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)