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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8  Next page →

#168897

On 1/22/2023 1:43 PM, Ben Bacarisse wrote:
> "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."
> 

Can't a struct be passed by value? I see the _except_ clause in your 
sentence. Some quick code typed in the damn newsreader, sorry for any typos!
______________
#include <stdio.h>


struct bar
{
     int baz;
};

void foo(struct bar bar)
{
     bar.baz = 666;

     printf(
         "foo::(%p)->struct bar::baz = %d\n",
         (void*)&bar,
         bar.baz
     );
}

int main()
{
     struct bar bar = { 123 };

     foo(bar);

     printf(
         "main::(%p)->struct bar::baz = %d\n",
         (void*)&bar,
         bar.baz
     );

     return 0;
}

______________

I should get an output of something like:

foo::(pointer_value)->struct bar::baz = 666
main::(pointer_value)->struct bar::baz = 123

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

#168900

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

> On 1/22/2023 1:43 PM, Ben Bacarisse wrote:
>> "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."
>
> Can't a struct be passed by value? I see the _except_ clause in your
> sentence. Some quick code typed in the damn newsreader, sorry for any
> typos!

In current C, yes, but I was commenting on TA's suggestion that passing
of structs and arrays should be changed.  In TA's suggestion, these
would be always be passed by reference.  He seemed to want to tidy
something up, but the effect is to create a new anomaly.

May I should have said "would be" rather than "are" to keep it clear
that I am talking about a hypothetical language.

-- 
Ben.

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

#168901

On 1/22/2023 2:29 PM, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> 
>> On 1/22/2023 1:43 PM, Ben Bacarisse wrote:
>>> "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."
>>
>> Can't a struct be passed by value? I see the _except_ clause in your
>> sentence. Some quick code typed in the damn newsreader, sorry for any
>> typos!
> 
> In current C, yes, but I was commenting on TA's suggestion that passing
> of structs and arrays should be changed.  In TA's suggestion, these
> would be always be passed by reference.  He seemed to want to tidy
> something up, but the effect is to create a new anomaly.
> 
> May I should have said "would be" rather than "are" to keep it clear
> that I am talking about a hypothetical language.
> 

Ahhh. Thank you for clearing that up Ben. For some reason, I failed to 
notice this wrt the OP. ;^o

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

#168915

On Sunday, January 22, 2023 at 7:30:12 PM UTC-3, Ben Bacarisse wrote:
> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes: 
> 
> > On 1/22/2023 1:43 PM, Ben Bacarisse wrote: 
> >> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes: 
> >> 
> >>> On 1/22/2023 7:54 AM, Ben Bacarisse wrote: 
> >>>> 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. 
> >>> 
> >>> 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." 
> > 
> > Can't a struct be passed by value? I see the _except_ clause in your 
> > sentence. Some quick code typed in the damn newsreader, sorry for any 
> > typos!
> In current C, yes, but I was commenting on TA's suggestion that passing 
> of structs and arrays should be changed. 

I don´t have a suggestion to change C right now, because of the impact
of existing code that is modifying a copy of the argument. 

>In TA's suggestion, these 
> would be always be passed by reference. He seemed to want to tidy 
> something up, but the effect is to create a new anomaly. 
> 
> May I should have said "would be" rather than "are" to keep it clear 
> that I am talking about a hypothetical language. 
> 
Yes I am talking about a time machine. If I was there I would recommend
by reference.
I searched but  I didn't find the rationally for structs by value and 
arrays (similar of references). We can just imagine some reasons.
Maybe it would broke some existing code for arrays for instance. And not
for structs because structs were not allowed in arguments.

I also would like to know the decision of this decorative array on arguments.
And also why when in C99 they added  [static  N] in arrays instead of just 
making the past decorative syntax behave like [static N].

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

#168921

On 23/01/2023 04:06, Thiago Adams wrote:
> On Sunday, January 22, 2023 at 7:30:12 PM UTC-3, Ben Bacarisse wrote:
>> "Chris M. Thomasson" <chris.m.t...@gmail.com> writes:
>>

>>> Can't a struct be passed by value? I see the _except_ clause in your
>>> sentence. Some quick code typed in the damn newsreader, sorry for any
>>> typos!
>> In current C, yes, but I was commenting on TA's suggestion that passing
>> of structs and arrays should be changed.
> 
> I don´t have a suggestion to change C right now, because of the impact
> of existing code that is modifying a copy of the argument.
> 
Surely the solution is simple (assuming you are happy making a compiler 
for a non-standard modified C)?  Add references in the style of C++. 
Then existing code will work fine as it is, and if you want to pass 
structs by reference, you can do so by declaring the appropriate 
parameter as a reference parameter.  You get the best of both worlds, 
while using a syntax and concepts that are already familiar to many people.

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

#168914

On Sunday, January 22, 2023 at 12:54:28 PM UTC-3, Ben Bacarisse wrote:
> 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 
> > } 

It works as if arrays were reference. Like

void f(int a[2]){
    a[0] = 1;
}
int main() {
    int a[2] = {0};
    f(a);
    assert(a[0] == 1);
}
 
And no need for address of.

> > 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. 

Don`t you think arrays already look like an anomaly? See the sample above.
We don't need  address of, we can mix pointers and arrays, the index is ignored in 
arguments and the sizeof of array argument does not make sense.
Latter [static] was added.

>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)? 

It is already invisible for arrays.
 
> What is the problem with C that you are trying to solve? I can't see 
> the issue. 

I don't have a suggestion right now. I am only thinking about the decision
of the past and wondering about an alternative design.
The problem I see is that we could have better ergonomics for something
that for me is 99.9% of the time.  (passing pointer to structs)

> 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.) 
> 
Yes. On the other hand it may make hard to know that the pointer may be null.
If we pass structs by reference like

void f(struct X x) 

I would say that we have an extra information that the pointer
must not be null (similar of C++ references but with no extra syntax) so 
using pointer to struct would make clear that the value is optional and may be null.

void f(struct X* p /*optional*/) 

we can do this today

void f(int a[2]){
    a[0] = 1;
}
int main() {
    int a[2] = {0};
    f(0);    
}

with references we would have an error on this sample.
sizeof of argument would be fixed.

I also like the & operator on the caller site. But it does not necessarily
means we change the argument because we can have

void f(const struct X* p); 

that have f(&s) on the caller side and does not modify the struct.

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

#168923

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

> On Sunday, January 22, 2023 at 12:54:28 PM UTC-3, Ben Bacarisse wrote:
>> 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 
>> > } 
>
> It works as if arrays were reference. Like
>
> void f(int a[2]){
>     a[0] = 1;
> }
> int main() {
>     int a[2] = {0};
>     f(a);
>     assert(a[0] == 1);
> }
>  
> And no need for address of.
>
>> > no need for -> everywhere inside structs.
>>
>> And now you have a different anomaly in the language. Everything except 
>> structs and arrays are passed by [value].

(I have corrected my editing error in the above.)

> Don`t you think arrays already look like an anomaly? See the sample
> above.

Yes, they are.  My point is you switch one for another so I don't see
the point.

And your suggestion does address what happens with arrays in /other/
contexts, so it's possible you are, in fact, adding a new anomaly to the
exiting array one.  At least arrays are widely anomalous -- it's not
just when passed to functions that array names decay to pointers.  You
have to lean this peculiarity in about lesson two when learning C!

-- 
Ben.

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

#169235

On Fri, 2023-01-20, 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, a lot. I don't write C these days, but last time I got to design
new C code, in 2014 or so, I used the feature heavily, to get some
properties I'd normally get from C++. I think call by value is one of
the great things about the C family of languages.

> Could it be replaced by const * ?

No.

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

No (obviously).  And I think it's futile to debate irreversible
language decision made 50 years ago. Better learn how those decisions
affect how you can write code well.

I do wonder why so many C programmers believed, for so long, that you
could only pass ints and pointers as parameters, but that's just idle
curiosity.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#169236

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
> On Fri, 2023-01-20, Thiago Adams wrote:
[...]
>> Do  you have structs passed by copy in your code?
>
> Yes, a lot. I don't write C these days, but last time I got to design
> new C code, in 2014 or so, I used the feature heavily, to get some
> properties I'd normally get from C++. I think call by value is one of
> the great things about the C family of languages.
>
>> Could it be replaced by const * ?
>
> No.

Could you expand on that?  I would think that any instance of passing a
struct by copy could be straightforwardly replaced by passing it by
const*, assuming your able to modify both the caller and the callee.
I'm not suggesting that this *should* be done, but you seem to be saying
that it *couldn't*.  (I could be a good idea for large structs.)

[...]

-- 
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]

#169237

On Sunday, 12 February 2023 at 01:08:24 UTC+2, Keith Thompson wrote:
> Jorgen Grahn <grahn...@snipabacken.se> writes: 
> > On Fri, 2023-01-20, Thiago Adams wrote:
> [...]
> >> Do you have structs passed by copy in your code? 
> > 
> > Yes, a lot. I don't write C these days, but last time I got to design 
> > new C code, in 2014 or so, I used the feature heavily, to get some 
> > properties I'd normally get from C++. I think call by value is one of 
> > the great things about the C family of languages. 
> > 
> >> Could it be replaced by const * ? 
> > 
> > No.
> 
> Could you expand on that? I would think that any instance of passing a 
> struct by copy could be straightforwardly replaced by passing it by 
> const*, assuming your able to modify both the caller and the callee. 
> I'm not suggesting that this *should* be done, but you seem to be saying 
> that it *couldn't*. (I could be a good idea for large structs.) 
> 
Because the meanings differ heavily. On case of pointer to const parameter
the function says that it needs immutable access to something, possibly
optional and possibly array, (that needs to be further documented). On
case of by value parameter function says that it needs a single non-optional
mutable copy. And returning everything by pointer would make C rather
inconvenient to use ... but that they realised already at 1978.

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

#169238

Öö Tiib <ootiib@hot.ee> writes:
> On Sunday, 12 February 2023 at 01:08:24 UTC+2, Keith Thompson wrote:
>> Jorgen Grahn <grahn...@snipabacken.se> writes: 
>> > On Fri, 2023-01-20, Thiago Adams wrote:
>> [...]
>> >> Do you have structs passed by copy in your code? 
>> > 
>> > Yes, a lot. I don't write C these days, but last time I got to design 
>> > new C code, in 2014 or so, I used the feature heavily, to get some 
>> > properties I'd normally get from C++. I think call by value is one of 
>> > the great things about the C family of languages. 
>> > 
>> >> Could it be replaced by const * ? 
>> > 
>> > No.
>> 
>> Could you expand on that? I would think that any instance of passing a 
>> struct by copy could be straightforwardly replaced by passing it by 
>> const*, assuming your able to modify both the caller and the callee. 
>> I'm not suggesting that this *should* be done, but you seem to be saying 
>> that it *couldn't*. (I could be a good idea for large structs.) 
>> 
> Because the meanings differ heavily. On case of pointer to const parameter
> the function says that it needs immutable access to something, possibly
> optional and possibly array, (that needs to be further documented). On
> case of by value parameter function says that it needs a single non-optional
> mutable copy. And returning everything by pointer would make C rather
> inconvenient to use ... but that they realised already at 1978.

I was actually asking Jorgen what *he* meant.

I wouldn't say there's that much difference between passing by copy and
passing by pointer-to-const.  The former does allow the function to
modify its copy of the parameter, but in my experience that's not a
common requirement.  And the discussion was about parameters, not return
values.

I can't think of a case where pass-by-copy *can't* be replaced by
pass-by-pointer-to-const.  If you need a local modifiable copy, you can
make one.  (And again, I'm not suggesting such a replacement *should* be
done in any particular case.)

-- 
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]

#169240

On 2/11/23 19:32, Keith Thompson wrote:
...
> I wouldn't say there's that much difference between passing by copy and
> passing by pointer-to-const.  The former does allow the function to
> modify its copy of the parameter, but in my experience that's not a
> common requirement.  And the discussion was about parameters, not return
> values.

It might not be a common requirement, but in my experience the existence
of such a requirement is, in C, the main reason why I'd use
pass-by-value rather than a pointer-to-const.

> I can't think of a case where pass-by-copy *can't* be replaced by
> pass-by-pointer-to-const.  If you need a local modifiable copy, you can
> make one.  (And again, I'm not suggesting such a replacement *should* be
> done in any particular case.)

So, you would replace pass-by-copy with pass-by-reference followed by
copy? I don't see the point. I wouldn't do that for the same reason I
wouldn't do the following:

long double _Complex func(const long double _Complex *in)
{
long double _Complex out = *in;
// operations which modify out
return out;
}

I chose long double _Complex just because it's likely to be the largest
scalar type, and might be passed in the same fashion as a struct
containing two long doubles.

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

#169242

On 12/02/2023 07:23, James Kuyper wrote:
> On 2/11/23 19:32, Keith Thompson wrote:
> ...
>> I wouldn't say there's that much difference between passing by copy and
>> passing by pointer-to-const.  The former does allow the function to
>> modify its copy of the parameter, but in my experience that's not a
>> common requirement.  And the discussion was about parameters, not return
>> values.
> 
> It might not be a common requirement, but in my experience the existence
> of such a requirement is, in C, the main reason why I'd use
> pass-by-value rather than a pointer-to-const.
> 
>> I can't think of a case where pass-by-copy *can't* be replaced by
>> pass-by-pointer-to-const.  If you need a local modifiable copy, you can
>> make one.  (And again, I'm not suggesting such a replacement *should* be
>> done in any particular case.)
> 
> So, you would replace pass-by-copy with pass-by-reference followed by
> copy? I don't see the point. I wouldn't do that for the same reason I
> wouldn't do the following:
> 
> long double _Complex func(const long double _Complex *in)
> {
> long double _Complex out = *in;
> // operations which modify out
> return out;
> }
> 

If you have a function that takes a struct parameter by value, then the 
normal calling convention (assuming the struct is too big to fit in 
registers, and that the functions involved are not optimised together in 
some way) will have the caller function make a local copy of the struct 
on its stack and pass a pointer to that struct to the callee.  The 
callee function is compiled as though it took a non-const pointer to the 
struct as the parameter.

If you pass a const pointer to the struct, then no copy need be made of 
the struct.  But if the callee wants a modifiable copy of the struct, it 
must make its own local copy (as Keith suggested).

At first glance, these two situations take the same amount of run-time 
effort (time and stack space) when the callee needs to modify a copy of 
the struct), but the manual local copy is a little more source code 
effort.  In practice, however, smart compilers can do better.  The 
function that took a const reference and made a local copy need not 
necessarily actually copy everything.  If the new copy is not treated as 
a complete struct (such as by passing a pointer to it to another 
function), then the compiler might just make local copies of the fields 
that are actually changed, and use the original for other fields.  It is 
common practice for compilers to consider structs as a collection of 
separate objects (and vice versa) if that allows greater efficiency.

So yes, there /is/ a point in passing by const reference and making a 
local copy.

Of course your emphasis should usually be on picking an interface that 
gives the clearest information in the code - getting the code right, and 
helping those who use the functions get things right is top priority. 
Maximal efficiency of the generated code is of secondary priority.  But 
when maximal efficiency is important, there can be differences here.

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

#169250

On 12/02/2023 10:24, David Brown wrote:
> If you have a function that takes a struct parameter by value, then the 
> normal calling convention (assuming the struct is too big to fit in 
> registers, and that the functions involved are not optimised together in 
> some way) will have the caller function make a local copy of the struct 
> on its stack and pass a pointer to that struct to the callee.  The 
> callee function is compiled as though it took a non-const pointer to the 
> struct as the parameter.
> 
> If you pass a const pointer to the struct, then no copy need be made of 
> the struct.  But if the callee wants a modifiable copy of the struct, it 
> must make its own local copy (as Keith suggested).
> 
> At first glance, these two situations take the same amount of run-time 
> effort (time and stack space) when the callee needs to modify a copy of 
> the struct), but the manual local copy is a little more source code 
> effort.  In practice, however, smart compilers can do better.  The 
> function that took a const reference and made a local copy need not 
> necessarily actually copy everything.  If the new copy is not treated as 
> a complete struct (such as by passing a pointer to it to another 
> function), then the compiler might just make local copies of the fields 
> that are actually changed, and use the original for other fields.  It is 
> common practice for compilers to consider structs as a collection of 
> separate objects (and vice versa) if that allows greater efficiency.
> 
> So yes, there /is/ a point in passing by const reference and making a 
> local copy.
> 
> Of course your emphasis should usually be on picking an interface that 
> gives the clearest information in the code - getting the code right, and 
> helping those who use the functions get things right is top priority. 
> Maximal efficiency of the generated code is of secondary priority.  But 
> when maximal efficiency is important, there can be differences here.

Should a smart compiler not realise that the called function is not 
modifying many of the fields of the structure, and allow it to access 
the original memory? It then need only copy the fields, if any, that are 
modified.

Andy

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

#169252

On 12/02/2023 23:11, Vir Campestris wrote:
> On 12/02/2023 10:24, David Brown wrote:
>> If you have a function that takes a struct parameter by value, then 
>> the normal calling convention (assuming the struct is too big to fit 
>> in registers, and that the functions involved are not optimised 
>> together in some way) will have the caller function make a local copy 
>> of the struct on its stack and pass a pointer to that struct to the 
>> callee.  The callee function is compiled as though it took a non-const 
>> pointer to the struct as the parameter.
>>
>> If you pass a const pointer to the struct, then no copy need be made 
>> of the struct.  But if the callee wants a modifiable copy of the 
>> struct, it must make its own local copy (as Keith suggested).
>>
>> At first glance, these two situations take the same amount of run-time 
>> effort (time and stack space) when the callee needs to modify a copy 
>> of the struct), but the manual local copy is a little more source code 
>> effort.  In practice, however, smart compilers can do better.  The 
>> function that took a const reference and made a local copy need not 
>> necessarily actually copy everything.  If the new copy is not treated 
>> as a complete struct (such as by passing a pointer to it to another 
>> function), then the compiler might just make local copies of the 
>> fields that are actually changed, and use the original for other 
>> fields.  It is common practice for compilers to consider structs as a 
>> collection of separate objects (and vice versa) if that allows greater 
>> efficiency.
>>
>> So yes, there /is/ a point in passing by const reference and making a 
>> local copy.
>>
>> Of course your emphasis should usually be on picking an interface that 
>> gives the clearest information in the code - getting the code right, 
>> and helping those who use the functions get things right is top 
>> priority. Maximal efficiency of the generated code is of secondary 
>> priority.  But when maximal efficiency is important, there can be 
>> differences here.
> 
> Should a smart compiler not realise that the called function is not 
> modifying many of the fields of the structure, and allow it to access 
> the original memory? It then need only copy the fields, if any, that are 
> modified.
> 

That would require the compiler to see both functions at the same time, 
and be able to optimise them together.  If that's the case, with the 
functions in the same translation unit or using LTO, then it can do all 
sorts of things to generate more efficient code.

The point is that with the version of the called function that takes a 
const pointer and makes a local copy, you can get the more efficient 
optimisation even without the functions being visible at the same time.

(Again, let me note that I am not saying you /should/ use a 
pointer-to-const instead of passing the struct as a value - you should 
use whatever method is clearest in your code unless you have real need 
of the highest possible efficiency.)

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

#169253

On Monday, February 13, 2023 at 6:26:12 AM UTC-3, David Brown wrote:
> On 12/02/2023 23:11, Vir Campestris wrote: 
> > On 12/02/2023 10:24, David Brown wrote: 
> >> If you have a function that takes a struct parameter by value, then 
> >> the normal calling convention (assuming the struct is too big to fit 
> >> in registers, and that the functions involved are not optimised 
> >> together in some way) will have the caller function make a local copy 
> >> of the struct on its stack and pass a pointer to that struct to the 
> >> callee.  The callee function is compiled as though it took a non-const 
> >> pointer to the struct as the parameter. 
> >> 
> >> If you pass a const pointer to the struct, then no copy need be made 
> >> of the struct.  But if the callee wants a modifiable copy of the 
> >> struct, it must make its own local copy (as Keith suggested). 
> >> 
> >> At first glance, these two situations take the same amount of run-time 
> >> effort (time and stack space) when the callee needs to modify a copy 
> >> of the struct), but the manual local copy is a little more source code 
> >> effort.  In practice, however, smart compilers can do better.  The 
> >> function that took a const reference and made a local copy need not 
> >> necessarily actually copy everything.  If the new copy is not treated 
> >> as a complete struct (such as by passing a pointer to it to another 
> >> function), then the compiler might just make local copies of the 
> >> fields that are actually changed, and use the original for other 
> >> fields.  It is common practice for compilers to consider structs as a 
> >> collection of separate objects (and vice versa) if that allows greater 
> >> efficiency. 
> >> 
> >> So yes, there /is/ a point in passing by const reference and making a 
> >> local copy. 
> >> 
> >> Of course your emphasis should usually be on picking an interface that 
> >> gives the clearest information in the code - getting the code right, 
> >> and helping those who use the functions get things right is top 
> >> priority. Maximal efficiency of the generated code is of secondary 
> >> priority.  But when maximal efficiency is important, there can be 
> >> differences here. 
> > 
> > Should a smart compiler not realise that the called function is not 
> > modifying many of the fields of the structure, and allow it to access 
> > the original memory? It then need only copy the fields, if any, that are 
> > modified. 
> >
> That would require the compiler to see both functions at the same time, 
> and be able to optimise them together. If that's the case, with the 
> functions in the same translation unit or using LTO, then it can do all 
> sorts of things to generate more efficient code. 
> 
> The point is that with the version of the called function that takes a 
> const pointer and makes a local copy, you can get the more efficient 
> optimisation even without the functions being visible at the same time. 
> 
> (Again, let me note that I am not saying you /should/ use a 
> pointer-to-const instead of passing the struct as a value - you should 
> use whatever method is clearest in your code unless you have real need 
> of the highest possible efficiency.)


Maybe the way structs are copied, could be changed using a new calling 
convention.

The difference is that using this new calling convention the struct is passed
by  reference, and a local copy is created by the compiler. 
Then the compiler  could detect if the structs was "read only" and avoid the copy.

void _new_calling_convention f1(struct X x);

Then a program could set this new convention globally and we don´t need
to see "_new_calling_convention ".

If we try to call a function that use the older (other) calling convention
we would see an error. (similar of what already happens today)

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

#169254

On Monday, February 13, 2023 at 11:41:36 AM UTC-3, Thiago Adams wrote:
> On Monday, February 13, 2023 at 6:26:12 AM UTC-3, David Brown wrote: 
> > On 12/02/2023 23:11, Vir Campestris wrote: 
> > > On 12/02/2023 10:24, David Brown wrote: 
> > >> If you have a function that takes a struct parameter by value, then 
> > >> the normal calling convention (assuming the struct is too big to fit 
> > >> in registers, and that the functions involved are not optimised 
> > >> together in some way) will have the caller function make a local copy 
> > >> of the struct on its stack and pass a pointer to that struct to the 
> > >> callee. The callee function is compiled as though it took a non-const 
> > >> pointer to the struct as the parameter. 
> > >> 
> > >> If you pass a const pointer to the struct, then no copy need be made 
> > >> of the struct. But if the callee wants a modifiable copy of the 
> > >> struct, it must make its own local copy (as Keith suggested). 
> > >> 
> > >> At first glance, these two situations take the same amount of run-time 
> > >> effort (time and stack space) when the callee needs to modify a copy 
> > >> of the struct), but the manual local copy is a little more source code 
> > >> effort. In practice, however, smart compilers can do better. The 
> > >> function that took a const reference and made a local copy need not 
> > >> necessarily actually copy everything. If the new copy is not treated 
> > >> as a complete struct (such as by passing a pointer to it to another 
> > >> function), then the compiler might just make local copies of the 
> > >> fields that are actually changed, and use the original for other 
> > >> fields. It is common practice for compilers to consider structs as a 
> > >> collection of separate objects (and vice versa) if that allows greater 
> > >> efficiency. 
> > >> 
> > >> So yes, there /is/ a point in passing by const reference and making a 
> > >> local copy. 
> > >> 
> > >> Of course your emphasis should usually be on picking an interface that 
> > >> gives the clearest information in the code - getting the code right, 
> > >> and helping those who use the functions get things right is top 
> > >> priority. Maximal efficiency of the generated code is of secondary 
> > >> priority. But when maximal efficiency is important, there can be 
> > >> differences here. 
> > > 
> > > Should a smart compiler not realise that the called function is not 
> > > modifying many of the fields of the structure, and allow it to access 
> > > the original memory? It then need only copy the fields, if any, that are 
> > > modified. 
> > > 
> > That would require the compiler to see both functions at the same time, 
> > and be able to optimise them together. If that's the case, with the 
> > functions in the same translation unit or using LTO, then it can do all 
> > sorts of things to generate more efficient code. 
> > 
> > The point is that with the version of the called function that takes a 
> > const pointer and makes a local copy, you can get the more efficient 
> > optimisation even without the functions being visible at the same time. 
> > 
> > (Again, let me note that I am not saying you /should/ use a 
> > pointer-to-const instead of passing the struct as a value - you should 
> > use whatever method is clearest in your code unless you have real need 
> > of the highest possible efficiency.)
> Maybe the way structs are copied, could be changed using a new calling 
> convention. 
> 
> The difference is that using this new calling convention the struct is passed 
> by reference, and a local copy is created by the compiler. 
> Then the compiler could detect if the structs was "read only" and avoid the copy. 
> 
> void _new_calling_convention f1(struct X x); 
> 
> Then a program could set this new convention globally and we don´t need 
> to see "_new_calling_convention ". 
> 
> If we try to call a function that use the older (other) calling convention 
> we would see an error. (similar of what already happens today)

The bonus of this feature  is:

- We have a concept of non null reference. 
  No need for  a new syntax or semantics.
- less typing for the default situation

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

#169258

On 13/02/2023 15:50, Thiago Adams wrote:
> On Monday, February 13, 2023 at 11:41:36 AM UTC-3, Thiago Adams wrote:
>> On Monday, February 13, 2023 at 6:26:12 AM UTC-3, David Brown wrote:
>>> On 12/02/2023 23:11, Vir Campestris wrote:
>>>> On 12/02/2023 10:24, David Brown wrote:
>>>>> If you have a function that takes a struct parameter by value, then
>>>>> the normal calling convention (assuming the struct is too big to fit
>>>>> in registers, and that the functions involved are not optimised
>>>>> together in some way) will have the caller function make a local copy
>>>>> of the struct on its stack and pass a pointer to that struct to the
>>>>> callee. The callee function is compiled as though it took a non-const
>>>>> pointer to the struct as the parameter.
>>>>>
>>>>> If you pass a const pointer to the struct, then no copy need be made
>>>>> of the struct. But if the callee wants a modifiable copy of the
>>>>> struct, it must make its own local copy (as Keith suggested).
>>>>>
>>>>> At first glance, these two situations take the same amount of run-time
>>>>> effort (time and stack space) when the callee needs to modify a copy
>>>>> of the struct), but the manual local copy is a little more source code
>>>>> effort. In practice, however, smart compilers can do better. The
>>>>> function that took a const reference and made a local copy need not
>>>>> necessarily actually copy everything. If the new copy is not treated
>>>>> as a complete struct (such as by passing a pointer to it to another
>>>>> function), then the compiler might just make local copies of the
>>>>> fields that are actually changed, and use the original for other
>>>>> fields. It is common practice for compilers to consider structs as a
>>>>> collection of separate objects (and vice versa) if that allows greater
>>>>> efficiency.
>>>>>
>>>>> So yes, there /is/ a point in passing by const reference and making a
>>>>> local copy.
>>>>>
>>>>> Of course your emphasis should usually be on picking an interface that
>>>>> gives the clearest information in the code - getting the code right,
>>>>> and helping those who use the functions get things right is top
>>>>> priority. Maximal efficiency of the generated code is of secondary
>>>>> priority. But when maximal efficiency is important, there can be
>>>>> differences here.
>>>>
>>>> Should a smart compiler not realise that the called function is not
>>>> modifying many of the fields of the structure, and allow it to access
>>>> the original memory? It then need only copy the fields, if any, that are
>>>> modified.
>>>>
>>> That would require the compiler to see both functions at the same time,
>>> and be able to optimise them together. If that's the case, with the
>>> functions in the same translation unit or using LTO, then it can do all
>>> sorts of things to generate more efficient code.
>>>
>>> The point is that with the version of the called function that takes a
>>> const pointer and makes a local copy, you can get the more efficient
>>> optimisation even without the functions being visible at the same time.
>>>
>>> (Again, let me note that I am not saying you /should/ use a
>>> pointer-to-const instead of passing the struct as a value - you should
>>> use whatever method is clearest in your code unless you have real need
>>> of the highest possible efficiency.)
>> Maybe the way structs are copied, could be changed using a new calling
>> convention.
>>
>> The difference is that using this new calling convention the struct is passed
>> by reference, and a local copy is created by the compiler.
>> Then the compiler could detect if the structs was "read only" and avoid the copy.
>>

Changing calling conventions is such a massive impact it is completely 
infeasible.  No one is going to re-compile every library and every 
binary on every OS in order to support such a change.

>> void _new_calling_convention f1(struct X x);
>>
>> Then a program could set this new convention globally and we don´t need
>> to see "_new_calling_convention ".
>>
>> If we try to call a function that use the older (other) calling convention
>> we would see an error. (similar of what already happens today)
> 
> The bonus of this feature  is:
> 
> - We have a concept of non null reference.
>    No need for  a new syntax or semantics.
> - less typing for the default situation
> 

I hate to sound like Bonita, but there's a neighbouring language that 
already supports reference syntax.

And for existing C compilers, there are attributes to tell the compiler 
(for optimisation and/or warning checks) that a pointer is non-null.

I can't remember details of the current plans for attributes in C2x, but 
if it doesn't have a "non-null" attribute, it probably could and should.

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

#169261

On Monday, February 13, 2023 at 1:22:26 PM UTC-3, David Brown wrote:
> On 13/02/2023 15:50, Thiago Adams wrote: 
> > On Monday, February 13, 2023 at 11:41:36 AM UTC-3, Thiago Adams wrote: 
> >> On Monday, February 13, 2023 at 6:26:12 AM UTC-3, David Brown wrote: 
> >>> On 12/02/2023 23:11, Vir Campestris wrote: 
> >>>> On 12/02/2023 10:24, David Brown wrote: 
> >>>>> If you have a function that takes a struct parameter by value, then 
> >>>>> the normal calling convention (assuming the struct is too big to fit 
> >>>>> in registers, and that the functions involved are not optimised 
> >>>>> together in some way) will have the caller function make a local copy 
> >>>>> of the struct on its stack and pass a pointer to that struct to the 
> >>>>> callee. The callee function is compiled as though it took a non-const 
> >>>>> pointer to the struct as the parameter. 
> >>>>> 
> >>>>> If you pass a const pointer to the struct, then no copy need be made 
> >>>>> of the struct. But if the callee wants a modifiable copy of the 
> >>>>> struct, it must make its own local copy (as Keith suggested). 
> >>>>> 
> >>>>> At first glance, these two situations take the same amount of run-time 
> >>>>> effort (time and stack space) when the callee needs to modify a copy 
> >>>>> of the struct), but the manual local copy is a little more source code 
> >>>>> effort. In practice, however, smart compilers can do better. The 
> >>>>> function that took a const reference and made a local copy need not 
> >>>>> necessarily actually copy everything. If the new copy is not treated 
> >>>>> as a complete struct (such as by passing a pointer to it to another 
> >>>>> function), then the compiler might just make local copies of the 
> >>>>> fields that are actually changed, and use the original for other 
> >>>>> fields. It is common practice for compilers to consider structs as a 
> >>>>> collection of separate objects (and vice versa) if that allows greater 
> >>>>> efficiency. 
> >>>>> 
> >>>>> So yes, there /is/ a point in passing by const reference and making a 
> >>>>> local copy. 
> >>>>> 
> >>>>> Of course your emphasis should usually be on picking an interface that 
> >>>>> gives the clearest information in the code - getting the code right, 
> >>>>> and helping those who use the functions get things right is top 
> >>>>> priority. Maximal efficiency of the generated code is of secondary 
> >>>>> priority. But when maximal efficiency is important, there can be 
> >>>>> differences here. 
> >>>> 
> >>>> Should a smart compiler not realise that the called function is not 
> >>>> modifying many of the fields of the structure, and allow it to access 
> >>>> the original memory? It then need only copy the fields, if any, that are 
> >>>> modified. 
> >>>> 
> >>> That would require the compiler to see both functions at the same time, 
> >>> and be able to optimise them together. If that's the case, with the 
> >>> functions in the same translation unit or using LTO, then it can do all 
> >>> sorts of things to generate more efficient code. 
> >>> 
> >>> The point is that with the version of the called function that takes a 
> >>> const pointer and makes a local copy, you can get the more efficient 
> >>> optimisation even without the functions being visible at the same time. 
> >>> 
> >>> (Again, let me note that I am not saying you /should/ use a 
> >>> pointer-to-const instead of passing the struct as a value - you should 
> >>> use whatever method is clearest in your code unless you have real need 
> >>> of the highest possible efficiency.) 
> >> Maybe the way structs are copied, could be changed using a new calling 
> >> convention. 
> >> 
> >> The difference is that using this new calling convention the struct is passed 
> >> by reference, and a local copy is created by the compiler. 
> >> Then the compiler could detect if the structs was "read only" and avoid the copy. 
> >>
> Changing calling conventions is such a massive impact it is completely 
> infeasible. No one is going to re-compile every library and every 
> binary on every OS in order to support such a change.

Another option that does not require recompilation is to provide a header
with the explicit calling convention or a way to control it using macros.

Recompilation is already a common problem. For instance opensll needs
to have a version x86 for instance linked with static or dynamic c runtime
on windows. This would be a third option.

On windows (Visual Studio)  headers already have  the calling convention on it.
(I don´t know on linux?)

Despite commenting on the possibilities, I also think the pros and cons
need to be balanced.

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

#169263

On 13/02/2023 19:47, Thiago Adams wrote:
> On Monday, February 13, 2023 at 1:22:26 PM UTC-3, David Brown wrote:
>> On 13/02/2023 15:50, Thiago Adams wrote:
>>> On Monday, February 13, 2023 at 11:41:36 AM UTC-3, Thiago Adams wrote:
>>>> On Monday, February 13, 2023 at 6:26:12 AM UTC-3, David Brown wrote:
>>>>> On 12/02/2023 23:11, Vir Campestris wrote:
>>>>>> On 12/02/2023 10:24, David Brown wrote:
>>>>>>> If you have a function that takes a struct parameter by value, then
>>>>>>> the normal calling convention (assuming the struct is too big to fit
>>>>>>> in registers, and that the functions involved are not optimised
>>>>>>> together in some way) will have the caller function make a local copy
>>>>>>> of the struct on its stack and pass a pointer to that struct to the
>>>>>>> callee. The callee function is compiled as though it took a non-const
>>>>>>> pointer to the struct as the parameter.
>>>>>>>
>>>>>>> If you pass a const pointer to the struct, then no copy need be made
>>>>>>> of the struct. But if the callee wants a modifiable copy of the
>>>>>>> struct, it must make its own local copy (as Keith suggested).
>>>>>>>
>>>>>>> At first glance, these two situations take the same amount of run-time
>>>>>>> effort (time and stack space) when the callee needs to modify a copy
>>>>>>> of the struct), but the manual local copy is a little more source code
>>>>>>> effort. In practice, however, smart compilers can do better. The
>>>>>>> function that took a const reference and made a local copy need not
>>>>>>> necessarily actually copy everything. If the new copy is not treated
>>>>>>> as a complete struct (such as by passing a pointer to it to another
>>>>>>> function), then the compiler might just make local copies of the
>>>>>>> fields that are actually changed, and use the original for other
>>>>>>> fields. It is common practice for compilers to consider structs as a
>>>>>>> collection of separate objects (and vice versa) if that allows greater
>>>>>>> efficiency.
>>>>>>>
>>>>>>> So yes, there /is/ a point in passing by const reference and making a
>>>>>>> local copy.
>>>>>>>
>>>>>>> Of course your emphasis should usually be on picking an interface that
>>>>>>> gives the clearest information in the code - getting the code right,
>>>>>>> and helping those who use the functions get things right is top
>>>>>>> priority. Maximal efficiency of the generated code is of secondary
>>>>>>> priority. But when maximal efficiency is important, there can be
>>>>>>> differences here.
>>>>>>
>>>>>> Should a smart compiler not realise that the called function is not
>>>>>> modifying many of the fields of the structure, and allow it to access
>>>>>> the original memory? It then need only copy the fields, if any, that are
>>>>>> modified.
>>>>>>
>>>>> That would require the compiler to see both functions at the same time,
>>>>> and be able to optimise them together. If that's the case, with the
>>>>> functions in the same translation unit or using LTO, then it can do all
>>>>> sorts of things to generate more efficient code.
>>>>>
>>>>> The point is that with the version of the called function that takes a
>>>>> const pointer and makes a local copy, you can get the more efficient
>>>>> optimisation even without the functions being visible at the same time.
>>>>>
>>>>> (Again, let me note that I am not saying you /should/ use a
>>>>> pointer-to-const instead of passing the struct as a value - you should
>>>>> use whatever method is clearest in your code unless you have real need
>>>>> of the highest possible efficiency.)
>>>> Maybe the way structs are copied, could be changed using a new calling
>>>> convention.
>>>>
>>>> The difference is that using this new calling convention the struct is passed
>>>> by reference, and a local copy is created by the compiler.
>>>> Then the compiler could detect if the structs was "read only" and avoid the copy.
>>>>
>> Changing calling conventions is such a massive impact it is completely
>> infeasible. No one is going to re-compile every library and every
>> binary on every OS in order to support such a change.
> 
> Another option that does not require recompilation is to provide a header
> with the explicit calling convention or a way to control it using macros.
> 
> Recompilation is already a common problem. For instance opensll needs
> to have a version x86 for instance linked with static or dynamic c runtime
> on windows. This would be a third option.
> 
> On windows (Visual Studio)  headers already have  the calling convention on it.
> (I don´t know on linux?)
> 
> Despite commenting on the possibilities, I also think the pros and cons
> need to be balanced.
> 

Jumbled random calling conventions is a PITA that plagues Windows 
development.  MS almost managed to eliminate it with x86-64 - no one 
wants it brought back.  On other platforms, ABI's are well specified and 
everyone sticks to them, meaning that static and dynamic libraries can 
be mixed and matched, even object files can often be used with different 
compilers.

I really do not think having multiple different calling conventions, so 
that the same C code gives different incompatible behaviour, is a good idea.

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

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

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

csiph-web