Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #65653 > unrolled thread
| Started by | doctor@doctor.nl2k.ab.ca (The Doctor) |
|---|---|
| First post | 2015-07-15 20:40 +0000 |
| Last post | 2015-07-16 09:55 +1200 |
| Articles | 20 on this page of 182 — 21 participants |
Back to article view | Back to comp.lang.c
SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 20:40 +0000
Re: SQL filesortcc question Paavo Helde <myfirstname@osa.pri.ee> - 2015-07-15 16:08 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-15 17:15 -0400
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-15 23:22 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 18:35 +0200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 17:48 +0100
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 19:38 +0200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question jacobnavia <jacob@jacob.remcomp.fr> - 2015-07-16 22:17 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-16 21:44 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:51 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:05 +1200
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 11:36 -0400
Re: SQL filesortcc question The Doctor <doctor@doctor.nl2k.ab.ca> - 2015-07-17 22:22 +0000
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-17 18:44 -0400
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-18 11:13 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-16 22:06 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:52 +0000
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-17 01:24 +0100
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-17 00:26 +0000
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 23:50 +0000
Re: SQL filesortcc question John Bode <jfbode1029@gmail.com> - 2015-07-31 13:39 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:48 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-17 09:07 +1200
Re: SQL filesortcc question Philip Lantz <prl@canterey.us> - 2015-07-16 16:05 -0700
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-16 17:28 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-20 11:13 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-20 19:27 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-21 08:46 +1200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:12 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:55 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:01 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:51 +1200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:02 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-27 23:35 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 14:16 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:49 +0100
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-27 23:25 -0500
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-28 09:32 +0000
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-28 10:22 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-27 22:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 04:57 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 16:38 +1200
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-28 00:51 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 07:06 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 20:32 +1200
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-28 10:02 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-28 22:08 +1200
Re: SQL filesortcc question David Kleinecke <dkleinecke@gmail.com> - 2015-07-28 18:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 12:14 -0400
Re: SQL filesortcc question Martin Shobe <martin.shobe@yahoo.com> - 2015-07-29 11:27 -0500
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 13:01 -0400
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-29 17:33 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 21:07 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-29 16:33 -0400
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-29 22:12 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-29 23:50 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 00:13 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 01:49 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 02:07 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 03:04 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 08:25 +0100
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-30 09:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:17 +0100
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 17:00 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 17:12 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 15:12 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 23:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 10:29 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-31 08:10 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 11:12 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-31 22:56 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-31 18:34 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 13:55 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 07:13 -0700
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-01 15:36 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 09:19 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 18:16 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 15:30 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-02 09:00 -0400
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-02 09:19 -0400
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:23 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:35 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:11 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 10:28 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 09:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 00:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 13:55 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 07:03 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-03 16:53 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 09:19 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 21:20 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 14:07 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 12:24 +0200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-06 13:49 +0100
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-06 15:41 +0200
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-07 07:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-09-07 17:04 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-02 06:48 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 08:00 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 08:52 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 11:56 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-04 23:45 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-05 08:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:00 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 13:17 -0700
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-08-01 16:11 -0400
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 14:00 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:40 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:20 -0700
Re: SQL filesortcc question Rosario19 <Ros@invalid.invalid> - 2015-08-22 08:24 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-22 19:26 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 05:39 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 13:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 10:38 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:14 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 01:15 +0200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 16:24 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 02:32 +0200
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-08-02 12:57 +1200
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-08-01 22:23 -0700
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:21 -0500
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-08-02 19:21 +0200
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 14:05 -0500
Re: SQL filesortcc question Robert Wessel <robertwessel2@yahoo.com> - 2015-08-02 01:24 -0500
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-01 23:56 -0700
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-08-09 14:25 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:19 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-29 19:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 23:45 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-30 04:22 -0700
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:13 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 13:27 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 13:57 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 14:11 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:39 +0100
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-07-30 15:05 +0100
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 14:03 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-07-30 11:22 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-29 18:32 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 14:38 +1200
Re: SQL filesortcc question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-07-30 10:56 +0100
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-30 22:28 +1200
Re: SQL filesortcc question Bartc <bc@freeuk.com> - 2015-07-30 10:57 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-03 08:02 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-03 08:33 -0700
Re: SQL filesortcc question Richard Damon <Richard@Damon-Family.org> - 2015-08-03 20:50 -0400
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 04:52 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:08 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:20 +0100
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-04 06:45 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 12:15 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-03 19:09 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-08-04 06:09 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-08-04 14:40 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-05 13:24 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-05 21:51 +0100
Re: SQL filesortcc question James Kuyper <jameskuyper@verizon.net> - 2015-09-05 17:16 -0400
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-09-05 19:59 -0700
Re: SQL filesortcc question Richard Heathfield <rjh@cpax.org.uk> - 2015-09-06 07:51 +0100
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 17:32 -0700
Re: SQL filesortcc question Tim Rentsch <txr@alumni.caltech.edu> - 2015-07-25 10:04 -0700
Re: SQL filesortcc question David Brown <david.brown@hesbynett.no> - 2015-07-21 13:23 +0200
Re: SQL filesortcc question raltbos@xs4all.nl (Richard Bos) - 2015-07-22 15:14 +0000
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 15:25 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 11:31 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 17:10 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 13:29 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-25 23:51 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-26 20:24 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 03:02 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 09:22 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:04 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 10:32 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 16:49 -0700
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-27 21:46 +1200
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-27 04:53 -0700
Re: SQL filesortcc question Keith Thompson <kst-u@mib.org> - 2015-07-26 14:58 -0700
Re: SQL filesortcc question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-26 15:15 -0700
Re: SQL filesortcc question doctor@doctor.nl2k.ab.ca (The Doctor) - 2015-07-16 19:47 +0000
Re: SQL filesortcc question Ian Collins <ian-news@hotmail.com> - 2015-07-16 09:55 +1200
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-08-02 12:57 +1200 |
| Message-ID | <d2588mF55b9U3@mid.individual.net> |
| In reply to | #66672 |
David Brown wrote: > But fortunately, that particular MSVC elephant is pretty much dead now, > as far as I understand it, with C99 support in current versions. Mainly thanks to C++14 :) -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-01 22:23 -0700 |
| Message-ID | <lna8uajmbr.fsf@kst-u.example.com> |
| In reply to | #66672 |
David Brown <david.brown@hesbynett.no> writes:
> On 02/08/15 01:24, Malcolm McLean wrote:
[...]
>> The elephant is Windows.
>> Microsoft withheld C99 support from its compiler for a long time.
>> In the hosted world, any routine that purports to be portable but
>> won't compile under a Microsoft system is useless.
>>
>
> For a lot of "portable" code, that elephant was irrelevant - for a great
> deal of C code, the biggest issue with MSVC is lack of POSIX rather than
> lack of C99. And when you want your C99 code to run on Windows you
> could always use gcc (mingw or cygwin), clang, or even Borland.
>
> But fortunately, that particular MSVC elephant is pretty much dead now,
> as far as I understand it, with C99 support in current versions.
Do you have a citation for that? My understanding, as of not
terribly long ago, is that Microsoft was adding *partial* C99 support
to their C compiler -- specifically that they were adding only C99
features that are also C++ features. I think C99 *library* support
is reasonably good (because C++ incorporates the C standard library),
but support for C99 *language* features is still very incomplete.
If Microsoft supports VLAs, flexible array members, restrict,
compound literals, designated initializers, and so forth, then I'll
be pleasantly surprised.
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 01:21 -0500 |
| Message-ID | <6ldrra1l90e5gjkvuivpfb5fkr5i53bcqo@4ax.com> |
| In reply to | #66675 |
On Sat, 01 Aug 2015 22:23:04 -0700, Keith Thompson <kst-u@mib.org> wrote: >David Brown <david.brown@hesbynett.no> writes: >> On 02/08/15 01:24, Malcolm McLean wrote: >[...] >>> The elephant is Windows. >>> Microsoft withheld C99 support from its compiler for a long time. >>> In the hosted world, any routine that purports to be portable but >>> won't compile under a Microsoft system is useless. >>> >> >> For a lot of "portable" code, that elephant was irrelevant - for a great >> deal of C code, the biggest issue with MSVC is lack of POSIX rather than >> lack of C99. And when you want your C99 code to run on Windows you >> could always use gcc (mingw or cygwin), clang, or even Borland. >> >> But fortunately, that particular MSVC elephant is pretty much dead now, >> as far as I understand it, with C99 support in current versions. > >Do you have a citation for that? My understanding, as of not >terribly long ago, is that Microsoft was adding *partial* C99 support >to their C compiler -- specifically that they were adding only C99 >features that are also C++ features. I think C99 *library* support >is reasonably good (because C++ incorporates the C standard library), >but support for C99 *language* features is still very incomplete. That's the case. >If Microsoft supports VLAs, flexible array members, restrict, >compound literals, designated initializers, and so forth, then I'll >be pleasantly surprised. Not as far as I know.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2015-08-02 19:21 +0200 |
| Message-ID | <mpljgg$bf9$1@dont-email.me> |
| In reply to | #66675 |
On 02/08/15 07:23, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 02/08/15 01:24, Malcolm McLean wrote: > [...] >>> The elephant is Windows. >>> Microsoft withheld C99 support from its compiler for a long time. >>> In the hosted world, any routine that purports to be portable but >>> won't compile under a Microsoft system is useless. >>> >> >> For a lot of "portable" code, that elephant was irrelevant - for a great >> deal of C code, the biggest issue with MSVC is lack of POSIX rather than >> lack of C99. And when you want your C99 code to run on Windows you >> could always use gcc (mingw or cygwin), clang, or even Borland. >> >> But fortunately, that particular MSVC elephant is pretty much dead now, >> as far as I understand it, with C99 support in current versions. > > Do you have a citation for that? My understanding, as of not > terribly long ago, is that Microsoft was adding *partial* C99 support > to their C compiler -- specifically that they were adding only C99 > features that are also C++ features. I think C99 *library* support > is reasonably good (because C++ incorporates the C standard library), > but support for C99 *language* features is still very incomplete. > > If Microsoft supports VLAs, flexible array members, restrict, > compound literals, designated initializers, and so forth, then I'll > be pleasantly surprised. > I thought the MSVC support for C99 was better than that now, but I wrote "as far as I understand it" because I knew my understanding was limited here - I don't use MSVC myself. From a quick googling, it looks like MSVS 2013 has support for long long, _Bool, compound literals, designated initialisers, mixing declarations and code, and // comments. I haven't seen any sign of VLAs or flexible array members. Apparently "restrict" is there, but is spelt "__restrict". So with the latest MSVC and perhaps a little bit of extra effort, you can get much of C99 support. Which is not a great situation, but it is better than it used to be.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 14:05 -0500 |
| Message-ID | <2eqsralpore7cl219ecgc410cvjk7iau33@4ax.com> |
| In reply to | #66706 |
On Sun, 02 Aug 2015 19:21:51 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 02/08/15 07:23, Keith Thompson wrote: >> David Brown <david.brown@hesbynett.no> writes: >>> On 02/08/15 01:24, Malcolm McLean wrote: >> [...] >>>> The elephant is Windows. >>>> Microsoft withheld C99 support from its compiler for a long time. >>>> In the hosted world, any routine that purports to be portable but >>>> won't compile under a Microsoft system is useless. >>>> >>> >>> For a lot of "portable" code, that elephant was irrelevant - for a great >>> deal of C code, the biggest issue with MSVC is lack of POSIX rather than >>> lack of C99. And when you want your C99 code to run on Windows you >>> could always use gcc (mingw or cygwin), clang, or even Borland. >>> >>> But fortunately, that particular MSVC elephant is pretty much dead now, >>> as far as I understand it, with C99 support in current versions. >> >> Do you have a citation for that? My understanding, as of not >> terribly long ago, is that Microsoft was adding *partial* C99 support >> to their C compiler -- specifically that they were adding only C99 >> features that are also C++ features. I think C99 *library* support >> is reasonably good (because C++ incorporates the C standard library), >> but support for C99 *language* features is still very incomplete. >> >> If Microsoft supports VLAs, flexible array members, restrict, >> compound literals, designated initializers, and so forth, then I'll >> be pleasantly surprised. >> > >I thought the MSVC support for C99 was better than that now, but I wrote >"as far as I understand it" because I knew my understanding was limited >here - I don't use MSVC myself. > > From a quick googling, it looks like MSVS 2013 has support for long >long, _Bool, compound literals, designated initialisers, mixing >declarations and code, and // comments. I haven't seen any sign of VLAs >or flexible array members. Apparently "restrict" is there, but is spelt >"__restrict". > >So with the latest MSVC and perhaps a little bit of extra effort, you >can get much of C99 support. Which is not a great situation, but it is >better than it used to be. MSVC supports all of C99 that's also C++, but only because they're actually supporting C++, and they had to add that stuff anyway.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2015-08-02 01:24 -0500 |
| Message-ID | <nndrrap0o6b352cbj552b5btrcd7acpn2j@4ax.com> |
| In reply to | #66672 |
On Sun, 02 Aug 2015 02:32:22 +0200, David Brown <david.brown@hesbynett.no> wrote: >On 02/08/15 01:24, Malcolm McLean wrote: >> On Sunday, August 2, 2015 at 12:15:27 AM UTC+1, David Brown wrote: >>> >>> For new machines, there are normally only two realistic, economically >>> viable ways of making a C compiler. You port gcc to the new target, or >>> you port llvm to the new target. I don't expected the C90 parsers of >>> gcc or clang to disappear any time soon. >>> >>> I also have a hard time thinking of systems that have C90 compilers but >>> not C99 compilers - the only ones I know (in the embedded world) are >>> either obsolete long ago, or so weird that any code written for the >>> chips is special and non-portable anyway. Of course, just because a >>> processor or system is obsolete does not mean no one uses it, but >>> personally I don't want my current programming options to be limited by >>> chips that went out of production 10 years ago. >>> >> The elephant is Windows. >> Microsoft withheld C99 support from its compiler for a long time. >> In the hosted world, any routine that purports to be portable but >> won't compile under a Microsoft system is useless. >> > >For a lot of "portable" code, that elephant was irrelevant - for a great >deal of C code, the biggest issue with MSVC is lack of POSIX rather than >lack of C99. And when you want your C99 code to run on Windows you >could always use gcc (mingw or cygwin), clang, or even Borland. > >But fortunately, that particular MSVC elephant is pretty much dead now, >as far as I understand it, with C99 support in current versions. GCC is not really an option for Windows development. Yes, it works after a fashion for porting *nix code, but you'll never get any serious native development usage. It simply doesn't fit well with the rest of the toolchain. ICC is probably the best bet, although now you're needing to spend non-trivial amounts of money.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-01 23:56 -0700 |
| Message-ID | <b2c3cc14-0129-4edb-b54b-28f43a74e622@googlegroups.com> |
| In reply to | #66680 |
On Sunday, August 2, 2015 at 7:24:17 AM UTC+1, robert...@yahoo.com wrote: > On Sun, 02 Aug 2015 02:32:22 +0200, David Brown > > >But fortunately, that particular MSVC elephant is pretty much dead now, > >as far as I understand it, with C99 support in current versions. > > GCC is not really an option for Windows development. Yes, it works > after a fashion for porting *nix code, but you'll never get any > serious native development usage. It simply doesn't fit well with the > rest of the toolchain. > > ICC is probably the best bet, although now you're needing to spend > non-trivial amounts of money. > There's a constant battle between big vendors and people who want portable code. We want to release the same program on Windows and Mac. Neither MS nor Apple are happy with that idea, because if the same programs run anywhere, they lose the ability to brand their offerings. On the other hand, they know that their compilers need to compile serious fundamental maths libraries, because a lot of developers don't have the technical skills to rewrite them from scratch.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-09 14:25 +0000 |
| Message-ID | <55c76257.18970765@news.xs4all.nl> |
| In reply to | #66681 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > There's a constant battle between big vendors and people who want > portable code. We want to release the same program on Windows and > Mac. Neither MS nor Apple are happy with that idea, because if the > same programs run anywhere, they lose the ability to brand their > offerings. Which is daft, because they can bugger up C's portability all they want, there's always Java in a browser window. Which is butt-ugly on every single platform out there, but /ex officio/ has to run equally butt-uglily using the same browser on each platform. Richard
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-07-30 14:19 +1200 |
| Message-ID | <d1tfuaF5hurU1@mid.individual.net> |
| In reply to | #66544 |
Richard Heathfield wrote: > > It is my contention that the extra features of C99 and C11 do not > compensate for the loss of portability and simplicity that is entailed > in adding new features to /any/ language. As I have said elsethread, if > on some occasions I don't need the portability of C90 (and yes, this > does happen), why on earth would I use C99 or C11 when I can use C++? I > see nothing in either C99 or C11 that attracts me. If I want to write, > say, a GUI program, there is a certain satisfaction to be gained from > writing it in C but if I'm even slightly in a hurry to get something up > and running I head straight for C++ like a half-starved bear heads for a > picnic basket. I agree with almost all of what you are saying here. Almost because in my line of programming (embedded/drives/system) there is one feature that gives C99 an edge over C++: designated initialisers. Low level code often contains a number of statically initialised structs (which come from C, so C++ trickery isn't an easy option) and designated initialisers are made for this job. Linux USB code is a good example. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-29 19:53 -0700 |
| Message-ID | <3f47e845-9b8c-40b4-b717-e15ecde17969@googlegroups.com> |
| In reply to | #66543 |
On Thursday, July 30, 2015 at 1:49:33 AM UTC+1, Ben Bacarisse wrote: > > Yes, I get that, but in what way does, say, the presence of type-generic > maths functions in C99 impact on your goal of having anyone compile your > code? You are against making changes to C, but all the reasoning seems > to relate only to why you should not use these new features. > It means it steadily gets harder to integrate other people's code with your own, and then present it in a form that a third set of people will want to use. You don't have a reliable standard any longer. Obviously any code you ship must be in the increasingly narrow subset of all the common standards out there, which can be hard to check. (A recent bit of code broke because I had forgotten to remove M_PI, it's just an irritation, but it means a new version of the file). But increasingly people will ask why they can't use some feature, they don't feel the code is idiomatic any more.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-07-29 23:45 -0700 |
| Message-ID | <ln6152m9eb.fsf@kst-u.example.com> |
| In reply to | #66549 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, July 30, 2015 at 1:49:33 AM UTC+1, Ben Bacarisse wrote:
>> Yes, I get that, but in what way does, say, the presence of type-generic
>> maths functions in C99 impact on your goal of having anyone compile your
>> code? You are against making changes to C, but all the reasoning seems
>> to relate only to why you should not use these new features.
>>
> It means it steadily gets harder to integrate other people's code
> with your own, and then present it in a form that a third set
> of people will want to use. You don't have a reliable standard
> any longer. Obviously any code you ship must be in the increasingly
> narrow subset of all the common standards out there, which can
> be hard to check. (A recent bit of code broke because I had
> forgotten to remove M_PI, it's just an irritation, but it means
> a new version of the file). But increasingly people will ask
> why they can't use some feature, they don't feel the code is
> idiomatic any more.
M_PI is an interesting example, since it's not defined by *any* C
standard.
--
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 | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-07-30 04:22 -0700 |
| Message-ID | <123be446-7723-417d-b8d0-5ae1f5409ec3@googlegroups.com> |
| In reply to | #66551 |
On Thursday, July 30, 2015 at 7:23:49 AM UTC+1, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > M_PI is an interesting example, since it's not defined by *any* C > standard. > It's a trap. I can't remember the digits of Pi beyond the first three, my mind doesn't work like that. So I have to look it up. It's tempting just to write M_PI whilst you're thinking of something else. Then it gets into release code, and it breaks.
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 13:13 +0100 |
| Message-ID | <mpd4b9$1vf$1@dont-email.me> |
| In reply to | #66556 |
On 30/07/2015 13:11, Stefan Ram wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> It's a trap. I can't remember the digits of Pi beyond the first three, >> my mind doesn't work like that. So I have to look it up. It's >> tempting just to write M_PI whilst you're thinking of something >> else. Then it gets into release code, and it breaks. > > pi is 4*atan2(1,1) or 4*atan(1), and e is exp(0) IIRC. exp(1) gives a more accurate value of e than exp(0).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 13:27 +0100 |
| Message-ID | <mpd554$54h$1@dont-email.me> |
| In reply to | #66556 |
On 30/07/15 12:22, Malcolm McLean wrote: > On Thursday, July 30, 2015 at 7:23:49 AM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> M_PI is an interesting example, since it's not defined by *any* C >> standard. >> > It's a trap. It never was for me. The first time I saw it was in a diagnostic message on code I'd inherited. (My compiler didn't recognise it.) I saw no value in the M_ so I replaced every occurrence with PI, which I #defined to 3.14159265358979323846 > I can't remember the digits of Pi beyond the first three, Here are twenty for you (twenty after the point, that is): Sir, I bear a rhyme excelling In mystic force and magic spelling; Celestial sprites elucidate All my own striving can't relate. Even if you can only remember the first /two/ lines of that, it still gives you eleven places after the decimal point. If you take the circumference of the earth as precisely 40 million metres (which is more or less how the metre was supposed to be defined originally), what is the radius? Let's find out, to 20 places, and to 11 places. pi radius of earth (metres) 3.14159265358979323846 6366197.723675813430 3.14159265358 6366197.723695658681 So you're no more than about 20 microns out (very slightly less, actually). Eleven places is plenty for most purposes. > my mind doesn't work like that. So I have to look it up. It's > tempting just to write M_PI whilst you're thinking of something > else. Then it gets into release code, and it breaks. So, ONCE FOR ALL, write yourself a pi.h header: #ifndef H_PI_H #define H_PI_H 1 #define PI 3.14159265358979323846 #endif stick it in your include path, and be done with 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 13:57 +0100 |
| Message-ID | <mpd6s8$bbo$1@dont-email.me> |
| In reply to | #66560 |
On 30/07/2015 13:27, Richard Heathfield wrote: > On 30/07/15 12:22, Malcolm McLean wrote: > Sir, I bear a rhyme excelling > In mystic force and magic spelling; > Celestial sprites elucidate > All my own striving can't relate. Give me a number to memorise any day, instead of poetry! I can't even remember the first line of that. (I knew pi to 127 places once (most of them now forgotten, except for 20 or so at the start). No direct practical use, except that when a lecturer was showing off by writing it to 75 places on the board, I was able to correct him. Although only to suggest the 75th digit should have been rounded up if it stopped there.) > So, ONCE FOR ALL, write yourself a pi.h header: > > #ifndef H_PI_H > #define H_PI_H 1 > #define PI 3.14159265358979323846 > #endif > > stick it in your include path, and be done with it. This doesn't really work, as then your code becomes non-portable. And would cause raised eyebrows if code was posted here full of PIs. Similarly to my posting code using FORs (#define FOR(i,a,b) for(i=a; i<=b; ++i)). You're effectively defining your own mini-C-standard, one shared by no-one else. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 14:11 +0100 |
| Message-ID | <mpd7mt$els$1@dont-email.me> |
| In reply to | #66561 |
On 30/07/15 13:57, Bartc wrote: > On 30/07/2015 13:27, Richard Heathfield wrote: >> On 30/07/15 12:22, Malcolm McLean wrote: > >> Sir, I bear a rhyme excelling >> In mystic force and magic spelling; >> Celestial sprites elucidate >> All my own striving can't relate. > > Give me a number to memorise any day, instead of poetry! I can't even > remember the first line of that. Well, maybe Malcolm is more into mnemonics than you are? If he can't remember more than 3.141, I thought words might be worth a shot. > (I knew pi to 127 places once (most of them now forgotten, except for 20 > or so at the start). 20 works fine for me. Once learned, never forgotten. >> So, ONCE FOR ALL, write yourself a pi.h header: >> >> #ifndef H_PI_H >> #define H_PI_H 1 >> #define PI 3.14159265358979323846 >> #endif >> >> stick it in your include path, and be done with it. > > This doesn't really work, as then your code becomes non-portable. HOW? In the name of all that's holy, how on EARTH is that code non-portable? That is, how is it any more non-portable than /any/ code Malcolm might write? > And > would cause raised eyebrows if code was posted here full of PIs. M_PI sets off clc's reflexes, but I don't see why PI should, especially if its definition is shown. > Similarly to my posting code using FORs (#define FOR(i,a,b) for(i=a; > i<=b; ++i)). No, there's an important difference. You're abusing #define to obfuscate the syntax. All I'm doing is using #define to avoid having a magic number strewn through the code, which is pretty much what most people use it for. > You're effectively defining your own mini-C-standard, one shared by > no-one else. If that's true, it's true every time you write: #define MAX_LEN 32 or anything of the kind. -- 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 14:39 +0100 |
| Message-ID | <mpd9b4$l0c$1@dont-email.me> |
| In reply to | #66564 |
On 30/07/2015 14:11, Richard Heathfield wrote: > On 30/07/15 13:57, Bartc wrote: >> On 30/07/2015 13:27, Richard Heathfield wrote: >>> So, ONCE FOR ALL, write yourself a pi.h header: >>> >>> #ifndef H_PI_H >>> #define H_PI_H 1 >>> #define PI 3.14159265358979323846 >>> #endif >>> >>> stick it in your include path, and be done with it. >> >> This doesn't really work, as then your code becomes non-portable. > > HOW? > > In the name of all that's holy, how on EARTH is that code non-portable? > That is, how is it any more non-portable than /any/ code Malcolm might > write? The problem is introducing this external dependency on pi.h. That's OK when part of a formal project with lots of modules and headers anyway. But it causes problems when writing informal bits of code (such as postings to c.l.c) where you now have to drag in pi.h otherwise it can't be compiled. (Although in the case of PI, people will probably be able to figure what it's meant to be.) >> You're effectively defining your own mini-C-standard, one shared by >> no-one else. > > If that's true, it's true every time you write: > > #define MAX_LEN 32 > > or anything of the kind. No, the difference is in putting it into a private include file. (I could put all my personal C preferences into bart.h. But people are not going to appreciate seeing all those macros in any code I post, even if I provide or link to bart.h.) But also, MAX_LEN is not something which would likely be a built-in to a language, but is rather more specific. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-07-30 15:05 +0100 |
| Message-ID | <mpdarr$qui$1@dont-email.me> |
| In reply to | #66565 |
On 30/07/15 14:39, Bartc wrote: > On 30/07/2015 14:11, Richard Heathfield wrote: >> On 30/07/15 13:57, Bartc wrote: >>> On 30/07/2015 13:27, Richard Heathfield wrote: > >>>> So, ONCE FOR ALL, write yourself a pi.h header: >>>> >>>> #ifndef H_PI_H >>>> #define H_PI_H 1 >>>> #define PI 3.14159265358979323846 >>>> #endif >>>> >>>> stick it in your include path, and be done with it. >>> >>> This doesn't really work, as then your code becomes non-portable. >> >> HOW? >> >> In the name of all that's holy, how on EARTH is that code non-portable? >> That is, how is it any more non-portable than /any/ code Malcolm might >> write? > > The problem is introducing this external dependency on pi.h. I don't get it. > That's OK when part of a formal project with lots of modules and headers > anyway. But it causes problems when writing informal bits of code (such > as postings to c.l.c) where you now have to drag in pi.h otherwise it > can't be compiled. If you really think that's a problem (and I don't), it's one that is easily solved with yy p (or, more generally, copy/paste into scratch source) before recompiling, retesting, and posting to clc for comment. > > (Although in the case of PI, people will probably be able to figure what > it's meant to be.) You'd ha' thunk so, wouldn't you? >>> You're effectively defining your own mini-C-standard, one shared by >>> no-one else. >> >> If that's true, it's true every time you write: >> >> #define MAX_LEN 32 >> >> or anything of the kind. > > No, the difference is in putting it into a private include file. I don't see why. Source is source. It doesn't matter where it goes as long as it's available. > > (I could put all my personal C preferences into bart.h. But people are > not going to appreciate seeing all those macros in any code I post, even > if I provide or link to bart.h.) Yes, but that's nothing to do with them being in a header, and everything to do with them being an attempt to rewrite the language syntax. > But also, MAX_LEN is not something which would likely be a built-in to a > language, but is rather more specific. I don't see how that matters. We all know, don't we, that PI is *not* built into C? -- 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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-07-30 14:03 +0100 |
| Message-ID | <mpd77h$crq$1@dont-email.me> |
| In reply to | #66556 |
On 30/07/2015 12:22, Malcolm McLean wrote: > On Thursday, July 30, 2015 at 7:23:49 AM UTC+1, Keith Thompson wrote: >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >> M_PI is an interesting example, since it's not defined by *any* C >> standard. >> > It's a trap. I can't remember the digits of Pi beyond the first three, > my mind doesn't work like that. So I have to look it up. It's > tempting just to write M_PI whilst you're thinking of something > else. Then it gets into release code, and it breaks. I had something like this in one compiler or other, for a language where 'pi' was a built-in constant: ... pi_value = 3.14159265358979...; This compiler was then compiled with itself, and that line got changed to: ... pi_value = pi; Now, the original definition has completely disappeared from the source code. The problem was that the original pi constant had a typo in the last few digits! But it's now more difficult to trace the error. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2015-07-30 11:22 -0400 |
| Message-ID | <mpdfcp$dcg$1@dont-email.me> |
| In reply to | #66551 |
On 07/30/2015 02:45 AM, Keith Thompson wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: ... >> be hard to check. (A recent bit of code broke because I had >> forgotten to remove M_PI, it's just an irritation, but it means ... > M_PI is an interesting example, since it's not defined by *any* C > standard. It is, however, defined by POSIX: > M_E > [XSI] Value of e > M_LOG2E > [XSI] Value of log2e > M_LOG10E > [XSI] Value of log10e > M_LN2 > [XSI] Value of loge2 > M_LN10 > [XSI] Value of loge10 > M_PI > [XSI] Value of pi > M_PI_2 > [XSI] Value of pi/2 > M_PI_4 > [XSI] Value of pi/4 > M_1_PI > [XSI] Value of 1/pi > M_2_PI > [XSI] Value of 2/pi > M_2_SQRTPI > [XSI] Value of 2/sqrt(pi) > M_SQRT2 > [XSI] Value of sqrt(2) > M_SQRT1_2 > [XSI] Value of 1/ sqrt(2) (I replaced symbols that don't display properly in this window with sqrt() and pi). The XSI notation indicates that these are part of the X/Open System Interface, which you can test for by checking wheteher _XOPEN_UNIX is pre#defined to have a value other than -1. My project allows me to assume POSIX support. This is less useful information for those not allowed to make that assumption. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
Page 7 of 10 — ← Prev page 1 … 5 6 [7] 8 9 10 Next page →
Back to top | Article view | comp.lang.c
csiph-web