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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-01-23 23:49 +0000 |
| Message-ID | <878rhssteq.fsf@bsb.me.uk> |
| In reply to | #168946 |
Michael S <already5chosen@yahoo.com> writes: > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote: >> On 23/01/2023 21:15, Keith Thompson wrote: >> > David Brown <david...@hesbynett.no> writes: >> > [...] >> >> I also wonder why the committee choose to make complex numbers >> >> mandatory in C99, then optional in C11. Complex numbers are not >> >> particularly hard to implement (once you have all the rest of floating >> >> point support and <math.h>), and on the user side they are zero cost >> >> if you don't use them. >> > >> > I had forgotten that C11 made complex numbers optional. I agree that it >> > was an odd decision, as was making VLAs optional. >> > >> > Making a feature optional could be a good first step towards making it >> > mandatory in a future edition of the standard. Making an existing >> > mandatory feature optional makes less sense to me. >> > >> Could it have been pressure from a certain major compiler manufacturer >> who has been extremely slow at implementing some C99 features, other >> than those that were also part of C++ ? Perhaps they wanted to change >> their reputation of being poor at C because they were far from C99 >> compliant, and they could now get C11 compliance with less effort. >> >> Or maybe that's just a conspiracy theory :-) > > I'd guess, that's part of the reason. > The other part is desire to make 'C' maximally close to a subset of > C++. But then C++ has had complex numbers (alost from the get-go), so maybe not! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-01-24 02:46 -0800 |
| Message-ID | <d17c6d83-8c66-4fbd-bb22-e006e3b395efn@googlegroups.com> |
| In reply to | #168963 |
On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote: > Michael S <already...@yahoo.com> writes: > > > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote: > >> On 23/01/2023 21:15, Keith Thompson wrote: > >> > David Brown <david...@hesbynett.no> writes: > >> > [...] > >> >> I also wonder why the committee choose to make complex numbers > >> >> mandatory in C99, then optional in C11. Complex numbers are not > >> >> particularly hard to implement (once you have all the rest of floating > >> >> point support and <math.h>), and on the user side they are zero cost > >> >> if you don't use them. > >> > > >> > I had forgotten that C11 made complex numbers optional. I agree that it > >> > was an odd decision, as was making VLAs optional. > >> > > >> > Making a feature optional could be a good first step towards making it > >> > mandatory in a future edition of the standard. Making an existing > >> > mandatory feature optional makes less sense to me. > >> > > >> Could it have been pressure from a certain major compiler manufacturer > >> who has been extremely slow at implementing some C99 features, other > >> than those that were also part of C++ ? Perhaps they wanted to change > >> their reputation of being poor at C because they were far from C99 > >> compliant, and they could now get C11 compliance with less effort. > >> > >> Or maybe that's just a conspiracy theory :-) > > > > I'd guess, that's part of the reason. > > The other part is desire to make 'C' maximally close to a subset of > > C++. > But then C++ has had complex numbers (alost from the get-go), so maybe > not! > > -- > Ben. C++ complex numbers are part of template library rather than of base language. C99 complex numbers and C++ complex number are not merely incompatible, forcing them to co-exist in the same program is not easy. And then, we have IPP (Intel Performance Primitives) complex types to make things more interesting. But my previous comment had smaller scope. All I wanted to say is that committee likely wants to reduce the # of 'C' programs that are neither legal C++ nor can be turned into legal C++ programs easily by adding few casts [that will still keep the legal C programs]. C99 VLA and complex numbers are by far the biggest obstacles here.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 04:18 -0800 |
| Message-ID | <7a94e733-dc25-4e3e-90f4-d00f4dcf9318n@googlegroups.com> |
| In reply to | #168986 |
wtorek, 24 stycznia 2023 o 11:46:23 UTC+1 Michael S napisał(a): > On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote: > > Michael S <already...@yahoo.com> writes: > > > > > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote: > > >> On 23/01/2023 21:15, Keith Thompson wrote: > > >> > David Brown <david...@hesbynett.no> writes: > > >> > [...] > > >> >> I also wonder why the committee choose to make complex numbers > > >> >> mandatory in C99, then optional in C11. Complex numbers are not > > >> >> particularly hard to implement (once you have all the rest of floating > > >> >> point support and <math.h>), and on the user side they are zero cost > > >> >> if you don't use them. > > >> > > > >> > I had forgotten that C11 made complex numbers optional. I agree that it > > >> > was an odd decision, as was making VLAs optional. > > >> > > > >> > Making a feature optional could be a good first step towards making it > > >> > mandatory in a future edition of the standard. Making an existing > > >> > mandatory feature optional makes less sense to me. > > >> > > > >> Could it have been pressure from a certain major compiler manufacturer > > >> who has been extremely slow at implementing some C99 features, other > > >> than those that were also part of C++ ? Perhaps they wanted to change > > >> their reputation of being poor at C because they were far from C99 > > >> compliant, and they could now get C11 compliance with less effort. > > >> > > >> Or maybe that's just a conspiracy theory :-) > > > > > > I'd guess, that's part of the reason. > > > The other part is desire to make 'C' maximally close to a subset of > > > C++. > > But then C++ has had complex numbers (alost from the get-go), so maybe > > not! > > > > -- > > Ben. > C++ complex numbers are part of template library rather than of base language. > C99 complex numbers and C++ complex number are not merely incompatible, > forcing them to co-exist in the same program is not easy. > And then, we have IPP (Intel Performance Primitives) complex types to make > things more interesting. > > But my previous comment had smaller scope. All I wanted to say is that > committee likely wants to reduce the # of 'C' programs that are neither > legal C++ nor can be turned into legal C++ programs easily by adding few casts > [that will still keep the legal C programs]. > C99 VLA and complex numbers are by far the biggest obstacles here. complex numbers should be implemented but not so much in c or c++ but on the cpu/assembly level it is bcouse the basic oparation of complex number it is x,y <-> fi, R (which uses atan2 and sqr cos and sin) is very basic and needed i also think that cpu should have precision for trigonometry to be set up becouse for many calculations for example when you got some x,y point and want to rotate it on angle +fi' (which involves atan2 and sqr to convert it to fir then add fi' to fi and then use cos sin to convert it to xy) you dont need 6 or 9 digit precision when calculating this trigonometry about 4 suffice i guess and internal circuit of cpu could do such lower digit precisions much quicker i quess there is though a problem how to expres it in language also
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 04:45 -0800 |
| Message-ID | <3d34409b-3c78-4cb9-87d4-8477de9e9008n@googlegroups.com> |
| In reply to | #168987 |
wtorek, 24 stycznia 2023 o 13:18:13 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 11:46:23 UTC+1 Michael S napisał(a):
> > On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote:
> > > Michael S <already...@yahoo.com> writes:
> > >
> > > > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote:
> > > >> On 23/01/2023 21:15, Keith Thompson wrote:
> > > >> > David Brown <david...@hesbynett.no> writes:
> > > >> > [...]
> > > >> >> I also wonder why the committee choose to make complex numbers
> > > >> >> mandatory in C99, then optional in C11. Complex numbers are not
> > > >> >> particularly hard to implement (once you have all the rest of floating
> > > >> >> point support and <math.h>), and on the user side they are zero cost
> > > >> >> if you don't use them.
> > > >> >
> > > >> > I had forgotten that C11 made complex numbers optional. I agree that it
> > > >> > was an odd decision, as was making VLAs optional.
> > > >> >
> > > >> > Making a feature optional could be a good first step towards making it
> > > >> > mandatory in a future edition of the standard. Making an existing
> > > >> > mandatory feature optional makes less sense to me.
> > > >> >
> > > >> Could it have been pressure from a certain major compiler manufacturer
> > > >> who has been extremely slow at implementing some C99 features, other
> > > >> than those that were also part of C++ ? Perhaps they wanted to change
> > > >> their reputation of being poor at C because they were far from C99
> > > >> compliant, and they could now get C11 compliance with less effort.
> > > >>
> > > >> Or maybe that's just a conspiracy theory :-)
> > > >
> > > > I'd guess, that's part of the reason.
> > > > The other part is desire to make 'C' maximally close to a subset of
> > > > C++.
> > > But then C++ has had complex numbers (alost from the get-go), so maybe
> > > not!
> > >
> > > --
> > > Ben.
> > C++ complex numbers are part of template library rather than of base language.
> > C99 complex numbers and C++ complex number are not merely incompatible,
> > forcing them to co-exist in the same program is not easy.
> > And then, we have IPP (Intel Performance Primitives) complex types to make
> > things more interesting.
> >
> > But my previous comment had smaller scope. All I wanted to say is that
> > committee likely wants to reduce the # of 'C' programs that are neither
> > legal C++ nor can be turned into legal C++ programs easily by adding few casts
> > [that will still keep the legal C programs].
> > C99 VLA and complex numbers are by far the biggest obstacles here.
> complex numbers should be implemented but not so much in c or c++ but on the cpu/assembly level
>
> it is bcouse the basic oparation of complex number it is x,y <-> fi, R
> (which uses atan2 and sqr cos and sin) is very basic and needed
>
> i also think that cpu should have precision for trigonometry to be set up
> becouse for many calculations for example when you got some x,y point
> and want to rotate it on angle +fi' (which involves atan2 and sqr to convert it to fir then add fi' to fi and then use cos sin to convert it to xy) you dont need 6 or 9 digit precision when calculating this trigonometry about 4 suffice i guess and internal circuit of cpu could do such lower digit precisions much quicker i quess
>
> there is though a problem how to expres it in language also
main problem is how to expres it in one line
i mean if you got o is a complex how to writa and read .x .y at once
p = {1,2}
{a,b}=p;
could be theoretycally used but im not sure its the best (though its also not the worst)
note if so this also rather mean that more natural function call is foo{1,2,3}
than foo(1,2,3) but round bersion looks better so maybe it suggest that
p=(1,2); (a,b)=p can be used (and maybe even p(1,2) and(a,b)p for short
its even kinda funny bcouse f(1,2,3,4) is a call with pasing and (a,b,c,d)f is a call with reting (returning) looks quite ok... [and this is stage idea how to do this complex call and et expressions when one is allowed to return more than one value, first time i seen that]
not sayin this syntax is the best as | looks tremendously good as separator,
but there it need proper decision when to use it and when not
note there is general separator that separates things in c (may be consecutive
function calls) and special separator that separates elemend of a vector/record/structure (and this separator has somewhat meaning of a gluer not separator, and maybe it would be good to use , more like separator and | more like gluer, im not sure yet though
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 04:54 -0800 |
| Message-ID | <dc558b92-b781-40f4-a456-e49439cc4901n@googlegroups.com> |
| In reply to | #168988 |
wtorek, 24 stycznia 2023 o 13:46:03 UTC+1 fir napisał(a):
> > it is bcouse the basic oparation of complex number it is x,y <-> fi, R
> > (which uses atan2 and sqr cos and sin) is very basic and needed
> >
> > i also think that cpu should have precision for trigonometry to be set up
> > becouse for many calculations for example when you got some x,y point
> > and want to rotate it on angle +fi' (which involves atan2 and sqr to convert it to fir then add fi' to fi and then use cos sin to convert it to xy) you dont need 6 or 9 digit precision when calculating this trigonometry about 4 suffice i guess and internal circuit of cpu could do such lower digit precisions much quicker i quess
> >
> > there is though a problem how to expres it in language also
> main problem is how to expres it in one line
>
> i mean if you got o is a complex how to writa and read .x .y at once
>
> p = {1,2}
>
> {a,b}=p;
>
> could be theoretycally used but im not sure its the best (though its also not the worst)
>
> note if so this also rather mean that more natural function call is foo{1,2,3}
> than foo(1,2,3) but round bersion looks better so maybe it suggest that
> p=(1,2); (a,b)=p can be used (and maybe even p(1,2) and(a,b)p for short
>
> its even kinda funny bcouse f(1,2,3,4) is a call with pasing and (a,b,c,d)f is a call with reting (returning) looks quite ok... [and this is stage idea how to do this complex call and et expressions when one is allowed to return more than one value, first time i seen that]
>
> not sayin this syntax is the best as | looks tremendously good as separator,
> but there it need proper decision when to use it and when not
>
> note there is general separator that separates things in c (may be consecutive
> function calls) and special separator that separates elemend of a vector/record/structure (and this separator has somewhat meaning of a gluer not separator, and maybe it would be good to use , more like separator and | more like gluer, im not sure yet though
this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 05:26 -0800 |
| Message-ID | <054f682d-5c1a-4238-8b98-a995a68f49edn@googlegroups.com> |
| In reply to | #168989 |
wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
>
> interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
some simple confusion i got was
what that should be
a, b=c, d
or what that should be
a b c
doeas todays conclusion say something on that? maybe..
the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
a b c
in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
maybe its becouse it conforms to
p = {1,2}
which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 05:38 -0800 |
| Message-ID | <34191d69-b8f8-4c67-b764-7382d3f0aab4n@googlegroups.com> |
| In reply to | #168993 |
wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> >
> > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> some simple confusion i got was
> what that should be
>
> a, b=c, d
>
> or what that should be
>
> a b c
>
> doeas todays conclusion say something on that? maybe..
>
> the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
>
> a b c
>
> in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
>
> a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
>
> maybe its becouse it conforms to
>
> p = {1,2}
>
> which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
hovewer some could say this yeild to some practical problem,
becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
void SetupCloud
{
ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
1:200: cloud_x.add(rand2 200 1900),
cloud_y.add(rand2 2200 3500)
cloud_z.add(rand2 0 1300)
cloud_r.add(rand2 10 30)
cloud_color.add(RandColor 0 255 0 255 0 255) ;
}
so quite different to what i say
but i dont wand now to think on that yet
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 05:53 -0800 |
| Message-ID | <db5c5524-9983-41f2-9e5f-0a3903d593d6n@googlegroups.com> |
| In reply to | #168994 |
wtorek, 24 stycznia 2023 o 14:38:26 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> > wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> > >
> > > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> > some simple confusion i got was
> > what that should be
> >
> > a, b=c, d
> >
> > or what that should be
> >
> > a b c
> >
> > doeas todays conclusion say something on that? maybe..
> >
> > the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
> >
> > a b c
> >
> > in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
> >
> > a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
> >
> > maybe its becouse it conforms to
> >
> > p = {1,2}
> >
> > which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> > 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
> hovewer some could say this yeild to some practical problem,
> becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
>
> where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
>
> void SetupCloud
> {
> ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
> 1:200: cloud_x.add(rand2 200 1900),
> cloud_y.add(rand2 2200 3500)
> cloud_z.add(rand2 0 1300)
> cloud_r.add(rand2 10 30)
> cloud_color.add(RandColor 0 255 0 255 0 255) ;
> }
>
> so quite different to what i say
>
> but i dont wand now to think on that yet
well overally this is maybe not much important yet becouse this is
matter of prioritizing operators (of calling structurization and separation)
underlying semantic behaviour seem to eb mostly done (probably) and
this seem most important
i probbaly need to do some experiments, it seem dor example that
if for example make rule that caling needs parenthesis and
no caling without parentesis can be done then sole space and
parenthesis may done a lot of structurisation and calling
itsef (by calling i also mean assigning bcouse = is not needed
so a lot of calling assigning and structurisation may be done
by pure spaces and parenthesis it seems so..then comma bay be add
as rough separator
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 06:20 -0800 |
| Message-ID | <34259986-2cbc-4828-ba46-a6336f081ed3n@googlegroups.com> |
| In reply to | #168995 |
wtorek, 24 stycznia 2023 o 14:53:41 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 14:38:26 UTC+1 fir napisał(a):
> > wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> > > wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > > > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> > > >
> > > > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> > > some simple confusion i got was
> > > what that should be
> > >
> > > a, b=c, d
> > >
> > > or what that should be
> > >
> > > a b c
> > >
> > > doeas todays conclusion say something on that? maybe..
> > >
> > > the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
> > >
> > > a b c
> > >
> > > in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
> > >
> > > a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
> > >
> > > maybe its becouse it conforms to
> > >
> > > p = {1,2}
> > >
> > > which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> > > 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
> > hovewer some could say this yeild to some practical problem,
> > becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
> >
> > where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
> >
> > void SetupCloud
> > {
> > ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
> > 1:200: cloud_x.add(rand2 200 1900),
> > cloud_y.add(rand2 2200 3500)
> > cloud_z.add(rand2 0 1300)
> > cloud_r.add(rand2 10 30)
> > cloud_color.add(RandColor 0 255 0 255 0 255) ;
> > }
> >
> > so quite different to what i say
> >
> > but i dont wand now to think on that yet
> well overally this is maybe not much important yet becouse this is
> matter of prioritizing operators (of calling structurization and separation)
> underlying semantic behaviour seem to eb mostly done (probably) and
> this seem most important
>
> i probbaly need to do some experiments, it seem dor example that
> if for example make rule that caling needs parenthesis and
> no caling without parentesis can be done then sole space and
> parenthesis may done a lot of structurisation and calling
> itsef (by calling i also mean assigning bcouse = is not needed
> so a lot of calling assigning and structurisation may be done
> by pure spaces and parenthesis it seems so..then comma bay be add
> as rough separator
it is damn sad to say
a b c
cant be a calls (call-chain) and you must write a(b(c))
but if you say it can be calls then f(a b c) cant ba a call on vector becouse a b c cant ba a vector and it must be written f(a,b,c) (or f a,b,c as i was writing)
from those two decisions (CAN and CANT ) CAN seem to be better probably
(though its not so sure becouse typically one use only 2 element call chains usually and then it get nice space based vectors f(a b(3 4) c) without a need of comma which it then can be used as separator...) but the thing that you cant write print 2 as call is aggreviating imo so probably CAN option is better
but it needs investigation (CAN option is imo more clasical)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 06:56 -0800 |
| Message-ID | <66c0d619-a8fc-42b3-a994-835138909cd0n@googlegroups.com> |
| In reply to | #168998 |
wtorek, 24 stycznia 2023 o 15:20:56 UTC+1 fir napisał(a):
> wtorek, 24 stycznia 2023 o 14:53:41 UTC+1 fir napisał(a):
> > wtorek, 24 stycznia 2023 o 14:38:26 UTC+1 fir napisał(a):
> > > wtorek, 24 stycznia 2023 o 14:26:38 UTC+1 fir napisał(a):
> > > > wtorek, 24 stycznia 2023 o 13:54:28 UTC+1 fir napisał(a):
> > > > > this obviously looks kinda good and as i said probbaly resolves some of my syntax problems
> > > > >
> > > > > interesting is a(b) and (a)b becouse it is like the same a takes value from b, but a(b) means a is fired than takes valueof b which then is fired , and (a)b means b is fired then pases its value to a (which then can also be fired)..this is nice imo
> > > > some simple confusion i got was
> > > > what that should be
> > > >
> > > > a, b=c, d
> > > >
> > > > or what that should be
> > > >
> > > > a b c
> > > >
> > > > doeas todays conclusion say something on that? maybe..
> > > >
> > > > the forst should be rather (a,b)(c,d) than a,(b=c), d i guess (im not fully sure as i cant feel my brain to much sadly today so im not quite sure from which rules it outcomem, but maybe dont matter)
> > > >
> > > > a b c
> > > >
> > > > in turn ahoud be calls (typically a b is like a(b) so i think a b c whould rather yeild to a(b c) which is a(b(c))
> > > >
> > > > a b, c in turn should rather be a(b,c) not (a b), c see above...im not quite sure at the moment from which that rule of priority outcomes but it is probably right
> > > >
> > > > maybe its becouse it conforms to
> > > >
> > > > p = {1,2}
> > > >
> > > > which i guess is right.. if you use 1,2 it means its a gluer (structurizer) holding 1 and 2 together ..and you cant omit it becouse otherwise 1 2 would mean 1(2)
> > > > 1 calls 2 so if you want skip helping syntax of = {} then whao you get p 1,2 or p=1,2 shouldnty be read otherwise than oryginal imo..this may be not maybe considered proof (that this is ok choice) but maybe it also could (probably) so it suggest me that choices shown are more like okay than not
> > > hovewer some could say this yeild to some practical problem,
> > > becouse here calling (empty space) is so favorized, then structurisation (comma) so what with just ability to put things in one line
> > >
> > > where in my real language i compile with my furia compiler (now in state of about half basic compiler done) i use it like
> > >
> > > void SetupCloud
> > > {
> > > ints cloud_x, ints cloud_y, ints cloud_z, ints cloud_r, ints cloud_color
> > > 1:200: cloud_x.add(rand2 200 1900),
> > > cloud_y.add(rand2 2200 3500)
> > > cloud_z.add(rand2 0 1300)
> > > cloud_r.add(rand2 10 30)
> > > cloud_color.add(RandColor 0 255 0 255 0 255) ;
> > > }
> > >
> > > so quite different to what i say
> > >
> > > but i dont wand now to think on that yet
> > well overally this is maybe not much important yet becouse this is
> > matter of prioritizing operators (of calling structurization and separation)
> > underlying semantic behaviour seem to eb mostly done (probably) and
> > this seem most important
> >
> > i probbaly need to do some experiments, it seem dor example that
> > if for example make rule that caling needs parenthesis and
> > no caling without parentesis can be done then sole space and
> > parenthesis may done a lot of structurisation and calling
> > itsef (by calling i also mean assigning bcouse = is not needed
> > so a lot of calling assigning and structurisation may be done
> > by pure spaces and parenthesis it seems so..then comma bay be add
> > as rough separator
> it is damn sad to say
>
> a b c
>
> cant be a calls (call-chain) and you must write a(b(c))
>
> but if you say it can be calls then f(a b c) cant ba a call on vector becouse a b c cant ba a vector and it must be written f(a,b,c) (or f a,b,c as i was writing)
>
> from those two decisions (CAN and CANT ) CAN seem to be better probably
> (though its not so sure becouse typically one use only 2 element call chains usually and then it get nice space based vectors f(a b(3 4) c) without a need of comma which it then can be used as separator...) but the thing that you cant write print 2 as call is aggreviating imo so probably CAN option is better
> but it needs investigation (CAN option is imo more clasical)
well in fact the option that a b,c may be treated as (a b), c may be seen as THIRD option so maybe in fact i should reconsider that too, but im a littel tired recently (feels like i cant feel the upper part of my brain, but maybe i should rest)
the third option allows a b c (as CAN version do) it also gives rough separator (as CANT version gives) it changes the meaning of a,b=3,c but maybe its not such bad, i cant compregend it fully now but probably teh way of getting to some conclusion is to slowly compare those 3 syntax scenarios then yet see if some additional will not do appear
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2023-01-24 07:17 -0800 |
| Message-ID | <2a1a9180-7f6d-4336-b463-fd6b8e745ad5n@googlegroups.com> |
| In reply to | #169000 |
wtorek, 24 stycznia 2023 o 15:56:32 UTC+1 fir napisał(a): > > > > from those two decisions (CAN and CANT ) CAN seem to be better probably > > (though its not so sure becouse typically one use only 2 element call chains usually and then it get nice space based vectors f(a b(3 4) c) without a need of comma which it then can be used as separator...) but the thing that you cant write print 2 as call is aggreviating imo so probably CAN option is better > > but it needs investigation (CAN option is imo more clasical) > well in fact the option that a b,c may be treated as (a b), c may be seen as THIRD option so maybe in fact i should reconsider that too, but im a littel tired recently (feels like i cant feel the upper part of my brain, but maybe i should rest) > > the third option allows a b c (as CAN version do) it also gives rough separator (as CANT version gives) it changes the meaning of a,b=3,c but maybe its not such bad, i cant compregend it fully now but probably teh way of getting to some conclusion is to slowly compare those 3 syntax scenarios then yet see if some additional will not do appear to sum examples a b c a b,c a,b c,d CANT: space means structurizer, comma means separator, () needed for call/assignment CAN: space means call, comma means structurizer THIRD: space means call, comma means separator and structurizer (if in parenthesis) riht now i would consider CAN and THIRD as usablem CAN is good but someone needs additional separator, THIRD gives separator but it needs parenthesis in calls that gabe more than 1 argument *which is maybe standalbe) so for now maybe the third is most usable
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2023-01-24 12:56 +0000 |
| Message-ID | <873580rsz7.fsf@bsb.me.uk> |
| In reply to | #168986 |
Michael S <already5chosen@yahoo.com> writes: > On Tuesday, January 24, 2023 at 1:50:02 AM UTC+2, Ben Bacarisse wrote: >> Michael S <already...@yahoo.com> writes: >> >> > On Monday, January 23, 2023 at 10:47:45 PM UTC+2, David Brown wrote: >> >> On 23/01/2023 21:15, Keith Thompson wrote: >> >> > David Brown <david...@hesbynett.no> writes: >> >> > [...] >> >> >> I also wonder why the committee choose to make complex numbers >> >> >> mandatory in C99, then optional in C11. Complex numbers are not >> >> >> particularly hard to implement (once you have all the rest of floating >> >> >> point support and <math.h>), and on the user side they are zero cost >> >> >> if you don't use them. >> >> > >> >> > I had forgotten that C11 made complex numbers optional. I agree that it >> >> > was an odd decision, as was making VLAs optional. >> >> > >> >> > Making a feature optional could be a good first step towards making it >> >> > mandatory in a future edition of the standard. Making an existing >> >> > mandatory feature optional makes less sense to me. >> >> > >> >> Could it have been pressure from a certain major compiler manufacturer >> >> who has been extremely slow at implementing some C99 features, other >> >> than those that were also part of C++ ? Perhaps they wanted to change >> >> their reputation of being poor at C because they were far from C99 >> >> compliant, and they could now get C11 compliance with less effort. >> >> >> >> Or maybe that's just a conspiracy theory :-) >> > >> > I'd guess, that's part of the reason. >> > The other part is desire to make 'C' maximally close to a subset of >> > C++. >> But then C++ has had complex numbers (alost from the get-go), so maybe >> not! > > C++ complex numbers are part of template library rather than of base language. > C99 complex numbers and C++ complex number are not merely incompatible, > forcing them to co-exist in the same program is not easy. > And then, we have IPP (Intel Performance Primitives) complex types to make > things more interesting. > > But my previous comment had smaller scope. All I wanted to say is that > committee likely wants to reduce the # of 'C' programs that are neither > legal C++ nor can be turned into legal C++ programs easily by adding few casts > [that will still keep the legal C programs]. > C99 VLA and complex numbers are by far the biggest obstacles here. OK, I see where you are going with this. You think that minimal adjustment is the aim. I was thinking that some class of programs using C's complex numbers could be made valid C++ with a fee macros and an #if or two, but it's been years since I wrote any such code and, anyway, you are suggesting a much narrower concept of "subset". By the way, are you basing this suggestion on some inside information (a paper, a private conversation...) or is it speculative? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2023-01-24 07:29 -0800 |
| Message-ID | <608dba34-16c8-4012-bc3a-e4d05243e327n@googlegroups.com> |
| In reply to | #168990 |
On Tuesday, January 24, 2023 at 2:56:59 PM UTC+2, Ben Bacarisse wrote: > By the way, are you basing this suggestion on some inside information (a > paper, a private conversation...) or is it speculative? > > -- > Ben. the later
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-01-23 15:44 -0800 |
| Message-ID | <86fsc0hl4i.fsf@linuxsc.com> |
| In reply to | #168903 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: [...] > BTW, I was wrong about one thing: Support for _Imaginary is optional > even for an implementation that predefines __STDC_IEC_559_COMPLEX__. > `#ifdef _Imaginary_I` can be used to detect whether an implementation > supports imaginary types. I don't see how you reach this conclusion. My reading of N1570 says an implementation that defines __STDC_IEC_559_COMPLEX__ must have imaginary types. Annex G is normative. It clearly states that an implementation that defines __STDC_IEC_559_COMPLEX__ must conform to its specifications. Section G.2 says _Imaginary is a keyword, and there are three imaginary types, float _Imaginary, double _Imaginary, and long double _Imaginary. That statement (actually a combination of two statements in the annex) is a specification, and so any designated implementation must conform to it. In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and '_Imaginary_I' are defined if and only if the implementation supports imaginary types, but I don't see that it gives any license to overrule any other statement in the standard. Annex G is clear that there are imaginary types, and the implementation must provide them. I don't see any wiggle room at all. What is the reasoning behind what you say above?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-01-23 16:37 -0800 |
| Message-ID | <87a628g440.fsf@nosuchdomain.example.com> |
| In reply to | #168961 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
> [...]
>
>> BTW, I was wrong about one thing: Support for _Imaginary is optional
>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
>> `#ifdef _Imaginary_I` can be used to detect whether an implementation
>> supports imaginary types.
>
> I don't see how you reach this conclusion. My reading of N1570 says
> an implementation that defines __STDC_IEC_559_COMPLEX__ must have
> imaginary types. Annex G is normative. It clearly states that an
> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
> its specifications. Section G.2 says _Imaginary is a keyword, and
> there are three imaginary types, float _Imaginary, double _Imaginary,
> and long double _Imaginary. That statement (actually a combination of
> two statements in the annex) is a specification, and so any designated
> implementation must conform to it.
I believe you're correct, and I was wrong (the second time, not
the first). I honestly don't know how I reached the conclusion
that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement
to support imaginary types. Most likely I read one document while
thinking it was a different one.
I apologize for the confusion.
> In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and
> '_Imaginary_I' are defined if and only if the implementation supports
> imaginary types, but I don't see that it gives any license to overrule
> any other statement in the standard. Annex G is clear that there are
> imaginary types, and the implementation must provide them. I don't
> see any wiggle room at all. What is the reasoning behind what you
> say above?
I now think that an implementation that defines __STDC_IEC_559_COMPLEX__
(which is optional) must support imaginary types as described in Annex G.
The N1570 draft, of the C11 standard, and of the N3054 draft of C23
are all consistent on this point.
Both gcc and clang define __STDC_IEC_559_COMPLEX__ but do not support
imaginary types (with command-line options to make them attempt to be
fully conforming). I find it surprising that they would both be
non-conforming in such a seemingly obvious way. The gcc 12.2.0 manual
doesn't even mention the _Imaginary keyword.
(Both complex and imaginary types are optional in C11. And a conforming
implementation could support both without supporting Annex G.)
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2023-01-23 20:13 -0500 |
| Message-ID | <tqnbb5$3rjfq$3@dont-email.me> |
| In reply to | #168967 |
On 1/23/23 19:37, Keith Thompson wrote: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >> [...] >> >>> BTW, I was wrong about one thing: Support for _Imaginary is optional >>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__. >>> `#ifdef _Imaginary_I` can be used to detect whether an implementation >>> supports imaginary types. >> >> I don't see how you reach this conclusion. My reading of N1570 says >> an implementation that defines __STDC_IEC_559_COMPLEX__ must have >> imaginary types. Annex G is normative. It clearly states that an >> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to >> its specifications. Section G.2 says _Imaginary is a keyword, and >> there are three imaginary types, float _Imaginary, double _Imaginary, >> and long double _Imaginary. That statement (actually a combination of >> two statements in the annex) is a specification, and so any designated >> implementation must conform to it. > > I believe you're correct, and I was wrong (the second time, not > the first). I honestly don't know how I reached the conclusion > that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement > to support imaginary types. Most likely I read one document while > thinking it was a different one. I think you were on the right track from the beginning. "The macros imaginary and _Imaginary_I are defined if and only if the implementation supports imaginary types." (7.3.1p5) That pretty clearly indicates that support for imaginary types is optional. It wouldn't be needed if imaginary types were guaranteed to be supported if complex types are supported.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-01-23 17:58 -0800 |
| Message-ID | <87pmb4elsn.fsf@nosuchdomain.example.com> |
| In reply to | #168980 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 1/23/23 19:37, Keith Thompson wrote:
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>> [...]
>>>
>>>> BTW, I was wrong about one thing: Support for _Imaginary is optional
>>>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__.
>>>> `#ifdef _Imaginary_I` can be used to detect whether an implementation
>>>> supports imaginary types.
>>>
>>> I don't see how you reach this conclusion. My reading of N1570 says
>>> an implementation that defines __STDC_IEC_559_COMPLEX__ must have
>>> imaginary types. Annex G is normative. It clearly states that an
>>> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to
>>> its specifications. Section G.2 says _Imaginary is a keyword, and
>>> there are three imaginary types, float _Imaginary, double _Imaginary,
>>> and long double _Imaginary. That statement (actually a combination of
>>> two statements in the annex) is a specification, and so any designated
>>> implementation must conform to it.
>>
>> I believe you're correct, and I was wrong (the second time, not
>> the first). I honestly don't know how I reached the conclusion
>> that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement
>> to support imaginary types. Most likely I read one document while
>> thinking it was a different one.
>
> I think you were on the right track from the beginning.
>
> "The macros imaginary and _Imaginary_I are defined if and only if the
> implementation supports imaginary types." (7.3.1p5)
>
> That pretty clearly indicates that support for imaginary types is
> optional. It wouldn't be needed if imaginary types were guaranteed to be
> supported if complex types are supported.
N1570 6.2.5 (Types) mentions complex types but not imaginary types,
other than in a footnote that refers to Annex G (and that incorrectly
says it's informative, as it was in C99). That seems like an odd
omission.
N1570 7.3.1 (<complex.h>) makes it clear that imaginary types are
optional (and that the macro I expands to an expression of either
complex or imaginary type, which seems really odd).
6.10.8.1: An implementation may predefine __STDC_NO_COMPLEX__ to
indicate that it doesn't support complex types (new in C11; in C99
complex types were mandatory).
My conclusions:
Support for complex types is optional.
Support for imaginary types is optional.
(Support for imaginary types but not complex types is probably allowed,
but would be silly.)
An implementation may optionally predefine __STDC_IEC_559_COMPLEX__.
Any implementation that does so must support both complex and imaginary
types, and must do so as specified by Annex G.
Recent versions of gcc and clang both predefine __STDC_IEC_559_COMPLEX__,
but neither supports imaginary types (with command-line options that
should make them conform to C11). This makes them non-conforming. I
feel like I might be missing something here, because it *seems* like an
obvious non-conformance, and I don't see anything about it on gcc's
bugzilla.
An implementation *could* support complex types, or complex and
imaginary types, without conforming to Annex G, for example if the
target platform doesn't support IEEE floating-point.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2023-01-24 07:53 -0800 |
| Message-ID | <86bkmogc9c.fsf@linuxsc.com> |
| In reply to | #168967 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >> >> [...] >> >>> BTW, I was wrong about one thing: Support for _Imaginary is optional >>> even for an implementation that predefines __STDC_IEC_559_COMPLEX__. >>> `#ifdef _Imaginary_I` can be used to detect whether an implementation >>> supports imaginary types. >> >> I don't see how you reach this conclusion. My reading of N1570 says >> an implementation that defines __STDC_IEC_559_COMPLEX__ must have >> imaginary types. Annex G is normative. It clearly states that an >> implementation that defines __STDC_IEC_559_COMPLEX__ must conform to >> its specifications. Section G.2 says _Imaginary is a keyword, and >> there are three imaginary types, float _Imaginary, double _Imaginary, >> and long double _Imaginary. That statement (actually a combination of >> two statements in the annex) is a specification, and so any designated >> implementation must conform to it. > > I believe you're correct, and I was wrong (the second time, not > the first). I honestly don't know how I reached the conclusion > that defining __STDC_IEC_559_COMPLEX__ *doesn't* imply a requirement > to support imaginary types. Most likely I read one document while > thinking it was a different one. > > I apologize for the confusion. No apology needed. >> In section 7.3.1, paragraph 5 says that the two macros 'imaginary' and >> '_Imaginary_I' are defined if and only if the implementation supports >> imaginary types, but I don't see that it gives any license to overrule >> any other statement in the standard. Annex G is clear that there are >> imaginary types, and the implementation must provide them. I don't >> see any wiggle room at all. What is the reasoning behind what you >> say above? > > I now think that an implementation that defines __STDC_IEC_559_COMPLEX__ > (which is optional) must support imaginary types as described in Annex G. > The N1570 draft, of the C11 standard, and of the N3054 draft of C23 > are all consistent on this point. > > Both gcc and clang define __STDC_IEC_559_COMPLEX__ but do not support > imaginary types (with command-line options to make them attempt to be > fully conforming). I find it surprising that they would both be > non-conforming in such a seemingly obvious way. The gcc 12.2.0 manual > doesn't even mention the _Imaginary keyword. What may have happened is that gcc implemented complex types around the time of C99, when complex types were required but Annex G was merely informative (and the last sentence of G.1 says "should conform" rather than "shall conform" as it does in C11). As far as C99 is concerned, gcc and clang are both conforming. Then, when C11 came along, no one noticed the switch in status of Annex G, and since relatively few people care about imaginary types, no one noticed that their absence violated the rules in the new standard. It may be the case that there are other parts of Annex G that either gcc or clang do not satisfy, perhaps because no one has pointed out the (possible) deficiencies. It would be nice if some energetic person would enter a bug report on the gcc bug list site, regarding the missing imaginary types. I have put in gcc bug reports in the past but don't have as much time for that now.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-01-24 11:14 -0800 |
| Message-ID | <87h6wfeodq.fsf@nosuchdomain.example.com> |
| In reply to | #169004 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
[...]
> It would be nice if some energetic person would enter a bug
> report on the gcc bug list site, regarding the missing imaginary
> types. I have put in gcc bug reports in the past but don't have
> as much time for that now.
*raises hand*
--
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 | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2023-01-24 12:02 -0800 |
| Message-ID | <87cz73em5o.fsf@nosuchdomain.example.com> |
| In reply to | #169006 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> [...]
>> It would be nice if some energetic person would enter a bug
>> report on the gcc bug list site, regarding the missing imaginary
>> types. I have put in gcc bug reports in the past but don't have
>> as much time for that now.
>
> *raises hand*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108531
"Imaginary types are not supported, violating ISO C Annex G"
After I submitted that, I found that it's probably a duplicate of
https://sourceware.org/bugzilla/show_bug.cgi?id=15720
which was resolved as "INVALID". I disagree with that resolution.
For clang:
https://github.com/llvm/llvm-project/issues/60269
--
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]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web