At first edition of "The C programming language" we can see
that structs could not be passed directly as function arguments.
They also could not be returned from functions and assigned.

Soon after [1], the language changed to allow assignment and make
structs arguments passed by copy by default.

Today, I have 0% of structs being passed by copy in my code.
So for me this is a very bad default.

If structs where passed by reference this would not be the only
exception on the type system because arrays are already passed
as pointers.

Do you have structs passed by copy in your code?
Could it be replaced by const * ?
Considering your answer would you agree with me that this is a bad default?

Returning function by copy is common in my code.

[1]
https://www.bell-labs.com/usr/dmr/www/cchanges.pdf

In article <76ec6d87-0f5d-4671-b4c8-7023e3da787an@googlegroups.com>,
Thiago Adams <thiago.adams@gmail.com> wrote:
>At first edition of "The C programming language" we can see
>that structs could not be passed directly as function arguments.
>They also could not be returned from functions and assigned.
>
>Soon after [1], the language changed to allow assignment and make
>structs arguments passed by copy by default.
>
>Today, I have 0% of structs being passed by copy in my code.
>So for me this is a very bad default.

Two comments:
1) I never really understood *why* they changed the language to allow
structs to be passed as actual objects. Anyone care to comment?
2) The usual method for passing structs around is to pass a pointer to
the struct. That works just fine in all cases and, thus, as above,
I don't understand why the change.

Like you, I've never needed (or used) this ability in my code, so have not
ever used it. I wonder if it came about because they made some other
changes (enhancements) in what you could legally do with a struct, and this
ended up coming for free.

P.S. I actually do kinda like the idea that you can pass an array "by
value" (should you want/need to do that) by wrapping the array inside a
struct and passing the struct. A cute hack that could prove useful some
sunny day...

--
"We should always be disposed to believe that which appears to us to be
white is really black, if the hierarchy of the church so decides."

- Saint Ignatius Loyola (1491-1556) Founder of the Jesuit Order -

On 1/20/23 13:41, Thiago Adams wrote:
> <snip/>
>
> If structs where passed by reference this would not be the only
> exception on the type system because arrays are already passed
> as pointers.
>
> <snip/>
​The only reason arrays are the exception is because arrays aren't a
first-class construct, and are just a syntactic wrapper around pointers
to contiguous storage.
--
⚗︎ | /blu.mɛin.dʰak/ | shortens to "Hawk" | he/him/his/himself/Mr.
bluemanedhawk.github.io
Apologies if this message got encoded into octoctal. Blame Thunderbird
for not behaving correctly with Unicode and PGP.

Thiago Adams <thiago.adams@gmail.com> writes:

> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
>
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
>
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
>
> If structs where passed by reference this would not be the only
> exception on the type system because arrays are already passed
> as pointers.
>
> Do you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
>
> Returning function by copy is common in my code.
>
> [1]
> https://www.bell-labs.com/usr/dmr/www/cchanges.pdf

All function arguments are passed by copy. Arrays are not an exception
to that rule because they're passed by pointer. They're an exception
because there are no arguments of array type. There is some syntactic
sugar that can make it look like arrays are being passed by reference,
but that's not what's happening.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Blue-Maned_Hawk <bluemanedhawk@gmail.com> writes:
> On 1/20/23 13:41, Thiago Adams wrote:
>> <snip/>
>> If structs where passed by reference this would not be the only
>> exception on the type system because arrays are already passed
>> as pointers.
>> <snip/>
>
> ​The only reason arrays are the exception is because arrays aren't a
> first-class construct, and are just a syntactic wrapper around
> pointers to contiguous storage.

That's incorrect.

Array objects and array types are entirely distinct from pointer objects
and pointer types.

An array *expressions* is, in most but not all contexts, implicitly
"converted" to a pointer to the array object's 0th element. And a
function parameter of array type is "adjusted" to a parameter of pointer
type. Together, these rules can make it seem like array objects are
being passed by reference, but that's not what's really happening.

I find it useful to treat the words "array" and "pointer" as adjectives,
not nounds: "array object", not just "array".

See section 6 of the comp.lang.c FAQ, <https://www.c-faq.com/>.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

Kenny McCormack:

> I never really understood *why* they changed the language
> to allow structs to be passed as actual objects. Anyone
> care to comment?

Integers, floats, and doubles can be passed by value. If I
were to implement complex numbers, I should do it as a
struct with a .re (real) and .im (imaginary) fields. I
should want to pass it by value whenever I pass real types
by value.

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 20/01/2023 18:41, Thiago Adams wrote:
> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
>
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
>
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
>
> If structs where passed by reference this would not be the only
> exception on the type system because arrays are already passed
> as pointers.

If S is a struct instance, and A is an array instance, then here:

S; // is the struct itself; not a reference;
A; // is a pointer to A[0]; not the array itself

So the default is already part of the language, and exists in nearly
every place where you use S and A within an expression.

Including expressions like f(S) and S=g().

So to me it makes sense.

Bear in mind that on modern ABIs, most structs tend to be passed by
reference behind the scenes anyway. Although it may still require some
copying to protect the caller's original data if that is at risk.

>
> Do you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
>
> Returning function by copy is common in my code.

If you use libraries like Raylib, then pretty much every struct is
passed and return by-value, or notionally by-value.

Like you I prefer by-reference, but I also prefer that that was explicit
in the language.

(My own language manipulates arrays by-value too. For some decades I had
structs and arrays passed by actual copying, but I NEVER used that
feature. That is still the case, but now behind the scenes it uses
pointers. I still use explicit pointer-to or by-reference passing modes.)

In article <20230120230138.1225d36e5ad8e5f07401c67a@gmail.com>,
Anton Shepelev <anton.txt@gmail.com> wrote:
>Kenny McCormack:
>
>> I never really understood *why* they changed the language
>> to allow structs to be passed as actual objects. Anyone
>> care to comment?
>
>Integers, floats, and doubles can be passed by value. If I
>were to implement complex numbers, I should do it as a
>struct with a .re (real) and .im (imaginary) fields. I
>should want to pass it by value whenever I pass real types
>by value.

I get that, for symmetry's sake and all, but wouldn't it be just as easy to
pass the address of your struct? Like we do with most of the structs that
get passed to Unix API calls (e.g., stat(2)).

By the way, didn't they already add complex numbers to the standard,
somewhere along the way? Having never used them, I can't remember, off
hand, how they are implemented.

--
Joni Ernst (2014): Obama should be impeached because 2 people have died of Ebola.
Joni Ernst (2020): Trump is doing great things, because only 65,000 times as many people have died of COVID-19.

Josef Stalin (1947): When one person dies, it is a tragedy; when a million die, it is merely statistics.

On Friday, January 20, 2023 at 4:02:59 PM UTC-3, Kenny McCormack wrote:
> In article <76ec6d87-0f5d-4671...@googlegroups.com>,
> Thiago Adams <thiago...@gmail.com> wrote:
> >At first edition of "The C programming language" we can see
> >that structs could not be passed directly as function arguments.
> >They also could not be returned from functions and assigned.
> >
> >Soon after [1], the language changed to allow assignment and make
> >structs arguments passed by copy by default.
> >
> >Today, I have 0% of structs being passed by copy in my code.
> >So for me this is a very bad default.
> Two comments:
> 1) I never really understood *why* they changed the language to allow
> structs to be passed as actual objects. Anyone care to comment?

I guess is to make structs work as other basic types.

But they didn't realise the common case is passing without copy.
const also was added latter, making references safer.

At 2 edition of c programming language, page 128, they added a "struct point"
sample, passing and returning point by copy.
This is a very specific cases where using copy may make sense.

This sample was not present at first edition. So it kind of justifying the feature.

At pag 168 of Byte magazine 1983 [2] has a interesting comment that some compilers
use to pass address of struct even without operator &.

[2] pag 168
https://ia800309.us.archive.org/26/items/byte-magazine-1983-08/1983_08_BYTE_08-08_The_C_Language.pdf

This shows me that this behaviour was common sense, at least for some compilers.

Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <76ec6d87-0f5d-4671-b4c8-7023e3da787an@googlegroups.com>,
> Thiago Adams <thiago.adams@gmail.com> wrote:
> >At first edition of "The C programming language" we can see
> >that structs could not be passed directly as function arguments.
> >They also could not be returned from functions and assigned.
> >
> >Soon after [1], the language changed to allow assignment and make
> >structs arguments passed by copy by default.
> >
> >Today, I have 0% of structs being passed by copy in my code.
> >So for me this is a very bad default.
>
> Two comments:
> 1) I never really understood *why* they changed the language to allow
> structs to be passed as actual objects. Anyone care to comment?

Why not? Argument passing in C is releated to assignment. Once you
allow structure assignment it is natural to allow passing of
structs. If compiler passes arguments on the stack, then
implementation is allmost for free, just generate code as for
assignment to fill stack slot. If some arguments are passed in
registers, then implementation gets more complicated. OTOH
small structures that fit into one or two registers are more
efficient to pass by value, so it makes sense to spend some
effort to pass them in registers.

> 2) The usual method for passing structs around is to pass a pointer to
> the struct. That works just fine in all cases and, thus, as above,
> I don't understand why the change.

If you pass address of the struct, than there is no change. The
rest is just making struct into "first class objects".
> Like you, I've never needed (or used) this ability in my code, so have not
> ever used it. I wonder if it came about because they made some other
> changes (enhancements) in what you could legally do with a struct, and this
> ended up coming for free.

Once you have structurs assignment passing them as arguments is only
logical thing.

Few times are used structures with one member to get stronger type
checking (free of default C rules for argument compatibility). I did
appropriate change temporarly, using macros and for this use it was
essential that structures were passed by value. Few times I used
small structures and passed them by value. It made code slightly
simpler and probably more efficient than passing address.

--
Waldek Hebisch

On 1/20/23 1:41 PM, Thiago Adams wrote:
> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
>
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
>
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
>
> If structs where passed by reference this would not be the only
> exception on the type system because arrays are already passed
> as pointers.
>
> Do you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
>
> Returning function by copy is common in my code.
>
> [1]
> https://www.bell-labs.com/usr/dmr/www/cchanges.pdf
>

My impression is that the biggest reason structs are passed by value and
not automatically by address is that pass by value is useful in some
cases, and allows "pass by address" easily with just adding a character,
while the opposite makes things complicated and inefficient.

This did not work for arrays for several reasons. First, the Array name
to pointer transformation is a fairly fundamental part of the definition
of how arrays work.

Second, I suspect enough early code depended on the ability to "pass a
character array" to a function and it fill in the answer existed that
would make changing that behavior hard. (Note, the early version didn't
convert struct variables to addresses automatically, you just needed a
add the &/* yourself.

Third, there is likely enough code that plays fast and loose with the
knowledge that an parameter declaired as an array isn't actually an
array, and the point it is passed might not point to an array of that
exact size anyway, so coming up with a good definition of how to handle
this might be hard, and will have a number of special cases that act
"surprisingly" different.

On 1/20/2023 10:41 AM, Thiago Adams wrote:
> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
>
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
>
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
>
> If structs where passed by reference this would not be the only
> exception on the type system because arrays are already passed
> as pointers.
>
> Do you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
>
> Returning function by copy is common in my code.
>
> [1]
> https://www.bell-labs.com/usr/dmr/www/cchanges.pdf
>
Sorry for any typos:

struct bar
{ int baz;
};

struct foo
{ struct bar bar[42];
};

struct foo
foobarbaz()
{ struct foo foo = { { 0 } };
foo.bar[0] = 4;
foo.bar[1] = 2;
return foo;
}

Nice! Wrapping up an array in a struct is fine with me... :^)

On Friday, January 20, 2023 at 5:16:58 PM UTC-3, Bart wrote:
> On 20/01/2023 18:41, Thiago Adams wrote:
> > At first edition of "The C programming language" we can see
> > that structs could not be passed directly as function arguments.
> > They also could not be returned from functions and assigned.
> >
> > Soon after [1], the language changed to allow assignment and make
> > structs arguments passed by copy by default.
> >
> > Today, I have 0% of structs being passed by copy in my code.
> > So for me this is a very bad default.
> >
> > If structs where passed by reference this would not be the only
> > exception on the type system because arrays are already passed
> > as pointers.
> If S is a struct instance, and A is an array instance, then here:
>
> S; // is the struct itself; not a reference;
> A; // is a pointer to A[0]; not the array itself

If you use sizeof of an array (not function argument) then
you get the correct size.

int a[2];
sizeof(a); // will not give the sizeof a[0]

So, in some cases it is not equivalent of first element.

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, January 20, 2023 at 5:16:58 PM UTC-3, Bart wrote:
>> On 20/01/2023 18:41, Thiago Adams wrote:
>> > At first edition of "The C programming language" we can see
>> > that structs could not be passed directly as function arguments.
>> > They also could not be returned from functions and assigned.
>> >
>> > Soon after [1], the language changed to allow assignment and make
>> > structs arguments passed by copy by default.
>> >
>> > Today, I have 0% of structs being passed by copy in my code.
>> > So for me this is a very bad default.
>> >
>> > If structs where passed by reference this would not be the only
>> > exception on the type system because arrays are already passed
>> > as pointers.
>> If S is a struct instance, and A is an array instance, then here:
>>
>> S; // is the struct itself; not a reference;
>> A; // is a pointer to A[0]; not the array itself
>
> If you use sizeof of an array (not function argument) then
> you get the correct size.

Of course.

> int a[2];
> sizeof(a); // will not give the sizeof a[0]
>
> So, in some cases it is not equivalent of first element.

It's never equivalent to the first element. It's sometimes equivalent
to the *address* of the first element.

But he specifically referred to `A;`, an expression statement where the
expression is the name of an array object. In that context, the
expression decays to a pointer to A[0] (and the value is discarded).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On 2023-01-20, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> I get that, for symmetry's sake and all, but wouldn't it be just as easy to
> pass the address of your struct? Like we do with most of the structs that
> get passed to Unix API calls (e.g., stat(2)).

In fact, passing a structure by value can be implemented by a hidden
pointer. Compilers do that at their discretion; it may be based on how
large the structure is and other factors.

The important thing is the semantics. In C, you can modify an argument
without affecting the caller; the understanding is that the object is
a local copy.

One big reason for passing a structure by value is that you want to
be able to mutate the copy, and to do that conveniently without
a dance like this:

void fun(struct obj *ptr)
{
struct obj local = *ptr;
// work with local
local.counter++;
// ...
}

It just just becomes

void fun(struct obj local)
{
local.counter++;
// ...
}

Even if you don't need the copy, there is less syntax. No pointer
declarator in the parameter, and just dot referencing instead of ->.

Moreover, you don't have to use the & operator to prepare the
argument;

void fun(struct obj local)
{
do_this(local.foo, local.bar);
}

//

struct obj x;
//
fun(x);

versus

void fun(struct obj *local) // noise here
{
do_this(local->foo, local->bar); // more noise here
}

//

struct obj x;
//
fun(&x); // noise here

There is more freedom to generate code for the by-value situation in
different ways. The pointer version basically specifies what the
implementation is, whereas the by-value version could use a pointer,
whereby callee copies the struct if necessary, or have the caller make
the copy, passing a pointer to the callee, or have the caller make an
actual stack copy that the callee finds at a fixed offset in the
parameter space. One strategy could be used for large structures,
another for small structures.

Thus, when you write the noise-free, clean version with by-value
passing, it can easily have the same efficiency as the explicit pointer
version, with as little actual data copying.

For small structures, you could actually be making the program less
efficient by passing a pointer. If you have a complex number
represented as a structure holding two doubles, when that is passed
by value, it could acctually be passed using the same mechanism
as if it were two arguments of type double. E.g. two registers.

And when the callee accesses "arg.real" and "arg.imag", that could
actually be compiled to just referring to those registers.

Whereas code that does arg->real might not have that pointer
optimized away at all.

Another consideration is that the recipent of a by-value struct
argument (no matter how the passage is implemented) has the
guarantee that it's a local. If the callee doesn't lift the
address of that local with the & operator, then it is guaranteed
that nothing else in the program has the address of the object;
and thus no function which it uses needs to be suspected of
modifying the object.

Pointer version:

void fun(const struct complex_number *pcplx)
{
double dr = other_fun_1(pcplx->real);
double di = other_fun_2(pcplx->real + pcplx->imag);
}

Here although the structure is marked "const", we have no idea
where the pointer came form and who else has that pointer.
When the other_fun_1 is called, and is an external function about which
we know nothing, it has to be assumed that it has access to that object
and can modify it. Thus the second evaluation of pcplx->real has to
re-load that member through the pointer. It cannot just re-use thue
previously loaded pcplx->real value.

There is no such threat under by-value:

void fun(const struct complex_number cplx)
{
double dr = other_fun_1(cplx.real);
double di = other_fun_2(cplx.real + cplx.imag);
}

The call to other_fun_1 cannot possibly change the value of
cplx.real; the compiler can put that into a register,
which doesn't have to be spilled and reloaded across
calls to external functions.

The pointer version could be optimized similarly if we
could convince the compiler that the object cannot
be modified. E.g. the members themselves could
be const-qualified types:

struct complex_number { const double real, imag; };

That's going to create hassles.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 1/20/23 15:01, Anton Shepelev wrote:
> Kenny McCormack:
>
>> I never really understood *why* they changed the language
>> to allow structs to be passed as actual objects. Anyone
>> care to comment?
>
> Integers, floats, and doubles can be passed by value. If I
> were to implement complex numbers, I should do it as a
> struct with a .re (real) and .im (imaginary) fields. I
> should want to pass it by value whenever I pass real types
> by value.

Note that this argument can be applied to any struct which can be seen
as implementing a type that is, in some way, an extension of the scalar
types, because the scalar types are also passed by value. I could, and
have, had reason to use this approach for things like quaternions,
vectors or tensors with a small fixed dimensions (<= 4), and smart
pointers. It's much easier to do such things in C++, where I can create
corresponding operator overloads.

On 21/01/2023 03:16, Thiago Adams wrote:
> On Friday, January 20, 2023 at 5:16:58 PM UTC-3, Bart wrote:
>> On 20/01/2023 18:41, Thiago Adams wrote:
>>> At first edition of "The C programming language" we can see
>>> that structs could not be passed directly as function arguments.
>>> They also could not be returned from functions and assigned.
>>>
>>> Soon after [1], the language changed to allow assignment and make
>>> structs arguments passed by copy by default.
>>>
>>> Today, I have 0% of structs being passed by copy in my code.
>>> So for me this is a very bad default.
>>>
>>> If structs where passed by reference this would not be the only
>>> exception on the type system because arrays are already passed
>>> as pointers.
>> If S is a struct instance, and A is an array instance, then here:
>>
>> S; // is the struct itself; not a reference;
>> A; // is a pointer to A[0]; not the array itself
>
> If you use sizeof of an array (not function argument) then
> you get the correct size.
>
> int a[2];
> sizeof(a); // will not give the sizeof a[0]
>
> So, in some cases it is not equivalent of first element.

You snipped this bit:

>> So the default is already part of the language, and exists in nearly
>> every place where you use S and A within an expression.

On 20/01/2023 19:41, Thiago Adams wrote:

> Do you have structs passed by copy in your code?
> Could it be replaced by const * ?
> Considering your answer would you agree with me that this is a bad default?
>
> Returning function by copy is common in my code.
>

In C, struct (and union) is the only way to make a new type. So if you
have a gui library with handles that are implemented as ints, you can write:

typedef struct { int contents; } handle;

Then you can assign, pass around and return instances of type "handle"
as conveniently and efficiently as an "int", but in a typesafe manner -
the compiler won't let you mix it up with an "int", or mismatch pointers
to handle with pointers to int.

If you have a fixed size buffer, you can have :

typedef struct { char data[bufSize]; } buffer;

and pass that around. sizeof works "correctly", and the ABI and
compiler conspire to make it all efficient using hidden pointers.

I wouldn't use pointers here unless I actually wanted pointers - passing
or returning structs by values is fine.

gazelle@shell.xmission.com (Kenny McCormack) writes:
>
> By the way, didn't they already add complex numbers to the standard,
> somewhere along the way? Having never used them, I can't remember, off
> hand, how they are implemented.

Yes, though that doesn't really affect the example.

I first learned about complex numbers in C when I typoed something like
5i when I meant 5+i and was very, very confused for a while.

In article <1btu0jojlm.fsf@pfeifferfamily.net>,
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:
>gazelle@shell.xmission.com (Kenny McCormack) writes:
>>
>> By the way, didn't they already add complex numbers to the standard,
>> somewhere along the way? Having never used them, I can't remember, off
>> hand, how they are implemented.
>
>Yes, though that doesn't really affect the example.

Agreed.

>I first learned about complex numbers in C when I typoed something like
>5i when I meant 5+i and was very, very confused for a while.

Interesting.

--
I'll give him credit for one thing: He is (& will be) the most quotable President
ever. Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

Tremendously wet - from the standpoint of water.

Le 20/01/2023 à 19:41, Thiago Adams a écrit :
> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.

Yes, that was a very long time ago. I personally don't remember having
ever been exposed to a C compiler that didn't support it.

> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.

Indeed.

> Do you have structs passed by copy in your code?

Yes, sometimes. As with any other programming topic, the key is just to
use your brain. Usually better than cargo cult programming.

- Passing and returning structs by value gets you some kind of
"functional" style.
- Avoids any pointer error.
- Should usually be avoided if the structure is too large. Common sense.
For two reasons: first it has to be copied (takes some time), and second
it will eat up space in the stack (may or may not be an issue depending
on your context.)
- Is thus inefficient if the struct is large, especially if you are only
going to access one or just a few members. In this case, it's obvious
that accessing it by reference (through a pointer) makes more sense.
- But if the struct is reasonably small, it can be not just elegant, but
very efficient. Most ABIs these days pass arguments in registers up to a
certain size/number of arguments. If say you define a 'complex' type
struct (two 'double'), then passing them by value rather than reference
works great and is less tedious than using pointers.
- Returning structs can be useful to combine, for instance, a returned
error code and a returned value.

If you want to get an impression of how that all compiles on various
targets and make comparisons, I suggest https://godbolt.org/ which is
very handy.

James Kuyper to Anton Shepelev:

> > Integers, floats, and doubles can be passed by value.
> > If I were to implement complex numbers, I should do it
> > as a struct with a .re (real) and .im (imaginary)
> > fields. I should want to pass it by value whenever I
> > pass real types by value.
>
> Note that this argument can be applied to any struct which
> can be seen as implementing a type that is, in some way,
> an extension of the scalar types, because the scalar types
> are also passed by value. I could, and have, had reason to
> use this approach for things like quaternions, vectors or
> tensors with a small fixed dimensions (<= 4), and smart
> pointers. It's much easier to do such things in C++, where
> I can create corresponding operator overloads.

Indeed. My specific example demostrates a general deficiency
of C and other similar languages: implementing one's own
"scalar-like" types is impossibe or cumbersome, whereas
those types are often very useful. All right, modern C has
built-in complex type, but that only shows that it cannot
be implemented by the programmer *in* C!

--
() ascii ribbon campaign -- against html e-mail
/\ www.asciiribbon.org -- against proprietary attachments

On 1/21/23 3:00 PM, Anton Shepelev wrote:
> James Kuyper to Anton Shepelev:
>
>>> Integers, floats, and doubles can be passed by value.
>>> If I were to implement complex numbers, I should do it
>>> as a struct with a .re (real) and .im (imaginary)
>>> fields. I should want to pass it by value whenever I
>>> pass real types by value.
>>
>> Note that this argument can be applied to any struct which
>> can be seen as implementing a type that is, in some way,
>> an extension of the scalar types, because the scalar types
>> are also passed by value. I could, and have, had reason to
>> use this approach for things like quaternions, vectors or
>> tensors with a small fixed dimensions (<= 4), and smart
>> pointers. It's much easier to do such things in C++, where
>> I can create corresponding operator overloads.
>
> Indeed. My specific example demostrates a general deficiency
> of C and other similar languages: implementing one's own
> "scalar-like" types is impossibe or cumbersome, whereas
> those types are often very useful. All right, modern C has
> built-in complex type, but that only shows that it cannot
> be implemented by the programmer *in* C!
>

No, they CAN be implemented, they just don't completely work like the
built in types because the operators don't work on them.

Yes, to make a completely "act like a native" type, you need to be able
to overload the operators, and then you need to be able to define
'conversion' functions to convert one type to another, and so on and you
get to the beginnings of something like C++.

Once you let that "Nosse of the Camel" in, you tend to get a lot of the
base language of C++ following.

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
[...]
> I first learned about complex numbers in C when I typoed something like
> 5i when I meant 5+i and was very, very confused for a while.

5i is an imaginary constant, a gcc-specific extension. It's a syntax
error in standard C.

gcc imaginary constants are of complex type. The standard defines
optional support for imaginary types in Annex G, but I don't know
of any compiler that supports them (or how they'd be useful).

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

On Friday, January 20, 2023 at 8:41:16 PM UTC+2, Thiago Adams wrote:
> At first edition of "The C programming language" we can see
> that structs could not be passed directly as function arguments.
> They also could not be returned from functions and assigned.
>
> Soon after [1], the language changed to allow assignment and make
> structs arguments passed by copy by default.
>
> Today, I have 0% of structs being passed by copy in my code.
> So for me this is a very bad default.
>
> If structs where passed by reference this would not be the only
> exception on the type system because arrays are already passed
> as pointers.
>
> Do you have structs passed by copy in your code?

Yes, I do.

> Could it be replaced by const * ?

Not 100%

> Considering your answer would you agree with me that this is a bad default?

No, it is the only sane option.
The early C that didn't have it was inconsistent.
And I don't understand why do you call it "default'.

>
> Returning function by copy is common in my code.
>

Then I even less understand your objection to passing by value.

> [1]
> https://www.bell-labs.com/usr/dmr/www/cchanges.pdf