Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #168839 > unrolled thread

structs passed by copy

Back to article view | Back to comp.lang.c

Contents

  structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 10:41 -0800
    Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-20 19:01 +0000
      Re: structs passed by copy Anton Shepelev <anton.txt@gmail.com> - 2023-01-20 23:01 +0300
        Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-20 21:28 +0000
          Re: structs passed by copy Kaz Kylheku <864-117-4973@kylheku.com> - 2023-01-21 09:14 +0000
          Re: structs passed by copy Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2023-01-21 10:58 -0700
            Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-01-21 18:00 +0000
            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-21 16:14 -0800
              Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 16:00 -0500
                Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:07 -0800
                Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 13:27 -0800
                  Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:51 -0800
                    Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:51 -0800
                  Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-22 17:11 -0500
                    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-22 16:01 -0800
                      Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-22 21:22 -0500
                      Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 10:46 +0100
                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 12:15 -0800
                          Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 21:47 +0100
                            Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-23 13:21 -0800
                              Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-23 23:49 +0000
                                Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-24 02:46 -0800
                                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:18 -0800
                                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:45 -0800
                                      Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 04:54 -0800
                                        Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:26 -0800
                                          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:38 -0800
                                            Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 05:53 -0800
                                              Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 06:20 -0800
                                                Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 06:56 -0800
                                                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-24 07:17 -0800
                                  Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-24 12:56 +0000
                                    Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-24 07:29 -0800
                      Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-23 15:44 -0800
                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 16:37 -0800
                          Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-23 20:13 -0500
                            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-23 17:58 -0800
                          Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-24 07:53 -0800
                            Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-24 11:14 -0800
                              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-24 12:02 -0800
                                Re: structs passed by copy Phil Carmody <pc+usenet@asdf.org> - 2023-01-25 10:18 +0200
                                  Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-25 10:53 -0800
                                    Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-01-29 13:30 -0800
                                      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 17:42 -0800
                                        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-17 07:19 -0800
                                          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 09:35 -0800
                                      Re: structs passed by copy John Forkosh <forkosh@panix.com> - 2023-01-30 04:24 +0000
                                        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-29 21:10 -0800
                                        Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-30 13:55 -0800
                                        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-17 05:57 -0800
        Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-01-21 05:00 -0500
          Re: structs passed by copy Anton Shepelev <anton.txt@gmail.com> - 2023-01-21 23:00 +0300
            Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-21 17:10 -0500
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 18:12 -0800
      Re: structs passed by copy antispam@math.uni.wroc.pl - 2023-01-21 02:28 +0000
    Re: structs passed by copy Blue-Maned_Hawk <bluemanedhawk@gmail.com> - 2023-01-20 14:09 -0500
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 11:26 -0800
    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 11:22 -0800
    Re: structs passed by copy Bart <bc@freeuk.com> - 2023-01-20 20:16 +0000
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-20 19:16 -0800
        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-01-20 21:08 -0800
        Re: structs passed by copy Bart <bc@freeuk.com> - 2023-01-21 13:30 +0000
          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 10:27 -0800
    Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-01-20 21:35 -0500
    Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-20 19:01 -0800
      Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-21 17:01 -0800
    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-21 14:59 +0100
    Re: structs passed by copy Opus <ifonly@youknew.org> - 2023-01-21 19:59 +0100
    Re: structs passed by copy Michael S <already5chosen@yahoo.com> - 2023-01-21 16:55 -0800
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 02:32 -0800
        Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 15:54 +0000
          Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 09:17 -0800
            Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 09:56 -0800
              Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 10:19 -0800
                Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:01 -0800
                  Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:08 -0800
                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 11:17 -0800
                    Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-01-22 13:27 -0800
          Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 13:04 -0800
            Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 21:43 +0000
              Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 14:10 -0800
                Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-22 22:29 +0000
                  Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-01-22 14:39 -0800
                  Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 19:06 -0800
                    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-01-23 10:54 +0100
          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-01-22 19:00 -0800
            Re: structs passed by copy Ben Bacarisse <ben.usenet@bsb.me.uk> - 2023-01-23 12:14 +0000
    Re: structs passed by copy Jorgen Grahn <grahn+nntp@snipabacken.se> - 2023-02-11 19:35 +0000
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-11 15:08 -0800
        Re: structs passed by copy Öö Tiib <ootiib@hot.ee> - 2023-02-11 15:56 -0800
          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-11 16:32 -0800
            Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-12 01:23 -0500
              Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-12 11:24 +0100
                Re: structs passed by copy Vir Campestris <vir.campestris@invalid.invalid> - 2023-02-12 22:11 +0000
                  Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 10:25 +0100
                    Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 06:41 -0800
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 06:50 -0800
                        Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 17:22 +0100
                          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-13 10:47 -0800
                            Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-13 21:50 +0100
                              Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-02-15 17:14 -0800
                                Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-16 10:53 +0100
                                  Re: structs passed by copy scott@slp53.sl.home (Scott Lurndal) - 2023-02-16 15:22 +0000
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-12 11:04 -0800
            Re: structs passed by copy Öö Tiib <ootiib@hot.ee> - 2023-02-12 12:41 -0800
            Re: structs passed by copy Andrey Tarasevich <andreytarasevich@hotmail.com> - 2023-02-16 22:49 -0800
        Re: structs passed by copy "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2023-02-11 17:49 -0800
        Grammar nitpick (Was: structs passed by copy) gazelle@shell.xmission.com (Kenny McCormack) - 2023-02-12 06:30 +0000
        Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 09:32 -0800
          Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-06 09:58 -0800
            Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 11:30 -0800
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-06 12:59 -0800
      Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-15 01:52 -0800
        Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-16 05:20 -0800
          Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-02-16 16:49 +0100
          Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-02-26 08:12 -0800
            Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-02-28 05:38 -0800
              Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-28 14:18 -0800
                Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-01 05:02 -0800
                  Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:23 -0800
                    Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-03-01 10:42 -0800
                    Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-03-01 15:13 -0800
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 04:17 -0800
                      Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-03-05 04:17 -0800
                        Re: structs passed by copy fir <profesor.fir@gmail.com> - 2023-03-05 04:55 -0800
                    Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-03-02 10:48 +0100
                      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 04:07 -0800
                        Re: structs passed by copy David Brown <david.brown@hesbynett.no> - 2023-03-02 15:08 +0100
                          Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-02 09:22 -0800
                Re: structs passed by copy gazelle@shell.xmission.com (Kenny McCormack) - 2023-03-01 13:34 +0000
                  Re: structs passed by copy Richard Damon <Richard@Damon-Family.org> - 2023-03-01 21:42 -0500
              Re: structs passed by copy Tim Rentsch <tr.17687@z991.linuxsc.com> - 2023-03-06 09:36 -0800
    Re: structs passed by copy Maciej Zelma <maciej.projectmanager@gmail.com> - 2023-02-17 14:10 -0800
      Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 15:45 -0800
        Re: structs passed by copy scott@slp53.sl.home (Scott Lurndal) - 2023-02-18 00:12 +0000
          Re: structs passed by copy bart c <bart4858@gmail.com> - 2023-02-18 02:33 -0800
      Re: structs passed by copy James Kuyper <jameskuyper@alumni.caltech.edu> - 2023-02-18 00:44 -0500
        Re: structs passed by copy Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2023-02-17 22:21 -0800
    Re: structs passed by copy Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-01 18:00 +0100
      Re: structs passed by copy Thiago Adams <thiago.adams@gmail.com> - 2023-03-01 09:18 -0800
        Re: structs passed by copy Bonita Montero <Bonita.Montero@gmail.com> - 2023-03-05 14:05 +0100

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

#168852

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 */

[toc] | [prev] | [next] | [standalone]

#168855

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.

[toc] | [prev] | [next] | [standalone]

#168870

sobota, 21 stycznia 2023 o 14:31:09 UTC+1 Bart napisał(a):
> 

btw why you so rare active user bart? this group looses on your inactivity a lot

i once criticized your activity becouse you were able repeat nearly the same content 200 times or so and this was exagerration imo ...but the oppose extremum not to post at all is even worse.. the good is to keep things in the middle...

[toc] | [prev] | [next] | [standalone]

#168849

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.

[toc] | [prev] | [next] | [standalone]

#168850

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... :^)

[toc] | [prev] | [next] | [standalone]

#168864

On 1/20/2023 7:01 PM, Chris M. Thomasson wrote:
> 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;

God damn it!

      foo.bar[0].baz = 4;
      foo.bar[1].baz = 2;

Right? Damn it!

>     return foo;
> }
> 
> 
> Nice! Wrapping up an array in a struct is fine with me... :^)

[toc] | [prev] | [next] | [standalone]

#168856

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.

[toc] | [prev] | [next] | [standalone]

#168859

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.

[toc] | [prev] | [next] | [standalone]

#168863

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

[toc] | [prev] | [next] | [standalone]

#168865

On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote:
> 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'.

I guess the other option was to make structs arguments passed by
reference. The same for arrays.

void f(struct X x, int a[2]) {
 // sizeof(x) and sizeof(a)  would not be sizeof pointer
}

no need for -> everywhere inside structs.

To imagine how it would work, a c++ compiler can be used.

struct X{int i;};

void f(struct X& x, int (&a)[2]) {
  static_assert(sizeof(x) == sizeof(struct X));
  static_assert(sizeof(a) == sizeof(int)*2);
}

Then imagine the same code but without & ref. Because this would be 
the default for structs and arrays.

If wee need a copy

void f(struct X x0, int a[2]) {
  struct X x = x0;
}

I don t think passing by copy is a problem, it is just
something I dont need frequently. 

On the other hand I pass 99.9% of time structs by pointer. 

[toc] | [prev] | [next] | [standalone]

#168866

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

> On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote:
>> 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'.
>
> I guess the other option was to make structs arguments passed by
> reference. The same for arrays.

(I'd say "and the same for arrays".  As it stands, it could sound like
you think arrays are currently "passed by reference".  I know you don;t
think that, but it's a common enough misconception that you'd want to
avoid any hint of it.)

> void f(struct X x, int a[2]) {
>  // sizeof(x) and sizeof(a)  would not be sizeof pointer
> }
>
> no need for -> everywhere inside structs.

And now you have a different anomaly in the language.  Everything except
structs and arrays are passed by reference.  And, what's more, the
caller can't tell if a function can change the passed object because the
pass by reference is invisible at the call site.  If I have a type T x
object, is x passed by value or reference in the call f(x)?

What is the problem with C that you are trying to solve?  I can't see
the issue.

If it is just avoiding writing -> vs ., it's well know that C could just
use . everywhere since the compiler always know when the LHS is a
pointer to a struct.  There would be no ambiguity, so that change would
be very low cost.  (I'm not sure it's a good idea, but that's a separate
issue.)

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168867

niedziela, 22 stycznia 2023 o 16:54:28 UTC+1 Ben Bacarisse napisał(a):
> Thiago Adams <thiago...@gmail.com> writes: 
> 
> > On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote: 
> >> 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'. 
> > 
> > I guess the other option was to make structs arguments passed by 
> > reference. The same for arrays.
> (I'd say "and the same for arrays". As it stands, it could sound like 
> you think arrays are currently "passed by reference". I know you don;t 
> think that, but it's a common enough misconception that you'd want to 
> avoid any hint of it.)
> > void f(struct X x, int a[2]) { 
> > // sizeof(x) and sizeof(a) would not be sizeof pointer 
> > } 
> > 
> > no need for -> everywhere inside structs.
> And now you have a different anomaly in the language. Everything except 
> structs and arrays are passed by reference. And, what's more, the 
> caller can't tell if a function can change the passed object because the 
> pass by reference is invisible at the call site. If I have a type T x 
> object, is x passed by value or reference in the call f(x)? 
> 
> What is the problem with C that you are trying to solve? I can't see 
> the issue. 
> 
> If it is just avoiding writing -> vs ., it's well know that C could just 
> use . everywhere since the compiler always know when the LHS is a 
> pointer to a struct. There would be no ambiguity, so that change would 
> be very low cost. (I'm not sure it's a good idea, but that's a separate 
> issue.) 
> 
it may be kinda funny but i probbaly pass structures  only by value (or nearly)

its becouse 2 facts:
1) i dont pass structures by pointers (i just dont need it, it seem to be a bad style coding)
2) i incidentaly have my own library sickle.c which has chunk structure 
struc chunk {char* begin; char* end;} whise i pass (and return) by value

as to syntax of default pasing structs i wrote nearly 20 years ago nmad then later many times, so maybe i will not repeay it)


(overally c needs micromodules imo, what i name that)

[toc] | [prev] | [next] | [standalone]

#168868

niedziela, 22 stycznia 2023 o 18:17:24 UTC+1 fir napisał(a):
> niedziela, 22 stycznia 2023 o 16:54:28 UTC+1 Ben Bacarisse napisał(a): 
> > 
> > If it is just avoiding writing -> vs ., it's well know that C could just 
> > use . everywhere since the compiler always know when the LHS is a 
> > pointer to a struct. There would be no ambiguity, so that change would 
> > be very low cost. (I'm not sure it's a good idea, but that's a separate 
> > issue.) 
> >
> it may be kinda funny but i probbaly pass structures only by value (or nearly) 
> 
> its becouse 2 facts: 
> 1) i dont pass structures by pointers (i just dont need it, it seem to be a bad style coding) 
> 2) i incidentaly have my own library sickle.c which has chunk structure 
> struc chunk {char* begin; char* end;} whise i pass (and return) by value 
> 
> as to syntax of default pasing structs i wrote nearly 20 years ago nmad then later many times, so maybe i will not repeay it) 
> 
> 
> (overally c needs micromodules imo, what i name that)

micromodules are like structure-like entities but with more syntax to it

having more syntax to it allows some to build more tight code constructions
i mean given micromodule may reckognize if it is called on other type micromodule and if so fire more complex behaviour - i would need to think on some interesting examples though (as this invention is kinda abstract in root
of its idea)

overtally example i guess can be in such form

left right

when left is micromodule and right is micromodule
left is ready for some micro api (set of few methods )  that right provides and
right is ready for some micro api that left provides whis way more tight 
interactions of pieco of code may be coded (i didnt thinked on more specific examples yet)

maybe somethink like that say its

print log

log is a module that hasmethods .print_line() .next() .first() .end() or something close and prnt is able to use such interface to print it (both of this micromodules may take parameters) like print('short') log("some.txt") 
some say it can be called normal way but print could be used to be called on
eberything thut just conforms to some micro-api not only for log and
also log micro-api could be used  to do something more than just print

i suspect that micromodule syntax (i mean this static compilation checking)
woild be of use here (and maybe more complex or common examples can be showed)

[toc] | [prev] | [next] | [standalone]

#168869

niedziela, 22 stycznia 2023 o 18:57:04 UTC+1 fir napisał(a):
> niedziela, 22 stycznia 2023 o 18:17:24 UTC+1 fir napisał(a): 
> > niedziela, 22 stycznia 2023 o 16:54:28 UTC+1 Ben Bacarisse napisał(a): 
> > > 
> > > If it is just avoiding writing -> vs ., it's well know that C could just 
> > > use . everywhere since the compiler always know when the LHS is a 
> > > pointer to a struct. There would be no ambiguity, so that change would 
> > > be very low cost. (I'm not sure it's a good idea, but that's a separate 
> > > issue.) 
> > > 
> > it may be kinda funny but i probbaly pass structures only by value (or nearly) 
> > 
> > its becouse 2 facts: 
> > 1) i dont pass structures by pointers (i just dont need it, it seem to be a bad style coding) 
> > 2) i incidentaly have my own library sickle.c which has chunk structure 
> > struc chunk {char* begin; char* end;} whise i pass (and return) by value 
> > 
> > as to syntax of default pasing structs i wrote nearly 20 years ago nmad then later many times, so maybe i will not repeay it) 
> > 
> > 
> > (overally c needs micromodules imo, what i name that)
> micromodules are like structure-like entities but with more syntax to it 
> 
> having more syntax to it allows some to build more tight code constructions 
> i mean given micromodule may reckognize if it is called on other type micromodule and if so fire more complex behaviour - i would need to think on some interesting examples though (as this invention is kinda abstract in root 
> of its idea) 
> 
> overtally example i guess can be in such form 
> 
> left right 
> 
> when left is micromodule and right is micromodule 
> left is ready for some micro api (set of few methods ) that right provides and 
> right is ready for some micro api that left provides whis way more tight 
> interactions of pieco of code may be coded (i didnt thinked on more specific examples yet) 
> 
> maybe somethink like that say its 
> 
> print log 
> 
> log is a module that hasmethods .print_line() .next() .first() .end() or something close and prnt is able to use such interface to print it (both of this micromodules may take parameters) like print('short') log("some.txt") 
> some say it can be called normal way but print could be used to be called on 
> eberything thut just conforms to some micro-api not only for log and 
> also log micro-api could be used to do something more than just print 
> 
> i suspect that micromodule syntax (i mean this static compilation checking) 
> woild be of use here (and maybe more complex or common examples can be showed)

other example could be assome you got mm (short for micromodule) that finds some string "cat" in some other text micromodule then another stores it in the array or sums the occurances 

sum find("cat") txt("some.txt")

*this with parenthesis () are parameters where entiyies/other micromodules
are withouth parenthesis or by dot
print.sum.find("cat").txt("some.txt")

(thought dot dont show the direction of calling and kinda more natural maybe is from left to right
txt("some.txt").find("cat").sum().print()

looks weird but the goal now is only to judge its usability

[toc] | [prev] | [next] | [standalone]

#168871

the question is how it could be done on implementtaipon level

i guess something like that can be seen as start for thinking

module rand  {
  int provide_integer() {  return rand(); }
}

module sum (int n) [   expect module B with int provide_integer(); ]
{
  int sum = 0;

   int provide_integer() 
  {
      for(int i=0;i<n; i++)   
      {
        sum+=  B.provide_integer();
       }
      return sum;
   }
}


then it could be called 

printf("%d", sum(120) rand);

[toc] | [prev] | [next] | [standalone]

#168872

niedziela, 22 stycznia 2023 o 20:01:17 UTC+1 fir napisał(a):
> the question is how it could be done on implementtaipon level 
> 
> i guess something like that can be seen as start for thinking 
> 
> module rand { 
> int provide_integer() { return rand(); } 
> } 
> 
> module sum (int n) [ expect module B with int provide_integer(); ] 
> { 
> int sum = 0; 
> 
> int provide_integer() 
> { 
> for(int i=0;i<n; i++) 
> { 
> sum+= B.provide_integer(); 
> } 
> return sum; 
> } 
> } 
> 
> 
> then it could be called 
> 
> printf("%d", sum(120) rand);

well it should yet have

 module sum (int n) [ expect module B with int provide_integer(); ] 
 { 
 int sum = 0; 
 provide_integer();
 return sum;

 int provide_integer()  {  for(int i=0;i<n; i++)  {  sum+= B.provide_integer();  }  return sum;  } 
 } 

i guess such micromodules could greatly improve seed of coding becouse there would be many patterns written, omstead of sum there could be building up and stacking dynamic array of ints etc, then using it greatly should speed up writing some things

[toc] | [prev] | [next] | [standalone]

#168873

niedziela, 22 stycznia 2023 o 20:08:19 UTC+1 fir napisał(a):
> niedziela, 22 stycznia 2023 o 20:01:17 UTC+1 fir napisał(a): 
> > the question is how it could be done on implementtaipon level 
> > 
> > i guess something like that can be seen as start for thinking 
> > 
> > module rand { 
> > int provide_integer() { return rand(); } 
> > } 
> > 
> > module sum (int n) [ expect module B with int provide_integer(); ] 
> > { 
> > int sum = 0; 
> > 
> > int provide_integer() 
> > { 
> > for(int i=0;i<n; i++) 
> > { 
> > sum+= B.provide_integer(); 
> > } 
> > return sum; 
> > } 
> > } 
> > 
> > 
> > then it could be called 
> > 
> > printf("%d", sum(120) rand);
> well it should yet have
> module sum (int n) [ expect module B with int provide_integer(); ] 
> { 
> int sum = 0;
> provide_integer(); 
> return sum;
> int provide_integer() { for(int i=0;i<n; i++) { sum+= B.provide_integer(); } return sum; } 
> }
> i guess such micromodules could greatly improve seed of coding becouse there would be many patterns written, omstead of sum there could be building up and stacking dynamic array of ints etc, then using it greatly should speed up writing some things

note this invention is oryginal i never seen or heard on something like that so if someone will do this in some language he probably took it from here (may take it indirectly also) i add it as i suspect some people do nt credit someone else work (and this invention is kinda fresh and tempting to implement) .. not that i much care but to be strict for state of things ;c later i probably will ad more examples of module-module call chains

[toc] | [prev] | [next] | [standalone]

#168890

niedziela, 22 stycznia 2023 o 20:08:19 UTC+1 fir napisał(a):
> niedziela, 22 stycznia 2023 o 20:01:17 UTC+1 fir napisał(a): 
> > the question is how it could be done on implementtaipon level 
> > 
> > i guess something like that can be seen as start for thinking 
> > 
> > module rand { 
> > int provide_integer() { return rand(); } 
> > } 
> > 
> > 
> > then it could be called 
> > 
> > printf("%d", sum(120) rand);
> well it should yet have
> module sum (int n) [ expect module B with int provide_integer(); ] 
> { 
> int sum = 0;
> provide_integer(); 
> return sum;
> int provide_integer() { for(int i=0;i<n; i++) { sum+= B.provide_integer(); } return sum; } 
> }
> i guess such micromodules could greatly improve seed of coding becouse there would be many patterns written, omstead of sum there could be building up and stacking dynamic array of ints etc, then using it greatly should speed up writing some things


thinked yet how examplec could be showed but not much come to my mind

for example if right is something like tree structure like directory structure, registry or json file, right wiull provude soem small api for wwalking and acessing the tree, same for some more info windows sometimes provides

left then could be a code porocedure that yses this api to do something..
hovever i dont see yet any example on which left would have anstract api and
right would gave avstract api to make this modules some two-side dialogue

[toc] | [prev] | [next] | [standalone]

#168886

On 1/22/2023 7:54 AM, Ben Bacarisse wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
> 
>> On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote:
>>> 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'.
>>
>> I guess the other option was to make structs arguments passed by
>> reference. The same for arrays.
> 
> (I'd say "and the same for arrays".  As it stands, it could sound like
> you think arrays are currently "passed by reference".  I know you don;t
> think that, but it's a common enough misconception that you'd want to
> avoid any hint of it.)
> 
>> void f(struct X x, int a[2]) {
>>   // sizeof(x) and sizeof(a)  would not be sizeof pointer
>> }
>>
>> no need for -> everywhere inside structs.
> 
> And now you have a different anomaly in the language.  Everything except
> structs and arrays are passed by reference.

I must be misunderstanding you here. You say, everything, _except_ 
structs and arrays are passed by reference. What about:

void foo(int bar)
{
     bar = 666;
}

bar is not passed by reference.

{
     int bar = 123;
     foo(bar);
     // bar = 123, NOT 666.
}

? Where did I misunderstand you Ben?



>  And, what's more, the
> caller can't tell if a function can change the passed object because the
> pass by reference is invisible at the call site.  If I have a type T x
> object, is x passed by value or reference in the call f(x)?
> 
> What is the problem with C that you are trying to solve?  I can't see
> the issue.
> 
> If it is just avoiding writing -> vs ., it's well know that C could just
> use . everywhere since the compiler always know when the LHS is a
> pointer to a struct.  There would be no ambiguity, so that change would
> be very low cost.  (I'm not sure it's a good idea, but that's a separate
> issue.)
> 

[toc] | [prev] | [next] | [standalone]

#168893

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:

> On 1/22/2023 7:54 AM, Ben Bacarisse wrote:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>> 
>>> On Saturday, January 21, 2023 at 9:55:10 PM UTC-3, Michael S wrote:
>>>> 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'.
>>>
>>> I guess the other option was to make structs arguments passed by
>>> reference. The same for arrays.
>>
>> (I'd say "and the same for arrays".  As it stands, it could sound like
>> you think arrays are currently "passed by reference".  I know you don;t
>> think that, but it's a common enough misconception that you'd want to
>> avoid any hint of it.)
>> 
>>> void f(struct X x, int a[2]) {
>>>   // sizeof(x) and sizeof(a)  would not be sizeof pointer
>>> }
>>>
>>> no need for -> everywhere inside structs.
>> And now you have a different anomaly in the language.  Everything except
>> structs and arrays are passed by reference.
>
> I must be misunderstanding you here.

No, you are understand what I wrote but I wrote the wrong thing.  I
meant to write "by value".  It's a common mistake I make.  I write it
one way, then edit in a way that makes things clearer but sometimes I
forget to edit a key part, and "except" or a "not" or an "otherwise"!

> ? Where did I misunderstand you Ben?

Nowhere!  Thanks for spotting it.

 "And now you have a different anomaly in the language.  Everything
 except structs and arrays are passed by value."

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8  Next page →

Back to top | Article view | comp.lang.c

csiph-web