Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #75624 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-11-10 09:10 -0800 |
| Last post | 2015-11-10 10:50 -0800 |
| Articles | 20 on this page of 184 — 23 participants |
Back to article view | Back to comp.lang.c
Objective C Alla _ <modelling.data@gmail.com> - 2015-11-10 09:10 -0800
Re: Objective C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-11-10 09:16 -0800
Re: Objective C Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 17:17 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-10 09:32 -0800
Re: Objective C Mark Storkamp <mstorkamp@yahoo.com> - 2015-11-10 11:38 -0600
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-10 12:36 -0500
Re: Objective C Alla _ <modelling.data@gmail.com> - 2015-11-10 11:15 -0800
Re: Objective C Richard Heathfield <rjh@cpax.org.uk> - 2015-11-10 21:51 +0000
Re: Objective C Alla _ <modelling.data@gmail.com> - 2015-11-10 23:13 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-13 16:01 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-14 01:07 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-14 06:26 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-14 22:22 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-14 15:46 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 01:47 +0000
Re: Objective C BartC <bc@freeuk.com> - 2015-11-15 10:43 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-15 13:19 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 15:43 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-15 23:50 +0100
Re: Objective C gazelle@shell.xmission.com (Kenny McCormack) - 2015-11-16 00:05 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-15 19:10 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-16 09:11 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-16 11:57 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 20:38 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-16 13:20 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 22:28 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-16 15:33 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-16 15:56 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 01:43 +0000
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-17 01:21 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-16 18:11 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-16 20:12 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 00:59 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-18 22:46 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 14:25 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-19 07:58 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-19 22:13 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-19 15:29 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 08:44 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-17 01:26 +0000
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-16 21:48 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-16 20:27 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-17 13:58 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-17 12:28 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-18 13:00 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-18 12:31 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-18 16:43 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-18 15:57 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-19 19:09 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-19 19:05 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-20 15:00 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-20 15:30 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 17:11 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-22 15:53 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 13:51 -0600
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-24 12:00 +0000
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-17 10:26 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-17 06:20 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-17 16:41 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-17 12:08 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-17 16:27 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-17 14:55 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-18 13:59 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-18 13:06 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-24 14:24 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-24 15:11 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-26 17:02 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-27 07:26 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-18 21:56 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 02:17 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-22 07:16 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-26 17:11 -0600
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-22 19:09 +0000
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-17 23:28 -0600
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-18 15:33 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-18 23:06 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-19 09:12 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-19 09:25 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-19 21:06 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 13:49 -0800
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 05:01 -0600
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-21 05:09 -0600
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-21 03:31 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-21 17:43 -0600
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-21 16:00 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 01:12 -0600
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:42 +0000
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-27 12:38 -0500
Re: Objective C supercat@casperkitty.com - 2015-11-27 11:09 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-21 19:06 -0500
Re: Objective C supercat@casperkitty.com - 2015-11-21 17:00 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-22 14:44 +0000
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 01:55 -0600
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-22 00:03 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-22 10:18 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 03:21 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-22 10:53 -0500
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-22 20:28 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-22 18:52 -0800
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 11:58 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-23 15:24 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-23 09:46 -0500
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-23 08:13 -0800
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-23 12:04 -0500
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-23 11:52 -0600
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 16:05 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-24 09:09 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-08 08:48 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-12-08 10:40 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 12:34 -0800
Re: Objective C supercat@casperkitty.com - 2015-12-08 10:50 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 12:42 -0800
Re: Objective C supercat@casperkitty.com - 2015-12-09 13:38 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-12-10 19:54 +0000
Re: Objective C David Thompson <dave.thompson2@verizon.net> - 2015-12-06 08:02 -0500
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 14:36 -0800
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-23 00:41 -0600
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 07:39 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-22 14:23 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-17 10:24 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-18 15:40 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-20 16:02 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-21 15:53 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-21 08:58 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-22 22:14 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 03:39 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-23 13:24 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-26 09:39 -0800
Re: Objective C Robert Wessel <robertwessel2@yahoo.com> - 2015-11-26 13:16 -0600
Re: Objective C supercat@casperkitty.com - 2015-11-26 12:25 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:34 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-26 12:39 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:43 +0000
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-27 09:29 -0800
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:18 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-23 22:35 +0000
Re: Objective C James Kuyper <jameskuyper@verizon.net> - 2015-11-23 17:40 -0500
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-24 05:35 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-25 12:15 -0800
Re: Objective C glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-11-25 22:49 +0000
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-27 16:44 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 14:03 -0800
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-29 09:29 +0000
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-22 19:01 +0000
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-23 07:31 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-23 07:43 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-23 08:17 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-23 17:34 +0100
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-23 22:02 +0000
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-24 10:12 +0100
Re: Objective C Tim Rentsch <txr@alumni.caltech.edu> - 2015-11-27 08:39 -0800
Re: Objective C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-11-14 18:24 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 12:23 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 12:36 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 13:13 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 14:04 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 14:15 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 14:29 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-14 15:39 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-14 16:37 -0800
Re: Objective C Ian Collins <ian-news@hotmail.com> - 2015-11-15 13:46 +1300
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 02:06 +0000
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-15 03:25 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 12:56 +0000
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-15 07:53 -0600
Re: Objective C Stephen Sprunk <stephen@sprunk.org> - 2015-11-15 07:19 -0600
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-15 13:29 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-15 10:56 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-15 14:35 -0800
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-15 16:52 -0800
Re: Objective C supercat@casperkitty.com - 2015-11-15 19:49 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-16 11:02 +0000
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-16 10:36 -0800
Re: Objective C David Thompson <dave.thompson2@verizon.net> - 2015-12-06 08:03 -0500
Re: Objective C Melzzzzz <mel@zzzzz.com> - 2015-11-16 02:01 +0100
Re: Objective C supercat@casperkitty.com - 2015-11-15 19:34 -0800
Re: Objective C Chad <cdalten@gmail.com> - 2015-11-15 19:54 -0800
Re: Objective C raltbos@xs4all.nl (Richard Bos) - 2015-11-17 22:36 +0000
Re: Objective C supercat@casperkitty.com - 2015-11-17 15:27 -0800
Re: Objective C Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-11-17 21:15 -0800
Re: Objective C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-11-14 22:08 +0000
Re: Objective C fir <profesor.fir@gmail.com> - 2015-11-27 14:36 -0800
Re: Objective C David Brown <david.brown@hesbynett.no> - 2015-11-10 19:03 +0100
Re: Objective C Keith Thompson <kst-u@mib.org> - 2015-11-10 10:50 -0800
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-11-15 13:46 +1300 |
| Message-ID | <daq2ukFi0ttU13@mid.individual.net> |
| In reply to | #76061 |
Malcolm McLean wrote:
> On Saturday, November 14, 2015 at 11:39:56 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> How do you convert a float to int?
>>
>> float f = 42.0;
>> int i = f;
>>
>> How do you print a human-readable representation of a float value?
>>
>> printf("%f\n", f);
>>
>> How are strict aliasing / effective type rules relevant to any of this?
>> My point is that Alla, and other novice C programmers, don't need to
>> worry about any of that. (I rarely worry about it myself.)
>>
> If you're content to say they work by magic, then fair enough.
> But if you want to understand what's going on, you have to
> explain it in terms of reinterpretation of bits, or aliasing.
Why? It is a fundamental feature of the language.
Do you have to explain loops in terms of conditional branch instructions?
I'd also like to know your answer to Keith's question "How are strict
aliasing / effective type rules relevant to any of this?"
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-15 02:06 +0000 |
| Message-ID | <87y4e0uibn.fsf@bsb.me.uk> |
| In reply to | #76061 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, November 14, 2015 at 11:39:56 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> How do you convert a float to int?
>>
>> float f = 42.0;
>> int i = f;
>>
>> How do you print a human-readable representation of a float value?
>>
>> printf("%f\n", f);
>>
>> How are strict aliasing / effective type rules relevant to any of this?
>> My point is that Alla, and other novice C programmers, don't need to
>> worry about any of that. (I rarely worry about it myself.)
>>
> If you're content to say they work by magic, then fair enough.
> But if you want to understand what's going on, you have to
> explain it in terms of reinterpretation of bits, or aliasing.
I thought the point you were making was to query how one can implement a
conversion from one set of bits (the representation of a float that you
suggested) to an int value in C without falling foul of the various type
and aliasing rules. If that indeed was your question, one answer is to
use bit fields with unsigned int type. The answer can be calculated
from those integers by a simple but laborious bit of code.
But given this more recent answer, I'm not sure what you point is
anymore. You can explain what's going on in the conversion and printing
above without making any reference to C at all, so there's no obvious
link to C rules about reinterpretation and aliasing.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-15 03:25 -0800 |
| Message-ID | <40116274-200f-415c-be26-13692a5988c4@googlegroups.com> |
| In reply to | #76070 |
On Sunday, November 15, 2015 at 2:07:01 AM UTC, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>
> > On Saturday, November 14, 2015 at 11:39:56 PM UTC, Keith Thompson wrote:
> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> >>
> >> How do you convert a float to int?
> >>
> >> float f = 42.0;
> >> int i = f;
> >>
> >> How do you print a human-readable representation of a float value?
> >>
> >> printf("%f\n", f);
> >>
> >> How are strict aliasing / effective type rules relevant to any of this?
> >> My point is that Alla, and other novice C programmers, don't need to
> >> worry about any of that. (I rarely worry about it myself.)
> >>
> > If you're content to say they work by magic, then fair enough.
> > But if you want to understand what's going on, you have to
> > explain it in terms of reinterpretation of bits, or aliasing.
>
> I thought the point you were making was to query how one can implement a
> conversion from one set of bits (the representation of a float that you
> suggested) to an int value in C without falling foul of the various type
> and aliasing rules. If that indeed was your question, one answer is to
> use bit fields with unsigned int type. The answer can be calculated
> from those integers by a simple but laborious bit of code.
>
> But given this more recent answer, I'm not sure what you point is
> anymore. You can explain what's going on in the conversion and printing
> above without making any reference to C at all, so there's no obvious
> link to C rules about reinterpretation and aliasing.
>
The point is that we can regard floating point types as opaque- just a representation
of a real number that, for all we know, might in fact be an analogue area of memory
attached to a basically digital computer. Everything will work. Until we actually
want to print out the results in human-readable form.
Then you need the bits. Or you can use a cast to int - it's arguable whether a real
atof() routine is better reading the bits directly or using a cast. But the cast to the
int is really handwaving and magicing away the problem, because the cast
operation needs to reinterpret the bits.
Aliasing a float to a 32 bit integer and extracting the bits is pretty basic. Not lesson
one in C programming. But certainly something to cover early on.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-15 12:56 +0000 |
| Message-ID | <87ziyfto9b.fsf@bsb.me.uk> |
| In reply to | #76088 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Sunday, November 15, 2015 at 2:07:01 AM UTC, Ben Bacarisse wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>>
>> > On Saturday, November 14, 2015 at 11:39:56 PM UTC, Keith Thompson wrote:
>> >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> >>
>> >> How do you convert a float to int?
>> >>
>> >> float f = 42.0;
>> >> int i = f;
>> >>
>> >> How do you print a human-readable representation of a float value?
>> >>
>> >> printf("%f\n", f);
>> >>
>> >> How are strict aliasing / effective type rules relevant to any of this?
>> >> My point is that Alla, and other novice C programmers, don't need to
>> >> worry about any of that. (I rarely worry about it myself.)
>> >>
>> > If you're content to say they work by magic, then fair enough.
>> > But if you want to understand what's going on, you have to
>> > explain it in terms of reinterpretation of bits, or aliasing.
>>
>> I thought the point you were making was to query how one can implement a
>> conversion from one set of bits (the representation of a float that you
>> suggested) to an int value in C without falling foul of the various type
>> and aliasing rules. If that indeed was your question, one answer is to
>> use bit fields with unsigned int type. The answer can be calculated
>> from those integers by a simple but laborious bit of code.
>>
>> But given this more recent answer, I'm not sure what you point is
>> anymore. You can explain what's going on in the conversion and printing
>> above without making any reference to C at all, so there's no obvious
>> link to C rules about reinterpretation and aliasing.
>>
> The point is that we can regard floating point types as opaque- just a
> representation of a real number that, for all we know, might in fact
> be an analogue area of memory attached to a basically digital
> computer. Everything will work. Until we actually want to print out
> the results in human-readable form. Then you need the bits. Or you
> can use a cast to int - it's arguable whether a real atof() routine is
> better reading the bits directly or using a cast.
I can't follow this. There is some to me unclear "problem" that you can
see that i can't. It's not helped by the fact that I think you are
using your own meanings again because:
> But the cast to the int is really handwaving and magicing away the
> problem, because the cast operation needs to reinterpret the bits.
The cast converts the value. Reinterpreting the bits would, in all
cases I know give a different result.
> Aliasing a float to a 32 bit integer and extracting the bits is pretty
> basic. Not lesson one in C programming. But certainly something to
> cover early on.
Why would it be in any C lesson? Why would you not teach doing it
with a union?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-15 07:53 -0600 |
| Message-ID | <n2a2kr$2nr$1@dont-email.me> |
| In reply to | #76088 |
On 15-Nov-15 05:25, Malcolm McLean wrote:
>>> Keith Thompson wrote:
>>>> How do you convert a float to int?
>>>>
>>>> float f = 42.0;
>>>> int i = f;
>>>>
>>>> How do you print a human-readable representation of a float
>>>> value?
>>>>
>>>> printf("%f\n", f);
>>>> ...
>
> The point is that we can regard floating point types as opaque- just
> a representation of a real number that, for all we know, might in
> fact be an analogue area of memory attached to a basically digital
> computer. Everything will work. Until we actually want to print out
> the results in human-readable form. Then you need the bits. Or you
> can use a cast to int - it's arguable whether a real atof() routine
> is better reading the bits directly or using a cast. But the cast to
> the int is really handwaving and magicing away the problem, because
> the cast operation needs to reinterpret the bits.
No, it doesn't.
In the above example, the conversion of a float _value_ to an integer
_value_ does not involve casting, aliasing or reinterpretation. The
compiler is required to know how to convert _values_ and to do so
transparently when necessary, so unless you are writing a compiler
yourself, "it's magic" is sufficient.
Adding a cast to one of the values does not change this in _any_ way,
which is why the cast isn't necessary in the first place:
int i = (int)f;
You don't have to deal with aliasing, reinterpretation, etc. until there
are pointers (or unions) involved:
float *f = malloc(sizeof float);
*f = 42.0;
int *i = (int *)f;
print("%d\n", *i);
This _does_ create an alias and _does_ reinterpret bits, which is why
the cast is needed, and the above "magic" doesn't apply because you're
not converting _values_. Converting _pointers_ is governed by an
entirely different set of rules that frequently invoke
implementation-defined and/or undefined behavior, so avoid doing that if
possible.
S
--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2015-11-15 07:19 -0600 |
| Message-ID | <n2a0k8$pq5$1@dont-email.me> |
| In reply to | #76070 |
On 14-Nov-15 20:06, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> Keith Thompson wrote: >>> How are strict aliasing / effective type rules relevant to any of >>> this? My point is that Alla, and other novice C programmers, >>> don't need to worry about any of that. (I rarely worry about it >>> myself.) >>> >> If you're content to say they work by magic, then fair enough. But >> if you want to understand what's going on, you have to explain it >> in terms of reinterpretation of bits, or aliasing. > > I thought the point you were making was to query how one can > implement a conversion from one set of bits (the representation of a > float that you suggested) to an int value in C without falling foul > of the various type and aliasing rules. Aliasing only comes into play when one is dealing with pointers, and reinterpretation of bits only comes into play when one is dealing with pointers to _different_ types or with unions. If there are no pointers and no unions, they are irrelevant. Converting a _value_ of one type to a _value_ of another type is governed by completely different rules. The compiler is required to do this when necessary, and do so transparently; unless you are writing a compiler yourself, the details are irrelevant. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-15 13:29 +0000 |
| Message-ID | <87twontmqg.fsf@bsb.me.uk> |
| In reply to | #76090 |
Stephen Sprunk <stephen@sprunk.org> writes: > On 14-Nov-15 20:06, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >>> Keith Thompson wrote: >>>> How are strict aliasing / effective type rules relevant to any of >>>> this? My point is that Alla, and other novice C programmers, >>>> don't need to worry about any of that. (I rarely worry about it >>>> myself.) >>>> >>> If you're content to say they work by magic, then fair enough. But >>> if you want to understand what's going on, you have to explain it >>> in terms of reinterpretation of bits, or aliasing. >> >> I thought the point you were making was to query how one can >> implement a conversion from one set of bits (the representation of a >> float that you suggested) to an int value in C without falling foul >> of the various type and aliasing rules. > > Aliasing only comes into play when one is dealing with pointers, and > reinterpretation of bits only comes into play when one is dealing with > pointers to _different_ types or with unions. If there are no pointers > and no unions, they are irrelevant. > > Converting a _value_ of one type to a _value_ of another type is > governed by completely different rules. Yes, that's why I used the phrase "set of bits". I was not talking about a value to value conversion. More precisely, I thought Malcolm was not talking about a value to value conversion but extracting an int value from a floating point representation (the "set of bits"). > The compiler is required to do > this when necessary, and do so transparently; unless you are writing a > compiler yourself, the details are irrelevant. Yes. Malcolm's post talked about implementing floating point in software so I thought he was indeed talking about stuff that has to happen "behind the scenes". But I accept that I no longer know what he was talking about as subsequent posts have muddied the waters. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-15 10:56 -0800 |
| Message-ID | <lnbnavm6rh.fsf@kst-u.example.com> |
| In reply to | #76061 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Saturday, November 14, 2015 at 11:39:56 PM UTC, Keith Thompson wrote:
>> Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
>> How do you convert a float to int?
>>
>> float f = 42.0;
>> int i = f;
>>
>> How do you print a human-readable representation of a float value?
>>
>> printf("%f\n", f);
>>
>> How are strict aliasing / effective type rules relevant to any of this?
>> My point is that Alla, and other novice C programmers, don't need to
>> worry about any of that. (I rarely worry about it myself.)
>>
> If you're content to say they work by magic, then fair enough.
> But if you want to understand what's going on, you have to
> explain it in terms of reinterpretation of bits, or aliasing.
I don't have much to add to the other responses you've gotten. I'll
just say that operating on floating-point values and objects, including
converting a float value to int (and I mean the kind of conversion that
converts 42.0 to 42) and generating a human-readable string
representation of a floating-point value, does not require
reinterpretation of the bits making up the representation of a
floating-point value or object. And I have no idea why you think it
does.
The context here is whether a novice C programmer needs to worry about
aliasing. The points you introduce are (a) beyond anything a novice C
programmer needs to worry about and (b) wrong.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-15 14:35 -0800 |
| Message-ID | <c6fa3d0b-537a-4f47-8de2-55962ef49a52@googlegroups.com> |
| In reply to | #76106 |
On Sunday, November 15, 2015 at 12:56:14 PM UTC-6, Keith Thompson wrote: > And I have no idea why you think it does. I was responding to the person's love of the language. I love the language that C programmers regarded as the common subset of non-weird C implementations in the 1990s, and I would like to see the OP come to appreciate the elegance of the multiple levels of abstraction that were combined therein. The OP isn't yet using pointers and malloc, but for understanding such things it's helpful to understand that memory is made up of a sequence of bytes, and that given "int *p", the expression "*p=123456789;" will break the number into byte-sized pieces and store them into consecutive bytes in memory, and that "int x=*p;" will reconstitute the value from those bytes. It's a very nice and elegant model, and I would hope newcomers would find it as fascinating as I did back in 1989. If one uses gcc with the -fno-strict-aliasing flag, it will behave according to such a model, and a new programmer will be able to try various experiments to see how things are really stored. If one does not use that flag, however, then it will sometimes behave as the model would suggest and sometimes behave in totally bizarre fashion without rhyme or reason. I would like to see C remain as a viable language for decades to come, but for that to happen it needs to offer novice programmers something that they won't find in other languages that are easier to work with. C has always historically required programmers to do extra work to manage things at the memory level (e.g. allocating a number of bytes suitable to hold something, rather than just creating an object of the proper type) but the -fno-strict- aliasing dialect of C gives programmers some extra power in exchange for that extra work. The language without -fno-strict-aliasing, by contrast, requires more work than Java or .NET, but exposes less power. JIT compilers for platforms like Java and .NET are improving, to the point that in many fields I don't see C holding a meaningful performance edge for much longer. The only reasons I can see for using C would be if either: 1. One is coding for a (probably embedded) platform which can't support Java or .NET, in which case one will need tight control over what's going on. 2. C offers better semantics than languages for those other platforms. At present, I would be hard-pressed to think of ways in which C, as defined by the Standard, would be semantically superior to Java or any of the .NET languages. It wouldn't take much to make it be semantically superior, but at present the language as defined by the Standard just isn't there.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-15 16:52 -0800 |
| Message-ID | <ln37w6n4tv.fsf@kst-u.example.com> |
| In reply to | #76133 |
supercat@casperkitty.com writes:
> On Sunday, November 15, 2015 at 12:56:14 PM UTC-6, Keith Thompson wrote:
>> And I have no idea why you think it does.
The above was a tiny part of my response to something Malcolm wrote.
I'm not sure why you're quoting it your followup, or why you've snipped
*all* the relevant context.
[...]
> The OP isn't yet using pointers and malloc, but for understanding such
> things it's helpful to understand that memory is made up of a sequence
> of bytes, and that given "int *p", the expression "*p=123456789;" will
> break the number into byte-sized pieces and store them into
> consecutive bytes in memory, and that "int x=*p;" will reconstitute
> the value from those bytes. It's a very nice and elegant model, and I
> would hope newcomers would find it as fascinating as I did back in
> 1989.
It's usually more useful to think of p as pointing to an object of type
int, and `*p=123456789;` as storing an int value in that int object.
> If one uses gcc with the -fno-strict-aliasing flag, it will behave
> according to such a model, and a new programmer will be able to try
> various experiments to see how things are really stored. If one does
> not use that flag, however, then it will sometimes behave as the model
> would suggest and sometimes behave in totally bizarre fashion without
> rhyme or reason.
The standard defines the representation of an object as a sequence of
values of type unsigned char (i.e., bytes). I don't believe there's
anything in the standard, even in the parts you dislike, that's
inconsistent with that.
[...]
(I request again that you keep your lines a bit shorter so I don't have
to reformat them when I quote them.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-15 19:49 -0800 |
| Message-ID | <9c627b85-5ca4-4ad6-93d2-14cae343e879@googlegroups.com> |
| In reply to | #76144 |
On Sunday, November 15, 2015 at 6:52:35 PM UTC-6, Keith Thompson wrote:
> The standard defines the representation of an object as a sequence of
> values of type unsigned char (i.e., bytes). I don't believe there's
> anything in the standard, even in the parts you dislike, that's
> inconsistent with that.
If an object's representation is a series of "unsigned char", then that
would mean that if *p=x would cause the sequence of bytes identified by
p to hold {1,2,3,4}, and if reading *q when q identifies a suitably-
aligned sequence of bytes containing {1,2,3,4} would yield the value
0x04030201, then those two facts together would imply that if *p and *q
identify the same sequence of bytes, then storing x into *p and reading
*q should yield 0x04030201.
Under C89, the fact that q identifies a suitably-aligned sequence of
bytes holding 0x04030201 says nothing about what may happen if one tries
to access *q. From an "as-if" standpoint, a compiler is entitled to
behave as though each byte holds some invisible and inaccessible information
related to its effective type, whose sole purpose is to allow a compiler
to find an excuse to engage in arbitrary behavior.
C99 makes things worse by saying that if one copies the unsigned char values
{1,2,3,4} which were stored for p into a new sequence of bytes occupied by q,
and p and q are not compatible types, a compiler which can figure out that
those bytes were copied from storage written as type *p could use the access
to *q as an excuse to engage in arbitrary behavior.
I could see some usefulness to such typing rules in certain kinds of
"sandboxing" implementations, fully recognizing that such rules would make
it impossible to write certain kinds of programs that would be useful in
other context. There is, however, a huge difference between saying that
a compiler may choose to implement certain restrictions if it defines
certain macros indicating what those restrictions are, versus taking the
attitude that no code on any platform has any write to expect that memory
will actually behave as a sequence of bytes.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-16 11:02 +0000 |
| Message-ID | <87h9kmryvc.fsf@bsb.me.uk> |
| In reply to | #76157 |
supercat@casperkitty.com writes:
> On Sunday, November 15, 2015 at 6:52:35 PM UTC-6, Keith Thompson wrote:
>> The standard defines the representation of an object as a sequence of
>> values of type unsigned char (i.e., bytes). I don't believe there's
>> anything in the standard, even in the parts you dislike, that's
>> inconsistent with that.
>
> If an object's representation is a series of "unsigned char", then that
> would mean that if *p=x would cause the sequence of bytes identified by
> p to hold {1,2,3,4}, and if reading *q when q identifies a suitably-
> aligned sequence of bytes containing {1,2,3,4} would yield the value
> 0x04030201, then those two facts together would imply that if *p and *q
> identify the same sequence of bytes, then storing x into *p and reading
> *q should yield 0x04030201.
No. When you write 0x04030201 you are writing a value. The mapping
between the representation in bytes and the value it represents is
determined by two things: the type of the expression used to access the
representation, and the meaning the implementation chooses for the bits.
Accessing (unsigned char []){1,2,3,4} as in int might just as well
produce the value 0x10203, and it almost certainly won't yield that same
value if you access that collection of bytes as a float.
If *p and *q have "assignment compatible" types, then storing x into *p
and reading *q should yield the same value provided there is no other
reason to prohibit it (restrict-qualified pointers come to mind, for
example). I say "assignment compatible", because assignment has an
extra permission relating to type qualifiers.
> Under C89, the fact that q identifies a suitably-aligned sequence of
> bytes holding 0x04030201 says nothing about what may happen if one tries
> to access *q. From an "as-if" standpoint, a compiler is entitled to
> behave as though each byte holds some invisible and inaccessible information
> related to its effective type, whose sole purpose is to allow a compiler
> to find an excuse to engage in arbitrary behavior.
The permission to take the notion of effective type into account is not
in contradiction with what Keith said.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-16 10:36 -0800 |
| Message-ID | <lnlh9xlrjp.fsf@kst-u.example.com> |
| In reply to | #76170 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
> There also might be literals that »have no value«, in
> the sense that a literal like »0x0403020104030201« might
> be rejected by some implementations (as »too large«).
[...]
But not a literal *exactly* like that, which must be accepted by any
conforming C implementation. It is of type int, long, or long long
depending on the ranges of those types (assuming C99 or later). But the
point is perfectly valid if you add a couple more digits.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2015-12-06 08:03 -0500 |
| Message-ID | <efc86b118l6s2qrc8rdebd917fa3gtpr0i@4ax.com> |
| In reply to | #76170 |
On 16 Nov 2015 11:41:09 GMT, ram@zedat.fu-berlin.de (Stefan Ram) wrote: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > >No. When you write 0x04030201 you are writing a value. The mapping > > What one actually writes, to me, is a »literal«, but C calls > it »integer-constant« (6.4.4.1). > > The literal /has a/ value, but the value is not written > directly. > I'm pretty sure this is a misunderstanding, and Ben meant 'write' in the sense of 'store a value in an object at runtime' not 'write' in the sense of 'choose the contents of part of a source file'. I.e. 'write 0x04030201' in the context of this thread means execute an assignment such as *p = x where p is a pointer to an integer type that occupies 4 bytes which individually might have values 1,2,3,4, or not. > >If *p and *q have "assignment compatible" types, then storing x into *p > > The C norms do not contain the notion of »assignment > compatibility« AFAIK, but the »Java Language Specification« > does: > > »If the type of an expression can be converted to the > type of a variable by assignment conversion, we say the > expression (or its value) is assignable to the variable > or, equivalently, that the type of the expression is > assignment compatible with the type of the variable.« > (JLS8, 5.2) > > (In Java, »object« is called »variable«.) In C, 'int' 'const int' 'volatile int' etc are not compatible types, nor are 'int *' 'const int *' 'volatile int *' etc, but an int object can be read or 'written' ((the standard says 'modified') through a qualified int lvalue (excluding modifying through const) possibly (usually) created by dereferencing a pointer to qualified int. See 6.5p7 and 6.5.16.1. I'm pretty sure this is what Ben meant here. Note 'int *' can be _converted without cast to_ 'const int *' etc, but that is not the same as compatibility.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-11-16 02:01 +0100 |
| Message-ID | <20151116020110.36f01527@maxa-pc> |
| In reply to | #76133 |
On Sun, 15 Nov 2015 14:35:56 -0800 (PST)
supercat@casperkitty.com wrote:
> On Sunday, November 15, 2015 at 12:56:14 PM UTC-6, Keith Thompson
> wrote:
> > And I have no idea why you think it does.
>
> I was responding to the person's love of the language. I love the
> language that C programmers regarded as the common subset of
> non-weird C implementations in the 1990s, and I would like to see the
> OP come to appreciate the elegance of the multiple levels of
> abstraction that were combined therein.
>
> The OP isn't yet using pointers and malloc, but for understanding
> such things it's helpful to understand that memory is made up of a
> sequence of bytes, and that given "int *p", the expression
> "*p=123456789;" will break the number into byte-sized pieces and
> store them into consecutive bytes in memory, and that "int x=*p;"
> will reconstitute the value from those bytes. It's a very nice and
> elegant model, and I would hope newcomers would find it as
> fascinating as I did back in 1989.
C is not assembler.
>
> If one uses gcc with the -fno-strict-aliasing flag, it will behave
> according to such a model, and a new programmer will be able to try
> various experiments to see how things are really stored. If one does
> not use that flag, however, then it will sometimes behave as the
> model would suggest and sometimes behave in totally bizarre fashion
> without rhyme or reason.
Because of optimizations. You can't assume things common for assembler
to behave same way in HLL.
>
> I would like to see C remain as a viable language for decades to
> come, but for that to happen it needs to offer novice programmers
> something that they won't find in other languages that are easier to
> work with. C has always historically required programmers to do
> extra work to manage things at the memory level (e.g. allocating a
> number of bytes suitable to hold something, rather than just creating
> an object of the proper type) but the -fno-strict- aliasing dialect
> of C gives programmers some extra power in exchange for that extra
> work.
What power?
The language without -fno-strict-aliasing, by contrast,
> requires more work than Java or .NET, but exposes less power.
Java or .NET does not have anything to do with C.
JIT
> compilers for platforms like Java and .NET are improving, to the
> point that in many fields I don't see C holding a meaningful
> performance edge for much longer.
C compilers are also improving...
Try this in java and C:
void init(int* array,int N)
{
for(int k=0;k<N;++k)
{
array[k]=k/3+k;
}
}
Measure execution time and report results. On my CPU gcc performs twice
as fast then Oracle Java 8... this is probably because gcc vectorizes
loop and last time I checked Java didn't perform division by
multiplication...
The only reasons I can see for
> using C would be if either:
>
> 1. One is coding for a (probably embedded) platform which can't
> support Java or .NET, in which case one will need tight control over
> what's going on.
>
> 2. C offers better semantics than languages for those other platforms.
>
That is, if one can choose.
> At present, I would be hard-pressed to think of ways in which C, as
> defined by the Standard, would be semantically superior to Java or
> any of the .NET languages.
?
It wouldn't take much to make it be
> semantically superior, but at present the language as defined by the
> Standard just isn't there.
What you mean by semantically superior? In .NET you can even count on
pointer not changing value under the hood let alone count on sequence
of bytes in memory...
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-15 19:34 -0800 |
| Message-ID | <fbb7eb6a-1632-433d-aab5-d5c9cfa8846e@googlegroups.com> |
| In reply to | #76145 |
On Sunday, November 15, 2015 at 7:01:19 PM UTC-6, Melzzzzz wrote: > C is not assembler. C was designed for systems programming of a type which had formerly required assembler. Compiler writers have traditionally supported its use for such purposes. If some people want a language which can't support the kinds of systems programming for which C has traditionally excelled, why should they not specify a new language which is based on C, but is better suited for the purposes they want, rather than trying to pretend that C has never been a language that supported the kinds of programming for which it was designed? > On Sun, 15 Nov 2015 14:35:56 -0800 (PST) > supercat wrote: > > If one uses gcc with the -fno-strict-aliasing flag, it will behave > > according to such a model, and a new programmer will be able to try > > various experiments to see how things are really stored. If one does > > not use that flag, however, then it will sometimes behave as the > > model would suggest and sometimes behave in totally bizarre fashion > > without rhyme or reason. > > Because of optimizations. You can't assume things common for assembler > to behave same way in HLL. Why not retain the ability to do things that could be done with 1990s C compilers while adding optimization opportunities by defining directives to let compilers know what freedoms they can exploit, and what constraints they must abide? > > I would like to see C remain as a viable language for decades to > > come, but for that to happen it needs to offer novice programmers > > something that they won't find in other languages that are easier to > > work with. C has always historically required programmers to do > > extra work to manage things at the memory level (e.g. allocating a > > number of bytes suitable to hold something, rather than just creating > > an object of the proper type) but the -fno-strict- aliasing dialect > > of C gives programmers some extra power in exchange for that extra > > work. > > What power? The ability to subdivide blocks of memory dynamically into different sizes of objects, and use a variety of compact data structures. Using malloc/free on lots of little 8-32 byte objects can be a real performance killer, but C was defined by K&R to allow code to efficiently reuse and reuse memory. Further, on many platforms it made it possible to process certain kinds of string operations in two- or four-character chunks. While optimizers may be able to find some such optimizations, there are a lot of cases where a programmer will know things an optimizer can't. > What you mean by semantically superior? In .NET you can even count on > pointer not changing value under the hood let alone count on sequence > of bytes in memory... C# allows code to request integer arithmetic that wraps in two's-complement mod fashion, or integer arithmetic which is overflow-checked, depending upon which the code needs at any given time. It also provides explicit memory barriers. I see no reason C shouldn't be able to offer all of those features, and would regard them as substantial semantic improvements over the language as it exists now.
[toc] | [prev] | [next] | [standalone]
| From | Chad <cdalten@gmail.com> |
|---|---|
| Date | 2015-11-15 19:54 -0800 |
| Message-ID | <e3727360-3534-4e7f-b8be-792b5c31a93d@googlegroups.com> |
| In reply to | #76156 |
On Sunday, November 15, 2015 at 7:34:22 PM UTC-8, supe...@casperkitty.com wrote: > On Sunday, November 15, 2015 at 7:01:19 PM UTC-6, Melzzzzz wrote: > > C is not assembler. > > C was designed for systems programming of a type which had formerly required > assembler. Assembler is *not* assembly though. Carry on. Chad
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-11-17 22:36 +0000 |
| Message-ID | <564babab.27210750@news.xs4all.nl> |
| In reply to | #76133 |
supercat@casperkitty.com wrote: > On Sunday, November 15, 2015 at 12:56:14 PM UTC-6, Keith Thompson wrote: > > And I have no idea why you think it does. > > I was responding to the person's love of the language. I love the language > that C programmers regarded as the common subset of non-weird C implementations > in the 1990s, No. It's become increasingly clear that what you love is _your memory of_ what _you_ regarded as that common subset. Many other programmers also programmed during the 1990s, me included, and I never mistook Turbo C for the reference implementation. Richard
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-17 15:27 -0800 |
| Message-ID | <92910574-8658-48a0-a857-763d27faa7b7@googlegroups.com> |
| In reply to | #76312 |
On Tuesday, November 17, 2015 at 4:37:40 PM UTC-6, Richard Bos wrote: > No. It's become increasingly clear that what you love is _your memory > of_ what _you_ regarded as that common subset. Many other programmers > also programmed during the 1990s, me included, and I never mistook > Turbo C for the reference implementation. Nor did I, since I also programmed in C on the Macintosh and a variety of embedded microcontrollers and DSPs; those varied implementations were weird in various ways dictated by the hardware, but even the ones for weird hardware tried to behave as much like the PC and Macintosh compilers as possible.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-11-17 21:15 -0800 |
| Message-ID | <20ae423d-daa9-4801-844d-de970a16f0ed@googlegroups.com> |
| In reply to | #76312 |
On Tuesday, November 17, 2015 at 10:37:40 PM UTC, Richard Bos wrote: > > No. It's become increasingly clear that what you love is _your memory > of_ what _you_ regarded as that common subset. Many other programmers > also programmed during the 1990s, me included, and I never mistook > Turbo C for the reference implementation. > I got Microsoft's Quick C (my grandmother bought me the compiler as a birthday present, and I had to try to explain to her what it was she had just purchased). I hadn't heard of ANSI and was completely unaware that there was a standard, so I remember being very puzzled that cprintf() obeyed the move commands whilst printf() did not, that there was an fputc() but no fputint(), and other quirks.
[toc] | [prev] | [next] | [standalone]
Page 9 of 10 — ← Prev page 1 … 7 8 [9] 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web