Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #168839 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2023-01-20 10:41 -0800 |
| Last post | 2023-03-05 14:05 +0100 |
| Articles | 20 on this page of 141 — 28 participants |
Back to article view | Back to comp.lang.c
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 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-03-01 10:42 -0800 |
| Message-ID | <874jr4nwib.fsf@nosuchdomain.example.com> |
| In reply to | #169414 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
> gcc does warn about `f(NULL)` (possibly requiring a command-line option
> depending on the version).
>
> $ cat c.c
> #include <stddef.h>
>
> int f(int a[static 7]){ return 0; }
>
> int main(void) {
> f(NULL);
> }
> $ gcc -c c.c
> c.c: In function ‘main’:
> c.c:6:5: warning: argument 1 to ‘int[static 28]’ is null where non-null expected [-Wnonnull]
> 6 | f(NULL);
> | ^~~~~~~
> c.c:3:5: note: in a call to function ‘f’
> 3 | int f(int a[static 7]){ return 0; }
> | ^
> $
>
> (The warning refers to the size of the array, not its length. I'll
> report this bug if someone else hasn't already done so.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108986
--
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]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-03-01 15:13 -0800 |
| Message-ID | <2d8e9c90-9f6f-4cd5-a09b-7e669f8fd996n@googlegroups.com> |
| In reply to | #169414 |
On Wednesday, 1 March 2023 at 18:23:38 UTC, Keith Thompson wrote:
> > Even sizeof() could be fixed to me, this would not affect my code.
> > int f(int a[2]){ sizeof(a) }
> That would break existing code, so it ain't gonna happen.
>
> Walter Bright, of Digital Mars and D, has a proposal for C in this
> article from 2009:
>
> https://www.digitalmars.com/articles/C-biggest-mistake.html
>
> The declaration
>
> void foo(char a[..])
>
> would cause an array argument to be passed as a fat pointer, a pair
> consisting of a pointer to the first element and a size_t holding its
> length. I tentatively like the idea, and I can't think of anything that
> it would break.
So, passing a slice? That's not really a new idea. But in C, it would need to be well-integrated with the rest of the language (eg. convert an array, or part of an array, to a slice, not necessarily involving parameter passing).
It would ideally have a for-statement that could loop over such a slice, using its bounds. But most uses of arrays now are represented as T* types not T[..], they do not have the necessary info.
When passing a T[..] object to an existing function that takes T* and a length, you need to be able to split it up. You also need to be able create a T[..] object from heap-allocated data.
It's not that easy to retrofit such a feature, and not so useful if everyone continues to use T* arrays.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2023-03-02 04:17 -0800 |
| Message-ID | <558edf71-69c9-4a30-b03b-0fb715521041n@googlegroups.com> |
| In reply to | #169417 |
On Wednesday, March 1, 2023 at 8:13:42 PM UTC-3, bart c wrote:
> On Wednesday, 1 March 2023 at 18:23:38 UTC, Keith Thompson wrote:
>
> > > Even sizeof() could be fixed to me, this would not affect my code.
> > > int f(int a[2]){ sizeof(a) }
> > That would break existing code, so it ain't gonna happen.
> >
> > Walter Bright, of Digital Mars and D, has a proposal for C in this
> > article from 2009:
> >
> > https://www.digitalmars.com/articles/C-biggest-mistake.html
> >
> > The declaration
> >
> > void foo(char a[..])
> >
> > would cause an array argument to be passed as a fat pointer, a pair
> > consisting of a pointer to the first element and a size_t holding its
> > length. I tentatively like the idea, and I can't think of anything that
> > it would break.
> So, passing a slice? That's not really a new idea. But in C, it would need to be well-integrated with the rest of the language (eg. convert an array, or part of an array, to a slice, not necessarily involving parameter passing).
>
> It would ideally have a for-statement that could loop over such a slice, using its bounds. But most uses of arrays now are represented as T* types not T[..], they do not have the necessary info.
>
> When passing a T[..] object to an existing function that takes T* and a length, you need to be able to split it up. You also need to be able create a T[..] object from heap-allocated data.
>
> It's not that easy to retrofit such a feature, and not so useful if everyone continues to use T* arrays.
C already have:
void f(int n, int a[n]) { }
if we have some syntax sugar at caller side to
group size+array like
int a[2];
f(a);
The logic to groups this is at caller side is consider this pair
"int n, int a[n]" as a unique argument. normal call just works as well.
void f2(float something, int n, int a[n], double somethingelse) { }
f2(1.0, a, 2.0);
This feature can simplify some functions, on the other hand
C is a very explicit language and I am not sure if this feature would
be well received.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-03-05 04:17 -0800 |
| Message-ID | <ecbd5e2a-3770-40ef-a104-031d5d16a674n@googlegroups.com> |
| In reply to | #169417 |
czwartek, 2 marca 2023 o 00:13:42 UTC+1 bart c napisał(a):
> On Wednesday, 1 March 2023 at 18:23:38 UTC, Keith Thompson wrote:
>
> > > Even sizeof() could be fixed to me, this would not affect my code.
> > > int f(int a[2]){ sizeof(a) }
> > That would break existing code, so it ain't gonna happen.
> >
> > Walter Bright, of Digital Mars and D, has a proposal for C in this
> > article from 2009:
> >
> > https://www.digitalmars.com/articles/C-biggest-mistake.html
> >
> > The declaration
> >
> > void foo(char a[..])
> >
> > would cause an array argument to be passed as a fat pointer, a pair
> > consisting of a pointer to the first element and a size_t holding its
> > length. I tentatively like the idea, and I can't think of anything that
> > it would break.
> So, passing a slice? That's not really a new idea. But in C, it would need to be well-integrated with the rest of the language (eg. convert an array, or part of an array, to a slice, not necessarily involving parameter passing).
>
> It would ideally have a for-statement that could loop over such a slice, using its bounds. But most uses of arrays now are represented as T* types not T[..], they do not have the necessary info.
>
> When passing a T[..] object to an existing function that takes T* and a length, you need to be able to split it up. You also need to be able create a T[..] object from heap-allocated data.
>
> It's not that easy to retrofit such a feature, and not so useful if everyone continues to use T* arrays.
you just use
typedef struct { char* beg,* end; } chunk;
in c, (or the second version with unisigned len instead cha* end
the l;en version seem to be more handy, but historically i use more
the first version)
then make some additions to C that makes some conversion
in language is kinda slight
(i wrote on this a hundred of posts or more ona span of few latst years)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-03-05 04:55 -0800 |
| Message-ID | <8500d373-1c89-4a64-83f6-be6ea61e4f31n@googlegroups.com> |
| In reply to | #169478 |
niedziela, 5 marca 2023 o 13:18:01 UTC+1 fir napisał(a):
> czwartek, 2 marca 2023 o 00:13:42 UTC+1 bart c napisał(a):
> > On Wednesday, 1 March 2023 at 18:23:38 UTC, Keith Thompson wrote:
> >
> > > > Even sizeof() could be fixed to me, this would not affect my code.
> > > > int f(int a[2]){ sizeof(a) }
> > > That would break existing code, so it ain't gonna happen.
> > >
> > > Walter Bright, of Digital Mars and D, has a proposal for C in this
> > > article from 2009:
> > >
> > > https://www.digitalmars.com/articles/C-biggest-mistake.html
> > >
> > > The declaration
> > >
> > > void foo(char a[..])
> > >
> > > would cause an array argument to be passed as a fat pointer, a pair
> > > consisting of a pointer to the first element and a size_t holding its
> > > length. I tentatively like the idea, and I can't think of anything that
> > > it would break.
> > So, passing a slice? That's not really a new idea. But in C, it would need to be well-integrated with the rest of the language (eg. convert an array, or part of an array, to a slice, not necessarily involving parameter passing).
> >
> > It would ideally have a for-statement that could loop over such a slice, using its bounds. But most uses of arrays now are represented as T* types not T[..], they do not have the necessary info.
> >
> > When passing a T[..] object to an existing function that takes T* and a length, you need to be able to split it up. You also need to be able create a T[..] object from heap-allocated data.
> >
> > It's not that easy to retrofit such a feature, and not so useful if everyone continues to use T* arrays.
> you just use
>
> typedef struct { char* beg,* end; } chunk;
>
> in c, (or the second version with unisigned len instead cha* end
> the l;en version seem to be more handy, but historically i use more
> the first version)
>
> then make some additions to C that makes some conversion
> in language is kinda slight
>
> (i wrote on this a hundred of posts or more ona span of few latst years)
btw on this fatpointers a heard something (though not from first hand, someone posted something on this on pl.comp.lang.c) and then i disliked it..it was before chunk and sickle.c invention... all thet chunk integration in c is kinda something else than FATPOINTER idea..yhough now thsi fat pointer doesnt look so bad
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-02 10:48 +0100 |
| Message-ID | <ttprcg$91q3$1@dont-email.me> |
| In reply to | #169414 |
On 01/03/2023 19:23, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> Even sizeof() could be fixed to me, this would not affect my code.
>> int f(int a[2]){ sizeof(a) }
>
> That would break existing code, so it ain't gonna happen.
>
You can't change what the code means, but a compiler can warn about it
(gcc does so). That's the best that can be done while retaining
backwards compatibility.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2023-03-02 04:07 -0800 |
| Message-ID | <c4ac64eb-fafe-409b-841b-2603d15681f7n@googlegroups.com> |
| In reply to | #169424 |
On Thursday, March 2, 2023 at 6:48:14 AM UTC-3, David Brown wrote:
> On 01/03/2023 19:23, Keith Thompson wrote:
> > Thiago Adams <thiago...@gmail.com> writes:
> >
> >> Even sizeof() could be fixed to me, this would not affect my code.
> >> int f(int a[2]){ sizeof(a) }
> >
> > That would break existing code, so it ain't gonna happen.
> >
> You can't change what the code means, but a compiler can warn about it
> (gcc does so). That's the best that can be done while retaining
> backwards compatibility.
Standard could just deprecate sizeof for array arguments.
Like:
void F(int a[2]){
// warning sizeof applied to array argument is deprecated.
// Use sizeof(&a[0]) instead.
sizeof(a);
}
and then 5 or 10 years latter repurpose the feature.
In case of int a[static 2] for instance, I cannot understand
why C standard standard was so cautious. The price for this
is very high because no one is using this feature the syntax
is ugly and probably the previous syntax could be repurpose for
this behavior. This feature is a warning so, any old code could just
remove warning using settings.
I really cannot understand how/why this was approved.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2023-03-02 15:08 +0100 |
| Message-ID | <ttqak1$afal$2@dont-email.me> |
| In reply to | #169426 |
On 02/03/2023 13:07, Thiago Adams wrote:
> On Thursday, March 2, 2023 at 6:48:14 AM UTC-3, David Brown wrote:
>> On 01/03/2023 19:23, Keith Thompson wrote:
>>> Thiago Adams <thiago...@gmail.com> writes:
>>>
>>>> Even sizeof() could be fixed to me, this would not affect my code.
>>>> int f(int a[2]){ sizeof(a) }
>>>
>>> That would break existing code, so it ain't gonna happen.
>>>
>> You can't change what the code means, but a compiler can warn about it
>> (gcc does so). That's the best that can be done while retaining
>> backwards compatibility.
>
> Standard could just deprecate sizeof for array arguments.
> Like:
>
> void F(int a[2]){
> // warning sizeof applied to array argument is deprecated.
> // Use sizeof(&a[0]) instead.
> sizeof(a);
> }
>
> and then 5 or 10 years latter repurpose the feature.
How long have you been using C? There are features that have been
marked as "obsolescent" in the standards for decades without being
removed. Backwards compatibility is king in C - even marking a feature
as "deprecated" is a laborious change to the standards.
Putting a warning in a compiler, however, is vastly easier. And if your
compiler doesn't aim to be compliant, you are free to make the warning
an error.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2023-03-02 09:22 -0800 |
| Message-ID | <616421ef-47f6-4443-b069-8ad0a52320a0n@googlegroups.com> |
| In reply to | #169429 |
On Thursday, March 2, 2023 at 11:08:16 AM UTC-3, David Brown wrote:
> On 02/03/2023 13:07, Thiago Adams wrote:
> > On Thursday, March 2, 2023 at 6:48:14 AM UTC-3, David Brown wrote:
> >> On 01/03/2023 19:23, Keith Thompson wrote:
> >>> Thiago Adams <thiago...@gmail.com> writes:
> >>>
> >>>> Even sizeof() could be fixed to me, this would not affect my code.
> >>>> int f(int a[2]){ sizeof(a) }
> >>>
> >>> That would break existing code, so it ain't gonna happen.
> >>>
> >> You can't change what the code means, but a compiler can warn about it
> >> (gcc does so). That's the best that can be done while retaining
> >> backwards compatibility.
> >
> > Standard could just deprecate sizeof for array arguments.
> > Like:
> >
> > void F(int a[2]){
> > // warning sizeof applied to array argument is deprecated.
> > // Use sizeof(&a[0]) instead.
> > sizeof(a);
> > }
> >
> > and then 5 or 10 years latter repurpose the feature.
> How long have you been using C? There are features that have been
> marked as "obsolescent" in the standards for decades without being
> removed. Backwards compatibility is king in C - even marking a feature
> as "deprecated" is a laborious change to the standards.
I have been programming in windows for many years.
From VC++ 6 to VC ++ 2023.
C code is very stable, but in general we had to update IDE/Tools every year
and deal with some adjustments mainly in C++.
For instance, I remember Visual C++ didn't have scope for variables at
for loop.
for (int i = 0;
scope of i was outside for. (I guess around 2003)
So they added an option /Zc:forScope that keeps the old behavior.
We are in 2023 and the option still there. (20 years later)
Recently they changed the preprocessor and this also became an
option. We can use the old preprocessor or new one. /Zc:preprocessor
We can also select the standard version we want to use. But having
individual flags allow us to mix new and old features and this can be
useful especially for a transitional period.
The point is.. compiler and tools can keep the "flag" to compile code
using the old behavior for many years. In this sizeof scenario I believe
a warning for deprecating and a review of the code is simple - just
change to sizeof(&a[0]) I am not suggesting this specific feature because
I think is better a bigger package of adjustments on the type system.
A too fast evolution is a bad thing in my view not because of a tooling
problem but because makes code less valuable. I personally like very much
the stability of C. This is one reason I disliked nullptr and still prefer NULL.
But any change needs to be evaluated individually. This sizeof of
array argument is clearly non sense. (it may be hard to find code using it intentionally)
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2023-03-01 13:34 +0000 |
| Message-ID | <ttnk8k$gnvm$2@news.xmission.com> |
| In reply to | #169407 |
In article <87cz5to2n3.fsf@nosuchdomain.example.com>,
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>Thiago Adams <thiago.adams@gmail.com> writes:
>[...]
>> 1 - Arrays arguments already "looks like" references.
>> So we cannot say all arguments are passed by copy in C.
>
>Yes, all arguments are passed by copy in C.
I'm surprised to see *you* using Thiago's terminology: "passed by copy".
That's not a standard term, is it? Isn't the usual term "passed by value"?
As far as I can tell, Thiago is the only one using that term, and it seems
to be confusing things.
But, that said, yes, we all know that all args are passed by value in C.
Everybody knowin' 'dat...
>Array arguments do not exist. Something that looks like an array
>argument or an array parameter is actually a pointer argument or
>parameter, and of course pointers are passed by copy.
Yes, everybody knowin' 'dat...
>> 2 - We also cannot say structs are copied because it is actually a
>> "shallow copy"
>
>Structs are copied. A shallow copy is a copy.
There is a theory that if you have to put a qualifier in front of a term,
then the resulting expression describes something that actually isn't
really that thing. Examples: Political Science is not a science. Neither
is Computer Science. There are many such things like this, in a wide
variety of human endeavors.
It seems clear that Thiago is asserting that a shallow copy is not really a
copy.
>It's not at all clear how a deep copy at the language level would even
>work. Say you have a linked list where each node contains a pointer to
>its associated data. Does a deep copy copy all the nodes, or all the
>nodes and what they point to? What if a node points to some huge
>recursive data structure? What if the linked list is circular? And if
>the language specified a deep copy, how would I do a shallow copy if I
>wanted one?
Other languages seem to have addressed and solved this question.
I think the .NET languages have both shallow and deep copies, available at
the programmer's option.
--
Nov 4, 2008 - the day when everything went
from being Clinton's fault to being Obama's fault.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2023-03-01 21:42 -0500 |
| Message-ID | <N2ULL.1383703$9sn9.842278@fx17.iad> |
| In reply to | #169411 |
On 3/1/23 8:34 AM, Kenny McCormack wrote: > In article <87cz5to2n3.fsf@nosuchdomain.example.com>, >> Structs are copied. A shallow copy is a copy. > > There is a theory that if you have to put a qualifier in front of a term, > then the resulting expression describes something that actually isn't > really that thing. Examples: Political Science is not a science. Neither > is Computer Science. There are many such things like this, in a wide > variety of human endeavors. > > Then there is no copy of objects as a copy will either be a shallow copy or a deep copy, or some other more involved name to describe it. To just say you "copied" an object doesn't fully define what you did, so something seems broken with the definition if that is the only "real" copy.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-03-06 09:36 -0800 |
| Message-ID | <86ilfd93zt.fsf@linuxsc.com> |
| In reply to | #169406 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Sunday, February 26, 2023 at 1:12:18?PM UTC-3, Tim Rentsch wrote:
>
>> Thiago Adams <thiago...@gmail.com> writes:
>>
>>> On Wednesday, February 15, 2023 at 6:52:51 AM UTC-3, Tim Rentsch wrote:
>>>
>>>> Jorgen Grahn <grahn...@snipabacken.se> writes:
>>>>
>>>>> I think call by value is one of the great things about the C
>>>>> family of languages.
>>>>
>>>> +1
>>>
>>> The idea of passing structs by value is a weak concept because
>>> the struct copy is only "superficial".
>>>
>>> struct person {
>>> char* name;
>>> };
>>>
>>> void f(struct person person) {
>>> person.name[0] = '1';
>>> }
>>>
>>> int main()
>>> {
>>> char buffer[] = "abc";
>>> struct person person = { .name = buffer };
>>> f(person);
>>> printf("%s", person.name); //prints 1bc
>>> }
>>
>> This argument even less convincing than saying automatic
>> transmissions are a bad idea because someone might put the
>> car in reverse while driving on the freeway. In short,
>> idiotic.
>
> My argument was more about the consistence of the type system
> not about security.
>
> Two situations where I can see the C type system is not very strict:
>
> 1 - Arrays arguments already "looks like" references.
> So we cannot say all arguments are passed by copy in C.
>
> 2 - We also cannot say structs are copied because it is actually a
> "shallow copy"
Any inconsistency about how C struct values are passed is only
in your head, and not in the C language or its type system.
[toc] | [prev] | [next] | [standalone]
| From | Maciej Zelma <maciej.projectmanager@gmail.com> |
|---|---|
| Date | 2023-02-17 14:10 -0800 |
| Message-ID | <d2231fed-a5b7-40ab-9485-ae39d4061086n@googlegroups.com> |
| In reply to | #168839 |
On Friday, January 20, 2023 at 1:41:16 PM UTC-5, Thiago Adams wrote: > structs arguments passed by copy by default. Because C uses a "pass-by-value" approach for function arguments, it's design choice afaik. > Today, I have 0% of structs being passed by copy in my code. > So for me this is a very bad default. Generally it depends. Both approaches have pros and cons. > If structs where passed by reference this would not be the only > exception on the type system because arrays are already passed > as pointers. Arrays do not exist in a form of a standalone, primitive objects, so you cannot pass it. You are allowed to pass-by-value only what fits into cpu register, for example a memory address (a pointer). > Do you have structs passed by copy in your code? Yes. > Could it be replaced by const * ? > Considering your answer would you agree with me that this is a bad default? "bad" is irrelevant. Say, the performance of passing a struct by copy or reference depends on the size of the struct, the specific use case, and the hardware architecture.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-02-17 15:45 -0800 |
| Message-ID | <87y1ovq2kh.fsf@nosuchdomain.example.com> |
| In reply to | #169304 |
Maciej Zelma <maciej.projectmanager@gmail.com> writes:
> On Friday, January 20, 2023 at 1:41:16 PM UTC-5, Thiago Adams wrote:
>> structs arguments passed by copy by default.
>
> Because C uses a "pass-by-value" approach for function arguments, it's
> design choice afaik.
>
>> Today, I have 0% of structs being passed by copy in my code.
>> So for me this is a very bad default.
>
> Generally it depends. Both approaches have pros and cons.
>
>> If structs where passed by reference this would not be the only
>> exception on the type system because arrays are already passed
>> as pointers.
>
> Arrays do not exist in a form of a standalone, primitive objects, so
> you cannot pass it.
I suppose that depends on what you mean by "primitive". There certainly
are standalone array objects, just as there are standalone struct
objects. There just aren't many operations you can perform on array
objects.
> You are allowed to pass-by-value only what fits into cpu register, for
> example a memory address (a pointer).
I suspect you meant something other than what you wrote.
Structures are passed by value, and they can be arbitrarily large.
`_Complex long double` is likely to be too big to fit into a CPU
register, but it can certainly be passed by value (for an implementation
that supports complex numbers). `long double` or `long long` may or may
not fit in a single register.
The C standard doesn't even discuss CPU registers (the "register"
keyword notwithstanding).
[...]
--
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]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2023-02-18 00:12 +0000 |
| Message-ID | <1KUHL.216091$PXw7.52113@fx45.iad> |
| In reply to | #169306 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >Maciej Zelma <maciej.projectmanager@gmail.com> writes: >> On Friday, January 20, 2023 at 1:41:16 PM UTC-5, Thiago Adams wrote: >>> structs arguments passed by copy by default. >> >> Because C uses a "pass-by-value" approach for function arguments, it's >> design choice afaik. >> >>> Today, I have 0% of structs being passed by copy in my code. >>> So for me this is a very bad default. >> >> Generally it depends. Both approaches have pros and cons. >> >>> If structs where passed by reference this would not be the only >>> exception on the type system because arrays are already passed >>> as pointers. >> >> Arrays do not exist in a form of a standalone, primitive objects, so >> you cannot pass it. > >I suppose that depends on what you mean by "primitive". There certainly >are standalone array objects, just as there are standalone struct >objects. There just aren't many operations you can perform on array >objects. > >> You are allowed to pass-by-value only what fits into cpu register, for >> example a memory address (a pointer). > >I suspect you meant something other than what you wrote. > >Structures are passed by value, and they can be arbitrarily large. >`_Complex long double` is likely to be too big to fit into a CPU >register, but it can certainly be passed by value (for an implementation >that supports complex numbers). `long double` or `long long` may or may >not fit in a single register. > >The C standard doesn't even discuss CPU registers (the "register" >keyword notwithstanding). > True. The various processor specific ABIs will define that, for example 64-bit ARMv8: Stage C - Assignment of arguments to registers and stack For each argument in the list the following rules are applied in turn until the argument has been allocated. When an argument is assigned to a register any unused bits in the register have unspecified value. When an argument is assigned to a stack slot any unused padding bytes have unspecified value. C.1 If the argument is a Half-, Single-, Double- or Quad- precision Floating-point or short vector type and the NSRN is less than 8, then the argument is allocated to the least significant bits of register v[NSRN]. The NSRN is incremented by one. The argument has now been allocated. C.2 If the argument is an HFA or an HVA and there are sufficient unallocated SIMD and Floating-point registers (NSRN + number of members \u2264 8), then the argument is allocated to SIMD and Floating-point registers (with one register per member of the HFA or HVA). The NSRN is incremented by the number of registers used. The argument has now been allocated. C.3 If the argument is an HFA or an HVA then the NSRN is set to 8 and the size of the argument is rounded up to the nearest multiple of 8 bytes. C.4 If the argument is an HFA, an HVA, a Quad-precision Floating-point or short vector type then the NSAA is rounded up to the next multiple of 8 if its natural alignment is \u2264 8 or the next multiple of 16 if its natural alignment is \u2265 16. C.5 If the argument is a Half- or Single- precision Floating Point type, then the size of the argument is set to 8 bytes. The effect is as if the argument had been copied to the least significant bits of a 64-bit register and the remaining bits filled with unspecified values. C.6 If the argument is an HFA, an HVA, a Half-, Single-, Double- or Quad- precision Floating-point or short vector type, then the argument is copied to memory at the adjusted NSAA. The NSAA is incremented by the size of the argument. The argument has now been allocated. C.7 If the argument is a Pure Scalable Type that consists of NV Scalable Vector Types and NP Scalable Predicate Types, if the argument is named, if NSRN+NV \u2264 8, and if NPRN+NP \u2264 4, then the Scalable Vector Types are allocated in order to z[NSRN]\u2026z[NSRN+NV-1] inclusive and the Scalable Predicate Types are allocated in order to p[NPRN]\u2026p[NPRN+NP-1] inclusive. The NSRN is incremented by NV and the NPRN is incremented by NP. The argument has now been allocated. C.8 If the argument is a Pure Scalable Type that has not been allocated by the rules above, then the argument is copied to memory allocated by the caller and the argument is replaced by a pointer to the copy (as for B.4 above). The argument is then allocated according to the rules below. C.9 If the argument is an Integral or Pointer Type, the size of the argument is less than or equal to 8 bytes and the NGRN is less than 8, the argument is copied to the least significant bits in x[NGRN]. The NGRN is incremented by one. The argument has now been allocated. C.10 If the argument has an alignment of 16 then the NGRN is rounded up to the next even number. C.11 If the argument is an Integral Type, the size of the argument is equal to 16 and the NGRN is less than 7, the argument is copied to x[NGRN] and x[NGRN+1]. x[NGRN] shall contain the lower addressed double-word of the memory representation of the argument. The NGRN is incremented by two. The argument has now been allocated. C.12 If the argument is a Composite Type and the size in double-words of the argument is not more than 8 minus NGRN, then the argument is copied into consecutive general-purpose registers, starting at x[NGRN]. The argument is passed as though it had been loaded into the registers from a double-word-aligned address with an appropriate sequence of LDR instructions loading consecutive registers from memory (the contents of any unused parts of the registers are unspecified by this standard). The NGRN is incremented by the number of registers used. The argument has now been allocated. C.13 The NGRN is set to 8. C.14 The NSAA is rounded up to the larger of 8 or the Natural Alignment of the argument\u2019s type. C.15 If the argument is a composite type then the argument is copied to memory at the adjusted NSAA. The NSAA is incremented by the size of the argument. The argument has now been allocated. C.16 If the size of the argument is less than 8 bytes then the size of the argument is set to 8 bytes. The effect is as if the argument was copied to the least significant bits of a 64-bit register and the remaining bits filled with unspecified values. C.17 The argument is copied to memory at the adjusted NSAA. The NSAA is incremented by the size of the argument. The argument has now been allocated. Basically any structure size (16 bytes or less, rounded up to 8-byte address boundary) that can fit in the remaining register arguments will be passed in consecutive registers, otherwise will be allocated on the caller stack. https://github.com/ARM-software/abi-aa/blob/2982a9f3b512a5bfdc9e3fea5d3b298f9165c36b/aapcs64/aapcs64.rst#the-base-procedure-call-standard
[toc] | [prev] | [next] | [standalone]
| From | bart c <bart4858@gmail.com> |
|---|---|
| Date | 2023-02-18 02:33 -0800 |
| Message-ID | <b5b84a47-95b3-4de1-8602-0d2b75cafd8en@googlegroups.com> |
| In reply to | #169307 |
On Saturday, 18 February 2023 at 00:12:59 UTC, Scott Lurndal wrote: > https://github.com/ARM-software/abi-aa/blob/2982a9f3b512a5bfdc9e3fea5d3b298f9165c36b/aapcs64/aapcs64.rst#the-base-procedure-call-standard Jesus. My comments about SYS V ABI pertained to the x64 processor, and I thought /that/ was complicated. I suspect that if I ever code for ARM64, ABI compliance will be strictly optional. (Wasn't the idea of RISC to keep things simple and therefore efficient?)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-02-18 00:44 -0500 |
| Message-ID | <tspokj$3t7aa$2@dont-email.me> |
| In reply to | #169304 |
On 2/17/23 17:10, Maciej Zelma wrote: > On Friday, January 20, 2023 at 1:41:16 PM UTC-5, Thiago Adams wrote: > >> structs arguments passed by copy by default. > > Because C uses a "pass-by-value" approach for function arguments, it's > design choice afaik. That answer doesn't quite fit the actual history. As originally designed, C did not allow structs to be passed by value, that feature was only added later. Originally, only pointers to structs could be passed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-02-17 22:21 -0800 |
| Message-ID | <87ttzjpk73.fsf@nosuchdomain.example.com> |
| In reply to | #169310 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 2/17/23 17:10, Maciej Zelma wrote:
>> On Friday, January 20, 2023 at 1:41:16 PM UTC-5, Thiago Adams wrote:
>>
>>> structs arguments passed by copy by default.
>>
>> Because C uses a "pass-by-value" approach for function arguments, it's
>> design choice afaik.
>
> That answer doesn't quite fit the actual history. As originally
> designed, C did not allow structs to be passed by value, that feature
> was only added later. Originally, only pointers to structs could be passed.
Right -- but those pointers have always been passed by value.
*All* function arguments are passed by value. You can emulate
pass-by-reference by passing the address of an object (a value of
pointer type).
What changed (some time before K&R1) is that it became possible to pass
struct values as function arguments. Struct pointers could be passed
before and after that change.
(As for arrays, the language has some syntactic sugar that can make it
look like they're being passed by reference, but again it's all just
pointers being passed by value.)
Of course you know all this. I'm just providing a slightly different
perspective.
--
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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2023-03-01 18:00 +0100 |
| Message-ID | <tto096$e4d$1@dont-email.me> |
| In reply to | #168839 |
Am 20.01.2023 um 19:41 schrieb Thiago Adams: > 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 > It may make sense to pass structs by copy if the temporary structure is changed inside the called function. C++ is more reliable with that since it has copy- and move-construction which allows temporaries to copy external resources.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2023-03-01 09:18 -0800 |
| Message-ID | <9fdc70f6-6f9b-45cf-a027-8fb342144473n@googlegroups.com> |
| In reply to | #169412 |
On Wednesday, March 1, 2023 at 1:59:31 PM UTC-3, Bonita Montero wrote: > Am 20.01.2023 um 19:41 schrieb Thiago Adams: > > 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 > > > > It may make sense to pass structs by copy if the temporary structure > is changed inside the called function. C++ is more reliable with that > since it has copy- and move-construction which allows temporaries to > copy external resources. (Since I am talking to Bonita..) At C++ API very few cases use objects passed by copy. One sample is when iterators begin, end are passed to a function. Because "this->' is implicitly many others usages are hidden. Of course, if structs where passed by reference these few cases could use const & an then make a internal copy. In real C++ code is very common to see a lot of "const std::string&." if the default of C were different maybe C+ references would not exist today and code would look just std::string s. (Another good default could be, const ref, and I guess Rust is doing this way) Since we are also talking about other languages, maybe Rust, C#, zig. https://ziglang.org/documentation/master/#Pass-by-value-Parameters "Primitive types such as Integers and Floats passed as parameters are copied, ..." "Structs, unions, and arrays can sometimes be more efficiently passed as a reference, since a copy could be arbitrarily expensive depending on the size. When these types are passed as parameters, Zig may choose to copy and pass by value, or pass by reference, whichever way Zig decides will be faster. " "For extern functions, Zig follows the C ABI for passing structs and unions by value. "
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web