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 1 of 10 [1] 2 3 … 10 Next page →
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-11-10 09:10 -0800 |
| Subject | Objective C |
| Message-ID | <829a44d6-a605-4d49-87d0-04fa9d2a2a0a@googlegroups.com> |
Hello! May I ask questions that refer to Objective C, or does this forum restrict questions to C language? I am yet sure I understand whether Objective C is part of C, or a completely separate language. I have found the forum on Objective C created by S. Kochan, but I am not sure how active the forum is (I have posted my question there however). Thank you!
[toc] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2015-11-10 09:16 -0800 |
| Message-ID | <b44ac5cb-c3c5-442b-b509-3ccc1a8be02d@googlegroups.com> |
| In reply to | #75624 |
On Tuesday, November 10, 2015 at 12:10:59 PM UTC-5, Alla _ wrote: > Hello! > > May I ask questions that refer to Objective C, or does this forum > restrict questions to C language? I am yet sure I understand whether > Objective C is part of C, or a completely separate language. It depends on who here you ask. > I have found the forum on Objective C created by S. Kochan, but I am > not sure how active the forum is (I have posted my question there however). > > Thank you! Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-10 17:17 +0000 |
| Message-ID | <n1t8mm$4kg$2@dont-email.me> |
| In reply to | #75624 |
On 10/11/15 17:10, Alla _ wrote: > Hello! > > May I ask questions that refer to Objective C, or does this forum > restrict questions to C language? I am yet sure I understand whether > Objective C is part of C, or a completely separate language. It is a separate language derived from C. My understanding of the topicality of this group is that it is restricted to C itself, and excludes languages derived from it. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-10 09:32 -0800 |
| Message-ID | <lnr3jxu5dj.fsf@kst-u.example.com> |
| In reply to | #75624 |
Alla _ <modelling.data@gmail.com> writes:
> May I ask questions that refer to Objective C, or does this forum
> restrict questions to C language? I am yet sure I understand whether
> Objective C is part of C, or a completely separate language.
>
> I have found the forum on Objective C created by S. Kochan, but I am
> not sure how active the forum is (I have posted my question there however).
Objective-C is a separate language, and is off-topic here.
(As I understand it, Objective-C, unlike C++, is actually a strict
superset of C.)
There's a comp.lang.objective-c newsgroup, but I don't know how active
it is.
Stack Overflow <https://stackoverflow.com/> is also a good place for
programming questions (opinions will differ on this).
--
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 | Mark Storkamp <mstorkamp@yahoo.com> |
|---|---|
| Date | 2015-11-10 11:38 -0600 |
| Message-ID | <mstorkamp-1A7126.11382310112015@88-209-239-213.giganet.hu> |
| In reply to | #75636 |
In article <lnr3jxu5dj.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: > Alla _ <modelling.data@gmail.com> writes: > > May I ask questions that refer to Objective C, or does this forum > > restrict questions to C language? I am yet sure I understand whether > > Objective C is part of C, or a completely separate language. > > > > I have found the forum on Objective C created by S. Kochan, but I am > > not sure how active the forum is (I have posted my question there however). > > Objective-C is a separate language, and is off-topic here. > > (As I understand it, Objective-C, unlike C++, is actually a strict > superset of C.) > > There's a comp.lang.objective-c newsgroup, but I don't know how active > it is. > There's also comp.sys.mac.programmer.help - since most objective-c programming is for OS-X or iOS > Stack Overflow <https://stackoverflow.com/> is also a good place for > programming questions (opinions will differ on this).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-11-10 12:36 -0500 |
| Message-ID | <n1t9ra$afb$1@dont-email.me> |
| In reply to | #75624 |
On 11/10/2015 12:10 PM, Alla _ wrote: > Hello! > > May I ask questions that refer to Objective C, or does this forum > restrict questions to C language? ... This is an unmoderated newsgroup. No one can prevent you from talking about anything you want to talk about. Nominally, the topic for this newsgroup is the C language. However, it's currently primarily used by people who find C defective, for the purpose of discussing their proposed alternatives to C. > ... I am yet sure I understand whether > Objective C is part of C, or a completely separate language. Objective C is a separate language, though heavily inspired by C. I'd recommend not bothering to learn a new language until you've made some decent progress understanding C. Otherwise you're likely to confuse the things you learn about Objective C with the things you're learning about C. However, if you're giving up on C, then there's no reason not to move on to Objective C. However, I believe that most of the things that have confused you about C are equally confusing in Objective C. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-11-10 11:15 -0800 |
| Message-ID | <3f7e3553-b5b3-45a7-9a3e-d2b18c7268a4@googlegroups.com> |
| In reply to | #75637 |
<snip> Thank you everyone for your answers. Although the group is not moderated, I tend not to violate tacit rules, because I understand how annoying off-topic message might be to some members. About C - I am not giving it up. I love it, the more I learn the more I like it. As I said elsewhere, I have to move on with what's suggested by CS50 course, and meanwhile I do go on with learning C - I don't believe that it makes sense to learn any other language until one knows C. I have some issues with Objective C program because I have no idea how to compile it, and my compiler yells at me. But even the program itself looks, well, not so nice and not so elegant as any written in C. C is more about functions, and I like it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-11-10 21:51 +0000 |
| Message-ID | <n1toom$abg$1@dont-email.me> |
| In reply to | #75665 |
On 10/11/15 19:15, Alla _ wrote: > <snip> > Thank you everyone for your answers. > Although the group is not moderated, I tend not to violate > tacit rules, because I understand how annoying off-topic > message might be to some members. > > About C - I am not giving it up. Good. > I love it, the more I learn > the more I like it. As I said elsewhere, I have to move on with > what's suggested by CS50 course, Not so good. It is pushing you into learning things at a faster pace than you can handle. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2015-11-10 23:13 -0800 |
| Message-ID | <98622aba-f65a-4453-8f6c-eb738d5c6a18@googlegroups.com> |
| In reply to | #75685 |
On Wednesday, November 11, 2015 at 1:51:40 AM UTC+4, Richard Heathfield wrote: > On 10/11/15 19:15, Alla _ wrote: > > <snip> > > Thank you everyone for your answers. > > Although the group is not moderated, I tend not to violate > > tacit rules, because I understand how annoying off-topic > > message might be to some members. > > > > About C - I am not giving it up. > > Good. > > > I love it, the more I learn > > the more I like it. As I said elsewhere, I have to move on with > > what's suggested by CS50 course, > > Not so good. It is pushing you into learning things at a faster pace > than you can handle. > Yes, but it is merely an introductory course; I believe the idea of this course is to get a person acquainted with basics of all languages, and related CS topics, so afterwards a person can choose the one he wants to learn and work with. But as I said elsewhere, this course is designed for bright people, and yes, I am not part of that group. Still I believe it's worth the effort.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-13 16:01 -0800 |
| Message-ID | <2e08fc7d-3253-404c-b04f-b624c3550c8f@googlegroups.com> |
| In reply to | #75665 |
On Tuesday, November 10, 2015 at 1:15:24 PM UTC-6, Alla _ wrote: > About C - I am not giving it up. I love it, the more I learn > the more I like it. Make sure you don't look too deeply into anything having to do with strict aliasing and GCC if you want to keep loving C. The authors of C99 included some weird restrictions on what programs can do which would have made many kinds of useful programs nearly impossible to write except that compilers enforced them only narrowly, if at all. In the succeeding years, there was not much call to do anything about these rules, since everyone was ignoring them anyway. Unfortunately, when the authors of gcc were faced with the fact that the only way to get good performance out of certain processors is to rearrange the order in which things are done, they decided that since the Standard requires that programs be written in such a way that certain kinds or rearrangement won't matter, the compiler should feel free to rearrange such things without regard for whether that would alter the behavior of the program [since the Standard allows compilers to do anything they like with programs whose behavior would be altered by rearranging the order in which those things are done]. Essentially, gcc can process a useful language when an option called "no strict aliasing" is used, or a bizarro-land language when that option is not used. While the latter can generate faster code than the former when given programs that conform to its requirements, such conformance in many cases requires writing programs in ways that are less efficient than would otherwise be possible, and are more prone to malfunction in weird bizarre ways.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-14 01:07 +0000 |
| Message-ID | <87fv09xubq.fsf@bsb.me.uk> |
| In reply to | #75991 |
supercat@casperkitty.com writes: > On Tuesday, November 10, 2015 at 1:15:24 PM UTC-6, Alla _ wrote: >> About C - I am not giving it up. I love it, the more I learn >> the more I like it. > > Make sure you don't look too deeply into anything having to do with strict > aliasing and GCC if you want to keep loving C. How you imagine that someone just learning to program will conclude that not being able to breaking the type rules of C is to be regretted? Someone used to writing that sort of C might regret the emergence of compilers that no longer do what was replied on, but, surely, a beginner is very unlikely to worry that such trickery is not portable. > The authors of C99 included > some weird restrictions on what programs can do which would have made many > kinds of useful programs nearly impossible to write except that compilers > enforced them only narrowly, if at all. So were you happy with the access restrictions in C90? That would be surprising, given what you've said elsewhere. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-14 06:26 -0800 |
| Message-ID | <e5eccc3a-f834-45ad-9839-9e02a6d39a93@googlegroups.com> |
| In reply to | #75995 |
On Friday, November 13, 2015 at 7:07:13 PM UTC-6, Ben Bacarisse wrote: > How you imagine that someone just learning to program will conclude that > not being able to breaking the type rules of C is to be regretted? > Someone used to writing that sort of C might regret the emergence of > compilers that no longer do what was replied on, but, surely, a beginner > is very unlikely to worry that such trickery is not portable. So far as I can tell, the type rules in C99 make C totally unsuitable for the purposes for which it was designed, and would make many kinds of embedded programming totally impossible except on compilers that ignore them. > So were you happy with the access restrictions in C90? That would be > surprising, given what you've said elsewhere. When I complained about the rules of C89/C90, I had for some reason not considered the possibility that C99 would be even worse, since compiler writers and programmers for over a decade were wise enough to ignore the rules of C99. What's truly unfortunate is that both rules could have been made much more workable if the Committee had done a few things: 1. Specify that compilers must default to a mode in which the rules are not applied across the boundaries of functions not marked "inline", and must provide a mode where they are not applied at all. Increasing the scope of the rules beyond that greatly increases the difficulty of compliance while only marginally improving the optimization opportunities. 2. Provide intrinsics which would effectively negate any "effective type" for a range of memory, or all memory. Note that this would be more useful than the present exception for "char" access, while imposing much less of an impediment to optimization, especially since programmers could often place such directives before loops, whereas the "char" exception needs to force register spills/reloads within loops. I have no problem with the idea that efficient code generation requires that the compilers be able to know about combinations of things that won't alias. I have a huge problem with the idea that language designers should care more about performance-versus-semantics trade-offs than the programmers who use a language. The vast majority of code is not performance critical, and a lot of code could run orders of magnitude slower with no effect on usability. Code which is performance-critical is the exception, rather than the rule, so why distort the normal semantics of a language to handle that oddball case? Why not instead leave C the way it is and define a new language which can use the same syntax if it chooses to do so but not pretend to be compatible with the popular language traditionally supported by C compilers?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-14 22:22 +0000 |
| Message-ID | <87lha0w7aq.fsf@bsb.me.uk> |
| In reply to | #75998 |
supercat@casperkitty.com writes: > On Friday, November 13, 2015 at 7:07:13 PM UTC-6, Ben Bacarisse wrote: >> How you imagine that someone just learning to program will conclude that >> not being able to breaking the type rules of C is to be regretted? >> Someone used to writing that sort of C might regret the emergence of >> compilers that no longer do what was replied on, but, surely, a beginner >> is very unlikely to worry that such trickery is not portable. > > So far as I can tell, the type rules in C99 make C totally unsuitable for > the purposes for which it was designed, and would make many kinds of embedded > programming totally impossible except on compilers that ignore them. (C99 again.) >> So were you happy with the access restrictions in C90? That would be >> surprising, given what you've said elsewhere. > > When I complained about the rules of C89/C90, I had for some reason not > considered the possibility that C99 would be even worse, since compiler > writers and programmers for over a decade were wise enough to ignore the > rules of C99. Right, so you don't like any of the rules that C has had in the respect for the last 25 years? Why do you keep suggesting that it's C99 that's the problem? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-14 15:46 -0800 |
| Message-ID | <bb45cd7e-7d2a-4f28-a850-d75a703027f0@googlegroups.com> |
| In reply to | #76036 |
On Saturday, November 14, 2015 at 4:22:15 PM UTC-6, Ben Bacarisse wrote:
> Right, so you don't like any of the rules that C has had in the respect
> for the last 25 years? Why do you keep suggesting that it's C99 that's
> the problem?
The thread at http://thread.gmane.org/gmane.linux.file-systems/28361/focus=29271
would suggest that gcc does not feel an obligation to honor the sequence of
operations:
1. write some storage as one type that's not a union
2. read it as that first type
3. write some storage as a different type that's not a union
4. read it as that first type
Perhaps the issue is the same in C89 and C99, even though the wording is
different, but I've never seen any indication that any C89 compiler would
not honor the sequence of operations as written above, but it sounds in
the linked thread as though gcc is deciding that the term "accessed" which
is not defined within the Standard so far as I can tell refers to both
writing and reading, and as a consequence code which uses memory for one
purpose and then later wants to use it for a different purpose may invoke
Undefined Behavior if the different purposes involve different types.
Further, the way the C99 is written, using memcpy to copy an object of one
type to heap storage and then reading that storage as another type will
yield Undefined Behavior, while in C89 memcpy was usable as a means of
"scrubbing" type information from a block of memory allowing it to be read
as any type (example below)
Am I being overly alarmist, or am I misunderstanding what's going on, or
what? The rationale given for C89 was to allow the compiler to keep things
in registers while performing operations in the given sequence. The apparent
use of the effective-type rules in gcc is to allow operations to be performed
out of sequence. Perhaps one could use the C89 wording to justify the same
sort of crazy behavior, but if code can't use a block of memory for disjoint
purposes at different times, which is what the thread would suggest, that
would render many kinds of embedded programming impossible (since malloc/free
are often not an option, but are instead replaced by functions which return
fixed-size blocks of memory from a pool).
In any case, I see no issue why the Standard shouldn't provide some means of
specifying "memory barriers"? If the Standard included an intrinsic to
"detach_and_fill_unspecified", and if code which receives a malloc'ed block
of memory and uses it for two disjoint purposes used such a directive between
those uses, then a compiler could either allocate one block of memory and
ensure that all uses of the first type complete before any of the second are
performed, or could allocate two blocks of memory and overlap the operations
as it saw fit.
C89-vs-99 example with memcpy():
In C89, by my understanding, the following would have been perfectly defined:
struct s1 { int key; };
struct s2 { int key; int data[4]; };
struct s2 s2_inst = {23, {1,2,3,4}} ;
void *p1 = malloc(sizeof (struct s1*));
void *p2 = malloc(sizeof (struct s2*));
*(struct s2**)p2 = &s2_inst;
memcpy(p1,p2, sizeof (struct s1*)); // Pointers to structs have same size
printf("%d", (*(struct s1**)p1)->key);
In c89, the memcpy would allow &s2_inst to be used as a (struct s1*), which
could in turn be used to access the "key" field of struct s2_inst. In c99,
however, the memcpy would set the effective type of *p1 to (struct s2) so
attempting to use it as a (struct s1*) would invoke Undefined Behavior.
Am I incorrect in thinking that the above code was 100% legal and defined in
C89, and Undefined in C99?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2015-11-15 01:47 +0000 |
| Message-ID | <87a8qgvxst.fsf@bsb.me.uk> |
| In reply to | #76050 |
supercat@casperkitty.com writes:
> On Saturday, November 14, 2015 at 4:22:15 PM UTC-6, Ben Bacarisse wrote:
>> Right, so you don't like any of the rules that C has had in the respect
>> for the last 25 years? Why do you keep suggesting that it's C99 that's
>> the problem?
>
> The thread at http://thread.gmane.org/gmane.linux.file-systems/28361/focus=29271
> would suggest that gcc does not feel an obligation to honor the sequence of
> operations:
>
> 1. write some storage as one type that's not a union
> 2. read it as that first type
> 3. write some storage as a different type that's not a union
> 4. read it as that first type
>
> Perhaps the issue is the same in C89 and C99,
I can't see anything between C89 and C99 that would make a difference
here.
> even though the wording is
> different, but I've never seen any indication that any C89 compiler would
> not honor the sequence of operations as written above,
Do you have any evidence other than not having seen one? In particular,
do you know that the version of gcc referred to in that thread does
*not* make the key optimisation when passed -std=c89?
> but it sounds in
> the linked thread as though gcc is deciding that the term "accessed" which
> is not defined within the Standard so far as I can tell
What did you do to find out? For example, did you read the definitions
of terms used in the standard?
> refers to both
> writing and reading, and as a consequence code which uses memory for one
> purpose and then later wants to use it for a different purpose may invoke
> Undefined Behavior if the different purposes involve different types.
>
> Further, the way the C99 is written, using memcpy to copy an object of one
> type to heap storage and then reading that storage as another type will
> yield Undefined Behavior, while in C89 memcpy was usable as a means of
> "scrubbing" type information from a block of memory allowing it to be read
> as any type (example below)
I can't find any support for that idea in the C89 standard. Can you
give a citation?
> Am I being overly alarmist, or am I misunderstanding what's going on, or
> what? The rationale given for C89 was to allow the compiler to keep things
> in registers while performing operations in the given sequence. The apparent
> use of the effective-type rules in gcc is to allow operations to be performed
> out of sequence. Perhaps one could use the C89 wording to justify the same
> sort of crazy behavior, but if code can't use a block of memory for disjoint
> purposes at different times, which is what the thread would suggest, that
> would render many kinds of embedded programming impossible (since malloc/free
> are often not an option, but are instead replaced by functions which return
> fixed-size blocks of memory from a pool).
It sounds alarmist to say that C renders many kinds of embedded
programming impossible because it's so often used for that purpose.
Maybe the programmers are able to use compilers that give them more
assurances than the C standard does? Maybe they have found ways to work
within the aliasing rules?
> In any case, I see no issue why the Standard shouldn't provide some means of
> specifying "memory barriers"? If the Standard included an intrinsic to
> "detach_and_fill_unspecified", and if code which receives a malloc'ed block
> of memory and uses it for two disjoint purposes used such a directive between
> those uses, then a compiler could either allocate one block of memory and
> ensure that all uses of the first type complete before any of the second are
> performed, or could allocate two blocks of memory and overlap the operations
> as it saw fit.
>
>
> C89-vs-99 example with memcpy():
>
> In C89, by my understanding, the following would have been perfectly defined:
>
> struct s1 { int key; };
> struct s2 { int key; int data[4]; };
>
> struct s2 s2_inst = {23, {1,2,3,4}} ;
>
> void *p1 = malloc(sizeof (struct s1*));
> void *p2 = malloc(sizeof (struct s2*));
> *(struct s2**)p2 = &s2_inst;
>
> memcpy(p1,p2, sizeof (struct s1*)); // Pointers to structs have same size
>
> printf("%d", (*(struct s1**)p1)->key);
>
> In c89, the memcpy would allow &s2_inst to be used as a (struct s1*), which
> could in turn be used to access the "key" field of struct s2_inst. In c99,
> however, the memcpy would set the effective type of *p1 to (struct s2) so
> attempting to use it as a (struct s1*) would invoke Undefined Behavior.
>
> Am I incorrect in thinking that the above code was 100% legal and defined in
> C89, and Undefined in C99?
C89's rules are all about the declared types of objects, so I don't
think it has anything to say on the matter of allocated ones. C99's
contribution to this area was to specify what type allocated objects can
be assumed to have and that does not appear to the thing you keep
complaining about. Your beef seems to be with C89 as well as with C99.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-11-15 10:43 +0000 |
| Message-ID | <n29nhd$l32$1@dont-email.me> |
| In reply to | #76050 |
On 14/11/2015 23:46, supercat@casperkitty.com wrote: > Am I being overly alarmist, or am I misunderstanding what's going on, or > what? I think the first! I actually can't follow most of your posts, but according to you C is not fit for purpose and never has been. Probably no other higher level language is either as generally they have less of the control you seem to want. And lower level ones would mean using assembly code. Yet people have successfully been programming computers, including microprocessors, with languages such as C, for decades. So what's gone right? > The rationale given for C89 was to allow the compiler to keep things > in registers while performing operations in the given sequence. The point of using C is that /you don't have to worry about all this stuff/. > In any case, I see no issue why the Standard shouldn't provide some means of > specifying "memory barriers"? No, let's have a more up-to-date means of printing first! (And 99 other things of more immediate and tangible benefit.) > Am I incorrect in thinking that the above code was 100% legal and defined in > C89, and Undefined in C99? If C89 code has become undefined in later versions, possibly it is due to aggressive optimisations in modern compilers putting the spotlight on certain dubious practices. In which case C89 code would still have problems if you used the newer compiler. In that case you need to follow the rules. The Standard seems to do a good job of advising how to write code that will always work. But you have to read between the lines to know if you can get away with something on your hardware. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-11-15 13:19 -0800 |
| Message-ID | <0966edb0-3ce9-419b-a578-30702dfe9fba@googlegroups.com> |
| In reply to | #76085 |
On Sunday, November 15, 2015 at 4:44:23 AM UTC-6, Bart wrote: > I think the first! I actually can't follow most of your posts, but > according to you C is not fit for purpose and never has been. I don't believe that a C implementation which was designed to strictly conform to the Standard but was designed capriciously in every way that it could be while retaining conformance would be usable for much of anything. The reason the C family of dialects has historically been useful is that almost all compilers handle some dialect that includes features and guarantees beyond what the Standard requires. Unfortunately, even though there is a lot of code which wouldn't have a hope of working usefully on any compiler which doesn't offer guarantees beyond those given by the Standard--not only with regard to UB, but also IB--the Standards Committee has made essentially zero effort to recognize even some of the most common guarantees. As a simple example, there is a lot of code that assumes that a 32-bit word will contain four groups of eight consecutive bits stored in one of four permutations of four bytes (either ABCD, BADC, CDAB, or DCBA). I doubt if there has ever been a machine where CHAR_BITS was 8 but bits are stored in some other order, but nothing in the Standard would forbid an implementation from permuting bits in some other fashion. Should code which requires that machines use one of the four indicated byte-to-word mappings be considered "non-portable"? > Probably no other higher level language is either as generally they have > less of the control you seem to want. A lot of them offer semantically more power, however. In Java or .NET languages, given a method which accepts an array of references to a base type, one can pass that method an array of references to a a derived type provided that one doesn't attempt to store any base-type objects into the derived-type array. In old C, one could achieve such semantics easily; the language would demand a typecast when converting a double-indirect pointer to one kind of structure into a double-indirect pointer to the other, but once that was done code could use the double-indirect pointer as an array of pointers to a structure whose members are all part of the initial sequence of the type used by the actual array. > Yet people have successfully been programming computers, including > microprocessors, with languages such as C, for decades. So what's gone > right? Compilers which have option flags for things like -fno-strict-aliasing. Do you know of any operating system which is as complex as Unix which will work correctly when compiled on gcc without -fno-strict-aliasing? Many people seem to take the attitude that only "bad" code should need to use -fno-strict-aliasing. I maintain that the ability to disable the strict aliasing rules (or, at minimum, a standard means by which code can refuse compilation if aliasing requirements are stricter than what the code is going to be able to handle) is so important that it should be part of the Standard. > > The rationale given for C89 was to allow the compiler to keep things > > in registers while performing operations in the given sequence. > > The point of using C is that /you don't have to worry about all this stuff/. The purpose of C was to free the programmer from having to worry about what's happening at the register level, and focus on the level of what's in memory. I would consider that a very useful level of abstraction for many purposes. If a language isn't going to require that memory be committed to use as a particular type, it should have strongly-typed allocation primitives. I have no problem with the idea that if code says `x = new Fnord();` that the memory allocated by that statement must only be used as type Fnord. The problem is that rather than define a compiler intrinsic to return strongly-typed memory, C tried to re-purpose features which returned loosly-typed memory. > > In any case, I see no issue why the Standard shouldn't provide some means of > > specifying "memory barriers"? > > No, let's have a more up-to-date means of printing first! (And 99 other > things of more immediate and tangible benefit.) Can you point me to examples of operating systems which will work under C's type rules? If not, I would suggest the lack of such systems as evidence that C as defined by the Standard is semantically too weak for the purpose that K&R created C. > > Am I incorrect in thinking that the above code was 100% legal and defined in > > C89, and Undefined in C99? > > If C89 code has become undefined in later versions, possibly it is due > to aggressive optimisations in modern compilers putting the spotlight on > certain dubious practices. In which case C89 code would still have > problems if you used the newer compiler. Setting aside the question of what implementations do or not do, nothing I've noticed in C89 stated that using memcpy to copy a block of memory to a non-overlapping region was semantically different from doing a character- by-character copy, and the rationale for the character-type exception to the aliasing rules was to allow for such actions. Is there something in C89 that I missed? Besides, in the real world, if a badly-written law gets passed which is supposed to outlaw some troublesome activity, but as written outlaws a common activity, but for 20 years those charged with enforcing it exercise judgment and only enforce it against those who are causing trouble, does that mean that if someone starts rigidly enforcing the law strictly people should have no right to complain, since they'd been living under that law for 20 years, or should people instead say that the law they'd actually been living under was one which only forbade the troublesome activities?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-11-14 15:43 -0800 |
| Message-ID | <lnsi48m9jb.fsf@kst-u.example.com> |
| In reply to | #75998 |
supercat@casperkitty.com writes:
[...]
> So far as I can tell, the type rules in C99 make C totally unsuitable for
> the purposes for which it was designed, and would make many kinds of embedded
> programming totally impossible except on compilers that ignore them.
[...]
And yet C is used for such purposes all the time, and I haven't seen
much of a demand for compilers that behave in the way you advocate.
--
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 Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-11-15 23:50 +0100 |
| Message-ID | <n2b23d$2n1$1@dont-email.me> |
| In reply to | #75998 |
On 14/11/15 15:26, supercat@casperkitty.com wrote: > On Friday, November 13, 2015 at 7:07:13 PM UTC-6, Ben Bacarisse wrote: >> How you imagine that someone just learning to program will conclude that >> not being able to breaking the type rules of C is to be regretted? >> Someone used to writing that sort of C might regret the emergence of >> compilers that no longer do what was replied on, but, surely, a beginner >> is very unlikely to worry that such trickery is not portable. > > So far as I can tell, the type rules in C99 make C totally unsuitable for > the purposes for which it was designed, and would make many kinds of embedded > programming totally impossible except on compilers that ignore them. > It's really strange how I manage to make a living doing many kinds of embedded programming, using C99 and without relying on any assumed effects of undefined behaviour, and using a variety of different compilers (including the epitome of evil, gcc) - despite such programming being totally impossible.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-11-16 00:05 +0000 |
| Message-ID | <n2b6l4$taj$1@news.xmission.com> |
| In reply to | #76137 |
In article <n2b23d$2n1$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 14/11/15 15:26, supercat@casperkitty.com wrote: >> On Friday, November 13, 2015 at 7:07:13 PM UTC-6, Ben Bacarisse wrote: >>> How you imagine that someone just learning to program will conclude that >>> not being able to breaking the type rules of C is to be regretted? >>> Someone used to writing that sort of C might regret the emergence of >>> compilers that no longer do what was replied on, but, surely, a beginner >>> is very unlikely to worry that such trickery is not portable. >> >> So far as I can tell, the type rules in C99 make C totally unsuitable for >> the purposes for which it was designed, and would make many kinds of embedded >> programming totally impossible except on compilers that ignore them. >> > >It's really strange how I manage to make a living doing many kinds of >embedded programming, using C99 and without relying on any assumed >effects of undefined behaviour, and using a variety of different >compilers (including the epitome of evil, gcc) - despite such >programming being totally impossible. > That's because we know that you are very smart. As I noted in another post, a while back, it is pretty clear that you are way over-qualified for your job. You are much smarter than you need to be, i.e., you are much smarter than your colleagues. -- People seem to think that Youtube (and Facebook and Twitter and so on) is (are) some sort of resource created for the public good. Why they delude themselves into believing this is beyond my ability to comprehend. Usenet will always be here. Longer than people remember what port 80 was for.
[toc] | [prev] | [next] | [standalone]
Page 1 of 10 [1] 2 3 … 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web