Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73070 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-10-16 13:29 -0700 |
| Last post | 2015-10-16 20:45 -0700 |
| Articles | 20 on this page of 168 — 20 participants |
Back to article view | Back to comp.lang.c
C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 13:29 -0700
Re: C struct syntax allowance by usage Siri Cruz <chine.bleu@yahoo.com> - 2015-10-16 13:47 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 14:12 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-16 22:15 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 10:32 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 05:26 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 14:17 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 06:48 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-17 19:01 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-17 11:17 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-16 15:28 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 01:41 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 18:23 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:04 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 10:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 14:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:14 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:25 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 11:31 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:38 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 12:32 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:35 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 11:16 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:40 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 17:35 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 10:52 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 11:02 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 19:59 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-18 12:15 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 21:41 +0100
Likeliehood of RDC/SeaAlive implementation (Was: C struct syntax allowance by usage) gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-19 08:23 +0000
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:02 -0400
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-18 14:19 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 21:13 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 20:37 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:27 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 23:14 +0200
Re: C struct syntax allowance by usage asetofsymbols@gmail.com - 2015-10-18 15:09 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-18 16:11 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 07:57 +1300
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-18 20:11 +0100
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 09:19 +1300
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:19 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 03:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 13:52 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 05:39 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 14:57 +0200
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-19 10:31 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-18 15:49 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-18 16:53 -0700
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 01:50 +0100
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 02:28 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 12:38 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 12:09 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:26 +0200
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-19 13:34 +0100
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 02:36 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 05:09 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 14:41 +0200
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-19 06:08 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-19 15:20 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 08:24 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 08:43 +1300
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-19 13:00 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-19 20:34 +0000
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-20 09:47 +1300
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-19 16:32 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 10:37 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-19 21:24 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-20 13:49 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-20 07:33 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:53 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:37 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:05 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 02:02 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 06:07 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 14:15 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 09:23 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 18:30 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 12:13 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 21:17 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 14:21 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-21 14:55 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:45 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:33 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 08:54 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-23 15:59 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:03 -0700
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:37 -0400
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-21 23:26 +0100
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 15:56 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:19 +0000
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 11:08 +0100
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:58 +0200
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-22 14:06 +0200
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 07:41 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-22 14:00 +0100
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 21:00 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 14:57 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 14:41 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-21 13:01 -0700
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-21 13:25 -0700
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-22 07:44 +0000
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:41 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:22 +0000
Re: C struct syntax allowance by usage Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-22 01:01 -0700
Re: C struct syntax allowance by usage Les Cargill <lcargill99@comcast.com> - 2015-10-22 08:00 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:49 -0400
Re: C struct syntax allowance by usage Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-21 13:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-20 15:40 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-20 11:55 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-20 10:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:20 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-21 05:11 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-21 09:47 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 05:32 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 10:08 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-22 21:45 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:09 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-22 19:22 -0400
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-22 17:49 -0700
Re: C struct syntax allowance by usage Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-10-22 21:13 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:36 +0000
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-22 20:18 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:55 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-23 11:14 +0000
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 09:09 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:31 +0000
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:17 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-11-10 10:39 -0800
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 11:02 -0800
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 15:54 -0400
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 13:51 -0700
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-23 17:41 -0400
Re: C struct syntax allowance by usage raltbos@xs4all.nl (Richard Bos) - 2015-11-10 15:32 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-23 15:17 -0700
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-23 16:34 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-24 09:51 +0000
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-24 10:01 -0400
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 12:38 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-24 13:56 -0500
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-24 15:17 -0400
Re: C struct syntax allowance by usage Robert Wessel <robertwessel2@yahoo.com> - 2015-10-25 13:47 -0500
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 23:46 +0000
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-25 07:05 +0000
Re: C struct syntax allowance by usage James Kuyper <jameskuyper@verizon.net> - 2015-10-25 10:59 -0400
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:24 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-25 11:13 -0700
Re: C struct syntax allowance by usage glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 02:58 +0000
Re: C struct syntax allowance by usage supercat@casperkitty.com - 2015-10-24 11:02 -0700
Re: C struct syntax allowance by usage Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-10-24 20:13 +0200
Re: C struct syntax allowance by usage Keith Thompson <kst-u@mib.org> - 2015-10-24 12:45 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-24 10:30 +1300
Re: C struct syntax allowance by usage Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-19 12:05 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 15:57 -0700
Re: C struct syntax allowance by usage Bartc <bc@freeuk.com> - 2015-10-17 00:54 +0100
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 17:19 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:33 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 19:41 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 15:58 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:10 -0700
Re: C struct syntax allowance by usage Ian Collins <ian-news@hotmail.com> - 2015-10-17 16:49 +1300
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:59 -0700
Re: C struct syntax allowance by usage David Brown <david.brown@hesbynett.no> - 2015-10-18 11:32 +0200
Re: C struct syntax allowance by usage Richard Damon <Richard@Damon-Family.org> - 2015-10-16 23:15 -0400
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:34 -0700
Re: C struct syntax allowance by usage "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-10-16 20:45 -0700
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 13:29 -0700 |
| Subject | C struct syntax allowance by usage |
| Message-ID | <40812880-9a99-48c6-9d67-6d6a98be00e1@googlegroups.com> |
Has there ever been a syntax allowance in C which would allow
something like this to be created without a reference to the
member object?
01: struct SAbc
02: {
03: int i;
04: float f;
05: };
06:
07: int main(int argc, char* argv[])
08: {
09: struct SAbc abc;
10:
11: abc = 5;
12: abc = 2.0f;
13:
14: printf("%d, %f\n", abc, abc);
15: }
Where the meaning of the above is actually understood by the
language/compiler to be these members, because there is only
one of each type in the structure:
11: abc.i = 5;
12: abc.f = 2.0f;
13:
14: printf("%d, %f\n", abc.i, abc.f);
The language/compiler should be able to discern by usage
which member is needed, so that it doesn't require the
member reference by name. Has this ever been part of the
C programming language? Or is it part of C++ or C#?
Best regards,
Rick C. Hodgin
[toc] | [next] | [standalone]
| From | Siri Cruz <chine.bleu@yahoo.com> |
|---|---|
| Date | 2015-10-16 13:47 -0700 |
| Message-ID | <chine.bleu-B24599.13474016102015@88-209-239-213.giganet.hu> |
| In reply to | #73070 |
In article <40812880-9a99-48c6-9d67-6d6a98be00e1@googlegroups.com>, "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > Where the meaning of the above is actually understood by the > language/compiler to be these members, because there is only > one of each type in the structure: > > 11: abc.i = 5; > 12: abc.f = 2.0f; abc.i = 2.0 and abc.f = 5 are valid assignments, so this introduce an ambiguity for the rather dubious benefit of occasionally dropping a '.' and some letters. Is typing really that onerous? -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' When is a Kenyan not a Kenyan? When he's a Canadian. That's People's Commissioner Siri Cruz now. Punch!
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 14:12 -0700 |
| Message-ID | <0a595d36-aab4-4983-9504-9fbf7c287985@googlegroups.com> |
| In reply to | #73073 |
On Friday, October 16, 2015 at 3:47:51 PM UTC-5, Siri Cruz wrote:
> abc.i = 2.0 and abc.f = 5 are valid assignments, so this introduce an ambiguity
> for the rather dubious benefit of occasionally dropping a '.' and some letters.
> Is typing really that onerous?
Being able to have multiple primitives in a struct wouldn't be all that useful,
but if C ever defined a syntax for defining bit-field layout I can imagine
some definite uses for being able to have a "default member" in a struct that
held such a bitfield. For example, if
struct __aligned BIG_ENDIAN_32 {
uint8_t b0,b1,b2,b3;
default signed value : 8(b0.0) : 8(b1.0) : 8(b2.0) : 8(b3.0);
};
meant that "value" was supposed to have its eight bottom bits come from
the bottom 8 bits of b3, the next higher 8 bits come from the bottom 8
bits of b2, then b1, then b0, having a means by which one could use such
a thing with the same syntax as any other numeric type [e.g. the default
keyword as used above] could be very useful when trying to write portable
code (a compiler for a big-endian 32-bit system could treat an increment
of a struct like an integer increment; one for a little-endian 32-bit
system could fetch a word, byte-swap it, do the increment, byte-swap
back, and store a word).
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-16 22:15 +0100 |
| Message-ID | <mvrp94$p8a$1@dont-email.me> |
| In reply to | #73070 |
On 16/10/2015 21:29, Rick C. Hodgin wrote:
> Has there ever been a syntax allowance in C which would allow
> something like this to be created without a reference to the
> member object?
>
> 01: struct SAbc
> 02: {
> 03: int i;
> 04: float f;
> 05: };
> 06:
> 07: int main(int argc, char* argv[])
> 08: {
> 09: struct SAbc abc;
> 10:
> 11: abc = 5;
> 12: abc = 2.0f;
> 13:
> 14: printf("%d, %f\n", abc, abc);
> 15: }
>
> Where the meaning of the above is actually understood by the
> language/compiler to be these members, because there is only
> one of each type in the structure:
>
> 11: abc.i = 5;
> 12: abc.f = 2.0f;
> 13:
> 14: printf("%d, %f\n", abc.i, abc.f);
>
> The language/compiler should be able to discern by usage
> which member is needed,
What's the purpose?
so that it doesn't require the
> member reference by name. Has this ever been part of the
> C programming language? Or is it part of C++ or C#?
I'd imagine those last two could have ways of overloading the assignment
operator for when the left-hand-side is a struct. But you might have to
specify every combination for each specific struct and each kind of
memory, unless there is some complicated solution involving macros and
templates.
I can still see plenty of problems, eg what happens when there are two
members with the same type? What about 'int' and 'short' member types,
but a rhs of 0?
What about about a nested version where one one member of a Sabc is also
a struct that has member types int and float; would it still be possible
to write abc = 5 and instead write several levels deep into the struct?
(I could go on, because my POV is that of someone who might have to
implement it! This stuff cannot be ambiguous or ill-defined.)
You also lose the ability to pick up an incorrect assignment of a scalar
to a struct.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 14:38 -0700 |
| Message-ID | <18125266-d647-4cd1-9502-363283e67765@googlegroups.com> |
| In reply to | #73081 |
On Friday, October 16, 2015 at 5:15:25 PM UTC-4, Bart wrote:
> On 16/10/2015 21:29, Rick C. Hodgin wrote:
> > Has there ever been a syntax allowance in C which would allow
> > something like this to be created without a reference to the
> > member object?
> >
> > 01: struct SAbc
> > 02: {
> > 03: int i;
> > 04: float f;
> > 05: };
> > 06:
> > 07: int main(int argc, char* argv[])
> > 08: {
> > 09: struct SAbc abc;
> > 10:
> > 11: abc = 5;
> > 12: abc = 2.0f;
> > 13:
> > 14: printf("%d, %f\n", abc, abc);
> > 15: }
> >
> > Where the meaning of the above is actually understood by the
> > language/compiler to be these members, because there is only
> > one of each type in the structure:
> >
> > 11: abc.i = 5;
> > 12: abc.f = 2.0f;
> > 13:
> > 14: printf("%d, %f\n", abc.i, abc.f);
> >
> > The language/compiler should be able to discern by usage
> > which member is needed,
>
> What's the purpose?
Being able to combine two or more things which are related into a
single thing, and then referencing their internal components as
through the combination. An example might be:
struct SLiver { ... };
struct SHeart { ... };
struct SBrain { ... };
struct SBody
{
struct SLiver liver;
struct SHeart heart;
struct SBrain brain;
};
void function(void)
{
struct SBody rick;
scan_liver(&rick);
scan_heart(&rick);
scan_brain(&rick); // Returns NULL LOL! :-)
}
To be able to reference the bigger thing and have it automatically
reference the sub-things by context.
> so that it doesn't require the
> > member reference by name. Has this ever been part of the
> > C programming language? Or is it part of C++ or C#?
>
> I'd imagine those last two could have ways of overloading the assignment
> operator for when the left-hand-side is a struct. But you might have to
> specify every combination for each specific struct and each kind of
> memory, unless there is some complicated solution involving macros and
> templates.
>
> I can still see plenty of problems, eg what happens when there are two
> members with the same type? What about 'int' and 'short' member types,
> but a rhs of 0?
It would error out. It would say that it's ambiguous and requires the
explicit member name.
> What about about a nested version where one one member of a Sabc is also
> a struct that has member types int and float; would it still be possible
> to write abc = 5 and instead write several levels deep into the struct?
No. It would only work for unique members throughout, however you do
bring up an interesting extension.
Consider:
struct SLeg { ... };
struct SLegs
{
struct SLeg right;
struct SLeg left;
};
struct SBody
{
struct SLegs legs;
};
void function(void)
{
struct SBody rick;
scan_leg(&rick..right);
scan_leg(&rick..left);
}
In this case, I wouldn't need to name the intermediate members, but
only indicate the .. so that it auto-searches the child members to
determine which one has a named member, and if only one is found it
would use that.
> (I could go on, because my POV is that of someone who might have to
> implement it! This stuff cannot be ambiguous or ill-defined.)
I am looking at an integrated toolset where the GUI would auto-fill
in that information on-demand. Flip a setting, and it automatically
inserts all of the missing members for display, but they're not
actually needed because the references are explicit.
Also, upon refactoring, it would be able to determine where the
types are needed should I suddenly add a second brain, for example,
:-) then it would allow for that type of refactoring to auto-insert
the old name before the new one is considered valid.
> You also lose the ability to pick up an incorrect assignment of a
> scalar to a struct.
How so?
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-17 10:32 +0100 |
| Message-ID | <mvt4f4$fah$1@dont-email.me> |
| In reply to | #73090 |
On 16/10/2015 22:38, Rick C. Hodgin wrote: > On Friday, October 16, 2015 at 5:15:25 PM UTC-4, Bart wrote: >> (I could go on, because my POV is that of someone who might have to >> implement it! This stuff cannot be ambiguous or ill-defined.) > > I am looking at an integrated toolset where the GUI would auto-fill > in that information on-demand. Flip a setting, and it automatically > inserts all of the missing members for display, but they're not > actually needed because the references are explicit. I think that's a better approach than having it part of the language. Let the IDE show the possible .member names or even let it choose the best match based on type. But the result source will have an actual .member name filled in so that the code remains readable (and people don't wonder why you're working with entire structs all over the place). An alternative if you feel the need to have it as part of the language, is to add it as special syntax: a = foo.auto; The 'auto' or whatever special name is chosen, is replaced by the best match member of foo. Then the reader will have a better idea of what's going on. (I use a similar idea here: a = cast(b); where this simply casts b to whatever type a needs. There is less need to know what type b is, and there is less maintenance.) But I think there will usually be too much ambiguity for a general purpose language feature: foo = foo; will presumably be ambiguous. But: foo = foo.i; // or: foo.i = foo; won't be. But they look odd. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-17 05:26 -0700 |
| Message-ID | <991f4469-3a34-417a-bdbc-4105908c2920@googlegroups.com> |
| In reply to | #73143 |
Bart wrote: > But I think there will usually be too much > ambiguity for a general purpose language > feature: > foo = foo; > will presumably be ambiguous. But: > foo = foo.i; // or: > foo.i = foo; > won't be. But they look odd. As I say, its purpose is for what it would be used for, and not for other things. CAlive will add this, and the .. feature. They both have utility, even if they are not universally applicable. And as a nod to your foo.auto idea, I will also allow foo.. to be used. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-17 14:17 +0100 |
| Message-ID | <87d1wdprb0.fsf@bsb.me.uk> |
| In reply to | #73144 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > CAlive will add this, and the .. feature. They both > have utility, even if they are not universally applicable. > > And as a nod to your foo.auto idea, I will also allow > foo.. to be used. What technical criteria, if any, would you use to exclude a feature from CAlive, if someone could show that it has utility? I say "technical" because features can be excluded for other, more arbitrary, kinds of reason such as not having time to implement them, or not being able to implement them. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-17 06:48 -0700 |
| Message-ID | <1745264a-2e15-493c-b44c-ffc5f4a0b24e@googlegroups.com> |
| In reply to | #73145 |
On Saturday, October 17, 2015 at 9:18:12 AM UTC-4, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > <snip> > > CAlive will add this, and the .. feature. They both > > have utility, even if they are not universally applicable. > > > > And as a nod to your foo.auto idea, I will also allow > > foo.. to be used. > > What technical criteria, if any, would you use to exclude a feature from > CAlive, if someone could show that it has utility? I can't think of any off the top of my head, except aspects relating to C's allowance of things like int being any size so long as it's at least 16 bits. I would never stand for that, except in the areas of backwards compatibility. In all things moving forward I would declare hard-and-fast forms which are the standard CAlive, and then allow for extensions which violate the standard per instance use. Most of my reasons I would allow or disallow something in /my/ programming language would relate to my personal opinion on how code should be written. But, ideas like Bart's "auto" feature (implemented as a trailing "..") are welcomed and become part of it. In fact, I think it's an absolutely brilliant suggestion, and I am very happy to implement it. If the ".." weren't already named "auto-resolve", I would consider calling it "bart," as in, "With CAlive you can bart your variables with a trailing '..' to have the compiler resolve by type the member of a parent container. This process is referred to as barting. You may see the error: 'Ambiguous reference, unable to bart.'" :-) As it is though, I'll just keep the name auto-resolve. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-10-17 19:01 +0100 |
| Message-ID | <87twppnzlp.fsf@bsb.me.uk> |
| In reply to | #73146 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Saturday, October 17, 2015 at 9:18:12 AM UTC-4, Ben Bacarisse wrote: >> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: >> <snip> >> > CAlive will add this, and the .. feature. They both >> > have utility, even if they are not universally applicable. >> > >> > And as a nod to your foo.auto idea, I will also allow >> > foo.. to be used. >> >> What technical criteria, if any, would you use to exclude a feature from >> CAlive, if someone could show that it has utility? > > I can't think of any off the top of my head, Then you must hope to avoid hearing about as many useful language features as possible. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-17 11:17 -0700 |
| Message-ID | <e19da21a-c7a1-4217-aba0-a0916e97db9b@googlegroups.com> |
| In reply to | #73151 |
Ben Bacarisse wrote:
> > I can't think of any off the top of my head,
> Then you must hope to avoid hearing about as
> many useful language features as possible.
I don't mind hearing ideas. Between the lot of us,
we'll sort out CAlive. :-)
In God's sight, we've come together.
We've come together to help each other.
Let's grow this project up ... together!
In service and Love to The Lord, forever!
I just hope others will come on board to help with
development at some point.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-16 15:28 -0700 |
| Message-ID | <1054a0bd-b310-42d6-a746-bde063310246@googlegroups.com> |
| In reply to | #73081 |
On Friday, October 16, 2015 at 4:15:25 PM UTC-5, Bart wrote:
> What's the purpose?
A real-world example of a place where I'd like such a feature is when
writing code for one of Atmel's ARM controllers. A little snippet from
the vendor-supplied header [comments on each line deleted to keep line
length reasonable]
/* From one of Atmel's include files */
typedef union {
struct {
uint32_t PINMASK:16;
uint32_t PMUXEN:1;
uint32_t INEN:1;
uint32_t PULLEN:1;
uint32_t :3;
uint32_t DRVSTR:1;
uint32_t :1;
uint32_t PMUX:4;
uint32_t WRPMUX:1;
uint32_t :1;
uint32_t WRPINCFG:1;
uint32_t HWSEL:1;
} bit;
uint32_t reg;
} PORT_WRCONFIG_Type;
Every single I/O register in the chip is defined similarly, which means that
it's necessary to attach ".reg" to every single I/O access (there are a few
cases where accessing as bit fields will actually work, and might actually
be nice, and using ".reg" consistently is better than sometimes using it and
sometimes not, but it would really be a lot nicer if there were a way of
using bitfield accesses in places where it would actually work(*) but
not have to use ".reg" everywhere.
(*) It seems that even when accessing an object like the above using a
volatile-qualified pointer, gcc heeds the volatile qualifier when
accessing "reg", but not when accessing bitfield members. I think
the C Standard is silent on how bitfields should interact with
"volatile", so GCC's behavior there is probably standards-compliant
even though it would be helpful to have the compiler honor volatile
semantics when reading and squawk when writing a bitfield of a
volatile object.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-17 01:41 +0100 |
| Message-ID | <mvs5cf$281$1@dont-email.me> |
| In reply to | #73102 |
On 16/10/2015 23:28, supercat@casperkitty.com wrote:
> On Friday, October 16, 2015 at 4:15:25 PM UTC-5, Bart wrote:
>> What's the purpose?
>
> A real-world example of a place where I'd like such a feature is when
> writing code for one of Atmel's ARM controllers. A little snippet from
> the vendor-supplied header [comments on each line deleted to keep line
> length reasonable]
>
> /* From one of Atmel's include files */
>
> typedef union {
> struct {
> uint32_t PINMASK:16;
> uint32_t PMUXEN:1;
> uint32_t INEN:1;
> uint32_t PULLEN:1;
> uint32_t :3;
> uint32_t DRVSTR:1;
> uint32_t :1;
> uint32_t PMUX:4;
> uint32_t WRPMUX:1;
> uint32_t :1;
> uint32_t WRPINCFG:1;
> uint32_t HWSEL:1;
> } bit;
> uint32_t reg;
> } PORT_WRCONFIG_Type;
>
> Every single I/O register in the chip is defined similarly, which means that
> it's necessary to attach ".reg" to every single I/O access
I'm not sure how Rick's feature works with unions, but you don't need to
get involved with types.
What I think you want here is a top-level anonymous union:
union {
PORT_BITS bit;
uint32_t reg;
};
Here, you have a variable called 'bit', and one called 'reg', which
share the same memory location (and happen to be the same size):
reg = 0x70028224;
So you still have to write 'reg' everywhere that you set all these 32
bits at once. But the 'reg' doesn't have to be a field of something else.
BTW C doesn't allow this, in case you thought it did. I've used this
feature elsewhere, so there is a precedent.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 18:23 -0700 |
| Message-ID | <b6bc650a-f254-40b8-8cfd-5ded7a1422b5@googlegroups.com> |
| In reply to | #73121 |
On Friday, October 16, 2015 at 8:41:58 PM UTC-4, Bart wrote:
> On 16/10/2015 23:28, supercat@casperkitty.com wrote:
> > On Friday, October 16, 2015 at 4:15:25 PM UTC-5, Bart wrote:
> >> What's the purpose?
> >
> > A real-world example of a place where I'd like such a feature is when
> > writing code for one of Atmel's ARM controllers. A little snippet from
> > the vendor-supplied header [comments on each line deleted to keep line
> > length reasonable]
> >
> > /* From one of Atmel's include files */
> >
> > typedef union {
> > struct {
> > uint32_t PINMASK:16;
> > uint32_t PMUXEN:1;
> > uint32_t INEN:1;
> > uint32_t PULLEN:1;
> > uint32_t :3;
> > uint32_t DRVSTR:1;
> > uint32_t :1;
> > uint32_t PMUX:4;
> > uint32_t WRPMUX:1;
> > uint32_t :1;
> > uint32_t WRPINCFG:1;
> > uint32_t HWSEL:1;
> > } bit;
> > uint32_t reg;
> > } PORT_WRCONFIG_Type;
> >
> > Every single I/O register in the chip is defined similarly, which means that
> > it's necessary to attach ".reg" to every single I/O access
>
> I'm not sure how Rick's feature works with unions...
In CAlive, it works with all named members going down through every
child reference, into grandchild references, and great-grandchild
references, and so on.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 11:04 +0200 |
| Message-ID | <mvvn7m$mmu$1@dont-email.me> |
| In reply to | #73102 |
On 17/10/15 00:28, supercat@casperkitty.com wrote:
> On Friday, October 16, 2015 at 4:15:25 PM UTC-5, Bart wrote:
>> What's the purpose?
>
> A real-world example of a place where I'd like such a feature is when
> writing code for one of Atmel's ARM controllers. A little snippet from
> the vendor-supplied header [comments on each line deleted to keep line
> length reasonable]
>
> /* From one of Atmel's include files */
>
> typedef union {
> struct {
> uint32_t PINMASK:16;
> uint32_t PMUXEN:1;
> uint32_t INEN:1;
> uint32_t PULLEN:1;
> uint32_t :3;
> uint32_t DRVSTR:1;
> uint32_t :1;
> uint32_t PMUX:4;
> uint32_t WRPMUX:1;
> uint32_t :1;
> uint32_t WRPINCFG:1;
> uint32_t HWSEL:1;
> } bit;
> uint32_t reg;
> } PORT_WRCONFIG_Type;
>
> Every single I/O register in the chip is defined similarly, which means that
> it's necessary to attach ".reg" to every single I/O access (there are a few
> cases where accessing as bit fields will actually work, and might actually
> be nice, and using ".reg" consistently is better than sometimes using it and
> sometimes not, but it would really be a lot nicer if there were a way of
> using bitfield accesses in places where it would actually work(*) but
> not have to use ".reg" everywhere.
>
> (*) It seems that even when accessing an object like the above using a
> volatile-qualified pointer, gcc heeds the volatile qualifier when
> accessing "reg", but not when accessing bitfield members. I think
> the C Standard is silent on how bitfields should interact with
> "volatile", so GCC's behavior there is probably standards-compliant
> even though it would be helpful to have the compiler honor volatile
> semantics when reading and squawk when writing a bitfield of a
> volatile object.
>
Most people manage to use the bitfields quite happily in such
circumstances. The C standards are more than a little vague about what
constitutes a "volatile access" (it's implementation defined, IIRC). But
gcc follows the same rules here as every other compiler I have seen
regarding structs and other aggregate types - as long as there is at
least one "volatile" in the chain from the innermost identifier through
to the outermost, then the access is volatile.
There is, however, a well-known issue regarding access to small volatile
bitfields in registers like this. When accessing a field such as PMUXEN
above, the code is shorter and faster if the compiler uses 8-bit access
rather than 32-bit access - so that is what gcc used to do. That would
be fine for many platforms, but causes trouble for most ARM devices. In
gcc 4.6, a flag "-fstrict-volatile-bitfields" was introduced (and made
default on the ARM but not on platforms without this problem) that means
that the bitfields are accessed using reads and writes of the same width
as their declared type.
So if you are using gcc 4.5 or before, you should probably upgrade - and
then you can use bitfields happily, safely and efficiently.
(It is also common practice in definitions like the one above to omit
the "bit" in the struct - then the bitfield fields can be accessed
without the "bit".)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 10:31 +1300 |
| Message-ID | <d8d8l6Fp0vsU1@mid.individual.net> |
| In reply to | #73070 |
Rick C. Hodgin wrote:
> Has there ever been a syntax allowance in C which would allow
> something like this to be created without a reference to the
> member object?
>
> 01: struct SAbc
> 02: {
> 03: int i;
> 04: float f;
> 05: };
> 06:
> 07: int main(int argc, char* argv[])
> 08: {
> 09: struct SAbc abc;
> 10:
> 11: abc = 5;
> 12: abc = 2.0f;
> 13:
> 14: printf("%d, %f\n", abc, abc);
> 15: }
>
> Where the meaning of the above is actually understood by the
> language/compiler to be these members, because there is only
> one of each type in the structure:
If you want C++, you know where to find it....
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 14:38 -0700 |
| Message-ID | <5cc39a78-02b1-4907-b2cd-66d4f8094c89@googlegroups.com> |
| In reply to | #73088 |
On Friday, October 16, 2015 at 5:31:27 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > Has there ever been a syntax allowance in C which would allow
> > something like this to be created without a reference to the
> > member object?
> >
> > 01: struct SAbc
> > 02: {
> > 03: int i;
> > 04: float f;
> > 05: };
> > 06:
> > 07: int main(int argc, char* argv[])
> > 08: {
> > 09: struct SAbc abc;
> > 10:
> > 11: abc = 5;
> > 12: abc = 2.0f;
> > 13:
> > 14: printf("%d, %f\n", abc, abc);
> > 15: }
> >
> > Where the meaning of the above is actually understood by the
> > language/compiler to be these members, because there is only
> > one of each type in the structure:
>
> If you want C++, you know where to find it....
Does C++ offer this ability? FWIW, I've never heard of it before.
If it does, that's great.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 11:14 +1300 |
| Message-ID | <d8db67Fp0vsU2@mid.individual.net> |
| In reply to | #73091 |
Rick C. Hodgin wrote:
> On Friday, October 16, 2015 at 5:31:27 PM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>> Has there ever been a syntax allowance in C which would allow
>>> something like this to be created without a reference to the
>>> member object?
>>>
>>> 01: struct SAbc
>>> 02: {
>>> 03: int i;
>>> 04: float f;
>>> 05: };
>>> 06:
>>> 07: int main(int argc, char* argv[])
>>> 08: {
>>> 09: struct SAbc abc;
>>> 10:
>>> 11: abc = 5;
>>> 12: abc = 2.0f;
>>> 13:
>>> 14: printf("%d, %f\n", abc, abc);
>>> 15: }
>>>
>>> Where the meaning of the above is actually understood by the
>>> language/compiler to be these members, because there is only
>>> one of each type in the structure:
>>
>> If you want C++, you know where to find it....
>
> Does C++ offer this ability? FWIW, I've never heard of it before.
> If it does, that's great.
With a little help from the programmer....
struct Foo
{
int i;
double f;
Foo& operator=( int v ) { i = v; return *this; }
Foo& operator=( double v ) { f = v; return *this; }
};
int main()
{
Foo foo;
foo = 42;
foo = 21.21;
printf( "%d %f\n", foo.i, foo.f );
return 0;
}
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 15:25 -0700 |
| Message-ID | <b8ccb2bf-d3f9-4a7f-b91c-a305d89c6001@googlegroups.com> |
| In reply to | #73097 |
On Friday, October 16, 2015 at 6:14:41 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > Does C++ offer this ability? FWIW, I've never heard of it before.
> > If it does, that's great.
>
> With a little help from the programmer....
>
> struct Foo
> {
> int i;
> double f;
>
> Foo& operator=( int v ) { i = v; return *this; }
> Foo& operator=( double v ) { f = v; return *this; }
> };
>
> int main()
> {
> Foo foo;
> foo = 42;
> foo = 21.21;
>
> printf( "%d %f\n", foo.i, foo.f );
Still had to reference the member names here.
> return 0;
> }
FWIW, I'd rather stop programming and become a farmer than inflict
that kind of syntax on all developers who would use my language,
and this ability.
I do not use C++ for those very reasons. It might be a powerful
language and extension to C, offering things that are amazing ...
but it comes at steep price. It's also horrid on the eyes.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 11:31 +1300 |
| Message-ID | <d8dc5cFp0vsU4@mid.individual.net> |
| In reply to | #73099 |
Rick C. Hodgin wrote:
> On Friday, October 16, 2015 at 6:14:41 PM UTC-4, Ian Collins wrote:
>> Rick C. Hodgin wrote:
>>> Does C++ offer this ability? FWIW, I've never heard of it before.
>>> If it does, that's great.
>>
>> With a little help from the programmer....
>>
>> struct Foo
>> {
>> int i;
>> double f;
>>
>> Foo& operator=( int v ) { i = v; return *this; }
>> Foo& operator=( double v ) { f = v; return *this; }
>> };
>>
>> int main()
>> {
>> Foo foo;
>> foo = 42;
>> foo = 21.21;
>>
>> printf( "%d %f\n", foo.i, foo.f );
>
> Still had to reference the member names here.
As did your OP.
>
>> return 0;
>> }
>
> FWIW, I'd rather stop programming and become a farmer than inflict
> that kind of syntax on all developers who would use my language,
> and this ability.
>
> I do not use C++ for those very reasons. It might be a powerful
> language and extension to C, offering things that are amazing ...
> but it comes at steep price. It's also horrid on the eyes.
If ugliness in one place leads to elegance in many, I'm all for it.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web