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 | 8 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 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 15:58 +1300 |
| Message-ID | <d8drqdFp0vsU8@mid.individual.net> |
| In reply to | #73126 |
Rick C. Hodgin wrote:
> On Friday, October 16, 2015 at 10:33:57 PM UTC-4, Ian Collins wrote:
>> Bartc wrote:
>>> On 16/10/2015 23:57, Rick C. Hodgin wrote:
>>>> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
>>>>> 01: struct SAbc
>>>>> 02: {
>>>>> 03: int i;
>>>>> 04: float f;
>>>
>>>>> 09: struct SAbc abc;
>>>>> 10:
>>>>> 11: abc = 5;
>>>>> 12: abc = 2.0f;
>>>
>>>> 14: printf("%d, %f\n", abc);
>>>
>>> This is not a satisfactory feature. For a start, it is very restrictive
>>> as it will only work with certain combinations of types with the struct.
>>
>> Indeed. A reasonable example would be something like:
>>
>> struct Foo { int i; short s; };
>>
>> Foo foo;
>>
>> foo = 42; // Which member gets the assignment?
>
> Neither. The target cannot be resolved into a single entity given
> that 42 could apply to both int and short. It would report an
> "ambiguous assignment, unable to auto-resolve" error.
Which could lead to a shed load of errors if at some point you decide
SAbc::f should really be a integer type rather than a float!
> However, these would both work:
>
> foo = (int)42;
> foo = (short)42;
Which defeats the code simplification objective.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 20:10 -0700 |
| Message-ID | <73147d83-f1b4-4c26-8ebf-45226d3b868c@googlegroups.com> |
| In reply to | #73128 |
On Friday, October 16, 2015 at 10:58:31 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Friday, October 16, 2015 at 10:33:57 PM UTC-4, Ian Collins wrote:
> >> Bartc wrote:
> >>> On 16/10/2015 23:57, Rick C. Hodgin wrote:
> >>>> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
> >>>>> 01: struct SAbc
> >>>>> 02: {
> >>>>> 03: int i;
> >>>>> 04: float f;
> >>>
> >>>>> 09: struct SAbc abc;
> >>>>> 10:
> >>>>> 11: abc = 5;
> >>>>> 12: abc = 2.0f;
> >>>
> >>>> 14: printf("%d, %f\n", abc);
> >>>
> >>> This is not a satisfactory feature. For a start, it is very restrictive
> >>> as it will only work with certain combinations of types with the struct.
> >>
> >> Indeed. A reasonable example would be something like:
> >>
> >> struct Foo { int i; short s; };
> >>
> >> Foo foo;
> >>
> >> foo = 42; // Which member gets the assignment?
> >
> > Neither. The target cannot be resolved into a single entity given
> > that 42 could apply to both int and short. It would report an
> > "ambiguous assignment, unable to auto-resolve" error.
>
> Which could lead to a shed load of errors if at some point you decide
> SAbc::f should really be a integer type rather than a float!
Have you read my replies in this thread? I have indicated there would
be refactoring abilities in the GUI editor / IDE which would allow for
these things to be changed in appropriate context. I cited the existing
Visual Studio add-on tool called Visual Assist X, which has the ability
today to change the C++ prototype definitions with initialized params
should you later decide to un-initialize one of them.
> > However, these would both work:
> >
> > foo = (int)42;
> > foo = (short)42;
>
> Which defeats the code simplification objective.
You and Bart are both looking at silly applications of fundamental
types which may intrude atop other fundamental types. While there
may be some utility there in storing fundamental types, my goals
are more for structs or classes, which would be unique and distinct
as by their storage within the larger outer container.
Simplification comes in the form of my example above where I use
the SBody struct which contained sub-struct members SLiver, SHeart,
SBrain, etc. I assigned "SBody rick" and then was able to use
only "rick" in context rather than rick.brain or rick.heart, etc.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-10-17 16:49 +1300 |
| Message-ID | <d8duqcFrihmU1@mid.individual.net> |
| In reply to | #73131 |
Rick C. Hodgin wrote: > On Friday, October 16, 2015 at 10:58:31 PM UTC-4, Ian Collins wrote: >> Rick C. Hodgin wrote: >>> Neither. The target cannot be resolved into a single entity given >>> that 42 could apply to both int and short. It would report an >>> "ambiguous assignment, unable to auto-resolve" error. >> >> Which could lead to a shed load of errors if at some point you decide >> SAbc::f should really be a integer type rather than a float! > > Have you read my replies in this thread? I have indicated there would > be refactoring abilities in the GUI editor / IDE which would allow for > these things to be changed in appropriate context. I cited the existing > Visual Studio add-on tool called Visual Assist X, which has the ability > today to change the C++ prototype definitions with initialized params > should you later decide to un-initialize one of them. You are biting off an awful lot... >>> However, these would both work: >>> >>> foo = (int)42; >>> foo = (short)42; >> >> Which defeats the code simplification objective. > > You and Bart are both looking at silly applications of fundamental > types which may intrude atop other fundamental types. While there > may be some utility there in storing fundamental types, my goals > are more for structs or classes, which would be unique and distinct > as by their storage within the larger outer container. Well you can't blame us when you used fundamental types in your example! > Simplification comes in the form of my example above where I use > the SBody struct which contained sub-struct members SLiver, SHeart, > SBrain, etc. I assigned "SBody rick" and then was able to use > only "rick" in context rather than rick.brain or rick.heart, etc. Conceptually that makes little sense. You aren't a liver, so writing rick = aLiver; is just wrong in so many ways. Believe me when I say I'm writing this having seen such hideous constructs used in novice C++ code. Just because something can be done doesn't mean it should! The only legitimate use for such code is for implementing an "anything" type generic object. I've used it for JSON objects that can be initialised or assigned from and converted back to any fundamental or JSON type. That use case does make sense, others do not. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 20:59 -0700 |
| Message-ID | <2b25b8c6-8a2d-466b-afd4-44cc29479c06@googlegroups.com> |
| In reply to | #73137 |
On Friday, October 16, 2015 at 11:49:44 PM UTC-4, Ian Collins wrote:
> Rick C. Hodgin wrote:
> > On Friday, October 16, 2015 at 10:58:31 PM UTC-4, Ian Collins wrote:
> >> Rick C. Hodgin wrote:
>
> >>> Neither. The target cannot be resolved into a single entity given
> >>> that 42 could apply to both int and short. It would report an
> >>> "ambiguous assignment, unable to auto-resolve" error.
> >>
> >> Which could lead to a shed load of errors if at some point you decide
> >> SAbc::f should really be a integer type rather than a float!
> >
> > Have you read my replies in this thread? I have indicated there would
> > be refactoring abilities in the GUI editor / IDE which would allow for
> > these things to be changed in appropriate context. I cited the existing
> > Visual Studio add-on tool called Visual Assist X, which has the ability
> > today to change the C++ prototype definitions with initialized params
> > should you later decide to un-initialize one of them.
>
> You are biting off an awful lot...
>
> >>> However, these would both work:
> >>>
> >>> foo = (int)42;
> >>> foo = (short)42;
> >>
> >> Which defeats the code simplification objective.
> >
> > You and Bart are both looking at silly applications of fundamental
> > types which may intrude atop other fundamental types. While there
> > may be some utility there in storing fundamental types, my goals
> > are more for structs or classes, which would be unique and distinct
> > as by their storage within the larger outer container.
>
> Well you can't blame us when you used fundamental types in your example!
I used those types as a simple example to ask if that ability ever
existed in C. I also then immediately thereafter upon inquiry used
examples which had structs.
My actual goal for this is encapsulation in a container object, and
I have considered creating a container for that express purpose, one
which doesn't auto-resolve inside of structs or unions unless they
are braced within something called "container," and if so, then it
will auto-resolve. But, I don't think that's necessary and am, for
now, content to leave it a full language feature.
> > Simplification comes in the form of my example above where I use
> > the SBody struct which contained sub-struct members SLiver, SHeart,
> > SBrain, etc. I assigned "SBody rick" and then was able to use
> > only "rick" in context rather than rick.brain or rick.heart, etc.
>
> Conceptually that makes little sense. You aren't a liver, so writing
>
> rick = aLiver;
>
> is just wrong in so many ways.
Then use rick.liver = aLiver. And in the cases where you want to
use the example like I did above, and if it makes more sense to
use the auto-resolve form, then do so:
scan_liver(&rick);
Rather than:
scan_liver(&rick.liver);
The intent is already clear there in the function name, so why the
need for replication? In this case, it would be clearer to use
just the identifier which makes it unique "&rick" instead of "&ian".
> Believe me when I say I'm writing this having seen such hideous
> constructs used in novice C++ code. Just because something can be done
> doesn't mean it should!
>
> The only legitimate use for such code is for implementing an "anything"
> type generic object. I've used it for JSON objects that can be
> initialised or assigned from and converted back to any fundamental or
> JSON type. That use case does make sense, others do not.
>
> --
> Ian Collins
I doubt you'll ever use CAlive, Ian, so it's a non-issue for both of us.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-10-18 11:32 +0200 |
| Message-ID | <mvvosb$s89$1@dont-email.me> |
| In reply to | #73138 |
On 17/10/15 05:59, Rick C. Hodgin wrote:
> On Friday, October 16, 2015 at 11:49:44 PM UTC-4, Ian Collins wrote:
>> Conceptually that makes little sense. You aren't a liver, so writing
>>
>> rick = aLiver;
>>
>> is just wrong in so many ways.
>
> Then use rick.liver = aLiver. And in the cases where you want to
> use the example like I did above, and if it makes more sense to
> use the auto-resolve form, then do so:
>
> scan_liver(&rick);
>
> Rather than:
>
> scan_liver(&rick.liver);
>
> The intent is already clear there in the function name, so why the
> need for replication? In this case, it would be clearer to use
> just the identifier which makes it unique "&rick" instead of "&ian".
For C, you can happily write:
scan_liver(&rick);
scan_heart(&rick);
scan_brain(&rick);
All you need to do is have your scan_liver function defined such as:
void scan_liver(SBody* body) {
do_scan_liver(&(body->liver));
}
Of course, you can't then also write "scan_liver(&rick.liver)".
If you want to be able to do both, you would have to have some way of
distinguishing between a "body" and a "liver" - perhaps with a type tag
at the beginning of the structure which you took care to initialise
properly when making each object.
Or you could use C++, which handles this easily:
void scan(SBody &body) {
scan(body.liver);
scan(body.heart);
scan(body.breain);
}
void scan(SLiver &liver) {
do_scan_liver(liver);
}
void scan_liver(SLiver &liver) {
do_scan_liver(liver);
}
void scan_liver(SBody &body) {
do_scan_liver(body.liver);
}
Then you can write:
scan_liver(rick);
scan_liver(rick.liver);
scan(rick.liver);
and they will all scan your liver.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-16 23:15 -0400 |
| Message-ID | <c3jUx.25189$gO.5735@fx19.iad> |
| In reply to | #73126 |
On 10/16/15 10:41 PM, Rick C. Hodgin wrote:
> On Friday, October 16, 2015 at 10:33:57 PM UTC-4, Ian Collins wrote:
>> Bartc wrote:
>>> On 16/10/2015 23:57, Rick C. Hodgin wrote:
>>>> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
>>>>> 01: struct SAbc
>>>>> 02: {
>>>>> 03: int i;
>>>>> 04: float f;
>>>
>>>>> 09: struct SAbc abc;
>>>>> 10:
>>>>> 11: abc = 5;
>>>>> 12: abc = 2.0f;
>>>
>>>> 14: printf("%d, %f\n", abc);
>>>
>>> This is not a satisfactory feature. For a start, it is very restrictive
>>> as it will only work with certain combinations of types with the struct.
>>
>> Indeed. A reasonable example would be something like:
>>
>> struct Foo { int i; short s; };
>>
>> Foo foo;
>>
>> foo = 42; // Which member gets the assignment?
>
> Neither. The target cannot be resolved into a single entity given
> that 42 could apply to both int and short. It would report an
> "ambiguous assignment, unable to auto-resolve" error.
>
> However, these would both work:
>
> foo = (int)42;
> foo = (short)42;
>
> Best regards,
> Rick C. Hodgin
>
That really messes up the type system. 42 HAS a type, its int. (You
can't actually write a constant of type short, there is no S suffix like
there is L for long). An actually 'a' has type int in C, so things would
get surprising there too if you had a char member. Same with
foo = foo.s + 1; /* This is an int */
To make this work you are going to need to break so much of the existing
language (and programs that are based on it).
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 20:34 -0700 |
| Message-ID | <e7b1c027-7a9a-4c60-8521-993253f6a072@googlegroups.com> |
| In reply to | #73133 |
On Friday, October 16, 2015 at 11:15:35 PM UTC-4, Richard Damon wrote:
> On 10/16/15 10:41 PM, Rick C. Hodgin wrote:
> > On Friday, October 16, 2015 at 10:33:57 PM UTC-4, Ian Collins wrote:
> >> Bartc wrote:
> >>> On 16/10/2015 23:57, Rick C. Hodgin wrote:
> >>>> On Friday, October 16, 2015 at 4:29:26 PM UTC-4, Rick C. Hodgin wrote:
> >>>>> 01: struct SAbc
> >>>>> 02: {
> >>>>> 03: int i;
> >>>>> 04: float f;
> >>>
> >>>>> 09: struct SAbc abc;
> >>>>> 10:
> >>>>> 11: abc = 5;
> >>>>> 12: abc = 2.0f;
> >>>
> >>>> 14: printf("%d, %f\n", abc);
> >>>
> >>> This is not a satisfactory feature. For a start, it is very restrictive
> >>> as it will only work with certain combinations of types with the struct.
> >>
> >> Indeed. A reasonable example would be something like:
> >>
> >> struct Foo { int i; short s; };
> >>
> >> Foo foo;
> >>
> >> foo = 42; // Which member gets the assignment?
> >
> > Neither. The target cannot be resolved into a single entity given
> > that 42 could apply to both int and short. It would report an
> > "ambiguous assignment, unable to auto-resolve" error.
> >
> > However, these would both work:
> >
> > foo = (int)42;
> > foo = (short)42;
> >
> > Best regards,
> > Rick C. Hodgin
> >
>
> That really messes up the type system. 42 HAS a type, its int. (You
> can't actually write a constant of type short, there is no S suffix like
> there is L for long). An actually 'a' has type int in C, so things would
> get surprising there too if you had a char member. Same with
>
> foo = foo.s + 1; /* This is an int */
>
> To make this work you are going to need to break so much of the existing
> language (and programs that are based on it).
How would it break anything that exists? Everything already uses
explicitly named members in all cases because that's all C allows.
This auto-resolve ability would only work if you were to try to use
their auto-resolve names, and that would only be in new code written
for augmentation to the code which previously existed and compiled
in the old C compilers.
In CAlive, it would be used on the code which it relates to, and
everyone would still be free to use wholly qualified member names
as they must today. But in those cases where you wouldn't need to,
and it might even make the code clearer to not use them, then you
can use those features in CAlive.
In the case of "foo = foo.s + 1;" it would report ambiguity because
the values in use in the expression are different. However, this
would work, "foo = foo.s + (short)1;".
Best regards,
Rick . Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-10-16 20:45 -0700 |
| Message-ID | <884bb1f8-eec8-49d9-916c-d4b9424c6424@googlegroups.com> |
| In reply to | #73134 |
On Friday, October 16, 2015 at 11:35:00 PM UTC-4, Rick C. Hodgin wrote:
> In the case of "foo = foo.s + 1;" it would report ambiguity because
> the values in use in the expression are different.
Actually that's not true. In CAlive this would not be an issue.
It would recognize that "1" is of a general numeric form, and that
because it's used in context with a short, "foo.s + 1" would be
resolved to a short result.
As such, the expression would expand to:
short t = foo.s + (short)1;
foo = t;
And it would auto-resolve properly in this case because of those
steps, and the fact that the "1" is associated through the
expression with a type to which it is compatible.
If would be different with "foo = foo.s + 1.0f;". The 1.0f cannot
be directly resolved to a short, even though it actually could be
by value, it's crossing types from floating point to integer, and
that would be an auto-resolve barrier.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web