Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #12065 > unrolled thread
| Started by | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| First post | 2011-10-25 00:44 +0000 |
| Last post | 2011-11-04 14:51 -0700 |
| Articles | 20 on this page of 90 — 25 participants |
Back to article view | Back to comp.lang.c
John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-10-25 00:44 +0000
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-25 01:27 -0700
Re: John McCarthy died today. Kleuskes & Moos <kleuske@somewhere.else.net> - 2011-10-25 09:27 +0000
Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-10-25 11:27 +0100
Re: John McCarthy died today. Ark <akhasin@macroexpressions.com> - 2011-10-29 13:33 -0400
Re: John McCarthy died today. Willem <willem@toad.stack.nl> - 2011-10-29 17:51 +0000
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-29 21:28 +0300
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-10-29 11:57 -0700
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-10-30 08:20 -0700
Re: John McCarthy died today. Ark <akhasin@macroexpressions.com> - 2011-11-04 05:20 -0400
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 15:53 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-04 12:16 -0400
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 17:58 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-04 20:49 -0400
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 01:55 +0000
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-07 10:54 +0000
Re: John McCarthy died today. "Charles Richmond" <netnews@aquaporin4.com> - 2011-11-07 07:36 -0600
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-07 19:49 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-07 15:49 -0500
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-08 00:38 -0800
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 07:05 -0500
Re: John McCarthy died today. lawrence.jones@siemens.com - 2011-11-08 09:12 -0500
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 16:48 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 12:12 -0500
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:27 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 14:10 -0800
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 17:16 -0500
Re: John McCarthy died today. lawrence.jones@siemens.com - 2011-11-09 13:51 -0500
Re: Looping Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-11-09 19:21 -0700
Re: Looping Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 02:34 +0000
Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-08 17:49 -0500
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 16:35 -0800
Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-09 01:08 -0500
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 01:26 -0800
Re: John McCarthy died today. Joe Wright <joewwright@comcast.net> - 2011-11-09 08:18 -0500
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:32 -0800
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 01:24 -0800
Re: John McCarthy died today. Quentin Carbonneaux <qcarbonn@invalid.com> - 2011-11-09 11:59 +0000
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-09 05:34 -0800
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-08 18:31 +0200
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 14:06 -0800
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-08 02:01 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 23:16 -0800
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 05:18 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-07 23:17 -0800
Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-08 01:46 -0800
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-08 13:02 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 14:19 -0800
Re: John McCarthy died today. Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-08 22:23 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 18:13 -0500
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:38 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-08 23:18 +0000
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 12:40 +0200
Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-10 11:39 +0000
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-10 12:23 +0000
Re: John McCarthy died today. 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-10 05:38 -0800
Re: John McCarthy died today. Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-10 17:29 +0200
Re: John McCarthy died today. David Thompson <dave.thompson2@verizon.net> - 2011-11-21 02:39 -0500
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-08 16:34 -0800
Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 01:37 -0800
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:25 -0800
Re: John McCarthy died today. Ian Collins <ian-news@hotmail.com> - 2011-11-10 10:36 +1300
Re: John McCarthy died today. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-09 23:47 -0800
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-10 00:21 -0800
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-10 03:04 -0800
Re: John McCarthy died today. gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-10 15:20 +0000
Re: John McCarthy died today. Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-11-12 23:22 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-13 01:44 +0000
Re: John McCarthy died today. "Charles Richmond" <netnews@aquaporin4.com> - 2011-11-13 04:18 -0600
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-13 16:57 +0000
Re: John McCarthy died today. Robert Wessel <robertwessel2@yahoo.com> - 2011-11-13 11:59 -0600
Re: John McCarthy died today. gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-13 18:54 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-13 14:47 -0800
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-14 03:43 +0000
Re: John McCarthy died today. Ike Naar <ike@sverige.freeshell.org> - 2011-11-14 09:00 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-14 18:30 +0000
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-14 14:44 -0500
Re: John McCarthy died today. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-14 20:13 +0000
Re: John McCarthy died today. Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-14 00:21 -0800
Re: John McCarthy died today. Lauri Alanko <la@iki.fi> - 2011-11-10 15:26 +0000
Re: John McCarthy died today. Kaz Kylheku <kaz@kylheku.com> - 2011-11-10 01:51 +0000
Re: John McCarthy died today. Edward Rutherford <edward.p.rutherford79@REMOVETHIS.gmail.com> - 2011-11-09 17:15 +0000
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-09 18:04 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:31 -0800
Re: John McCarthy died today. Robert Wessel <robertwessel2@yahoo.com> - 2011-11-09 15:53 -0600
Re: John McCarthy died today. "BartC" <bc@freeuk.com> - 2011-11-09 22:02 +0000
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 14:14 -0800
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-09 13:50 -0800
Re: John McCarthy died today. James Kuyper <jameskuyper@verizon.net> - 2011-11-08 07:10 -0500
Re: John McCarthy died today. Keith Thompson <kst-u@mib.org> - 2011-11-04 14:51 -0700
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-09 13:25 -0800 |
| Message-ID | <lnehxhasz6.fsf@nuthaus.mib.org> |
| In reply to | #12946 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Nov 9, 2:34 am, Keith Thompson <ks...@mib.org> wrote:
>>
>> So tell us, how would you address the problem of existing code that
>> uses "=" for assignment, and of new code using ":=" for assignment
>> that would no longer compile with older compilers? Similarly,
>> how would you address the legions of C programmers who believe
>> (rightly or wrongly) that using "=" for assignment and "==" for
>> equality is ok, and doesn't need to be fixed?
>>
> You need to make the change compulsory, so the Luddites will have to
> use old compilers. Otherwise you get a worse mess than the one you
> were trying to solve. The new compiler gives an error, "old style
> assignment operator: please run makenewstyle". So you type
> makenewstyle *.c, and within seconds, all your code compiles.
And you check it all into your source control system, and re-test
everything, and re-release all of it. Updating the source files
is a tiny fraction of the overhead imposed by a change like this.
> There are some potential problems with diff and so on. If you've got a
> decent version control system then the new code is just flagged as a
> "new version", and it's no different to adding a comment, maybe a
> copyright notice to comply with new corporate policy. But there will
> be people for whom having two logically identical but textually
> different source files will be a nuisance. Then for a while there will
> be both old and new compilers in existence. You can't break old code
> without some problems.
>
> However old code with implict int will generate an unacceptable
> cascade of warnings on new compilers. implicit int has just about died
> out, together with old style function declarations. Changes are
> possible.
The use of implicit int was never mandatory. The 1989 ANSI standard
kept the feature. C99 dropped it, but most compilers still accept
it with a warning. And if you change all your old code to declare
return types explicitly, it still compiles with old compilers.
As for old-style function declarations, they're still in the
language, even though they're clearly inferior to prototypes.
Even in the latest C201X draft they're still merely "an obsolescent
feature"; compilers are still required to support them.
In both cases, the changes to source code could be made
incrementally.
Changing "=" to ":=" as you propose is an all-or-nothing change.
If the C201X standard made such a change (it won't), there would
be a transition period of, probably, a couple of decades in which
you could either ignore the new standard altogether (the most
likely outcome for most programmers), *or* you could maintain two
versions of every single C source file. That maintenance could be
largely automated, but there would be as many inconsistent automated
solutions as there are development environments.
Oh, and try getting agreement from the C++ standard committee while
you're at it. And Objective-C (I don't know whether there's a
committee for that, but Objective-C is closely upward-compatible
with C).
If your goal is to kill an future development of the C standard,
making a wide-reaching change like this for fairly trivial benefit
is a good way to do it.
Or here's another idea. Leave "=" the way it is, and let compilers
issue an optional warning when "=" is used in a context where "=="
is probably what was meant.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-11-10 10:36 +1300 |
| Message-ID | <9i0a2cFbi8U1@mid.individual.net> |
| In reply to | #12981 |
On 11/10/11 10:25 AM, Keith Thompson wrote: > Malcolm McLean<malcolm.mclean5@btinternet.com> writes: >> On Nov 9, 2:34 am, Keith Thompson<ks...@mib.org> wrote: >>> >>> So tell us, how would you address the problem of existing code that >>> uses "=" for assignment, and of new code using ":=" for assignment >>> that would no longer compile with older compilers? Similarly, >>> how would you address the legions of C programmers who believe >>> (rightly or wrongly) that using "=" for assignment and "==" for >>> equality is ok, and doesn't need to be fixed? >>> >> You need to make the change compulsory, so the Luddites will have to >> use old compilers. Otherwise you get a worse mess than the one you >> were trying to solve. The new compiler gives an error, "old style >> assignment operator: please run makenewstyle". So you type >> makenewstyle *.c, and within seconds, all your code compiles. > > And you check it all into your source control system, and re-test > everything, and re-release all of it. Updating the source files > is a tiny fraction of the overhead imposed by a change like this. To be fair, you would have to do this for any compiler upgrade. But I do agree this is a silly idea! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2011-11-09 23:47 -0800 |
| Message-ID | <e574be37-94f2-4587-943b-e674d80d6fea@a5g2000vbb.googlegroups.com> |
| In reply to | #12981 |
On Nov 9, 11:25 pm, Keith Thompson <ks...@mib.org> wrote: > > Or here's another idea. Leave "=" the way it is, and let compilers > issue an optional warning when "=" is used in a context where "==" > is probably what was meant. > I've used compilers which did that while(ch = fgetc(fp)) would trigger a warning while( (ch = fgetc(fp)) != 0) would not.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-10 00:21 -0800 |
| Message-ID | <83205f44-2ef4-4f1c-b278-d2be35c7da89@y7g2000vbe.googlegroups.com> |
| In reply to | #12981 |
On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote: <snip> > Changing "=" to ":=" as you propose is an all-or-nothing change. > If the C201X standard made such a change (it won't), there would > be a transition period of, probably, a couple of decades in which > you could either ignore the new standard altogether (the most > likely outcome for most programmers), *or* you could maintain two > versions of every single C source file. That maintenance could be > largely automated, but there would be as many inconsistent automated > solutions as there are development environments. > > Oh, and try getting agreement from the C++ standard committee while > you're at it. And Objective-C (I don't know whether there's a > committee for that, but Objective-C is closely upward-compatible > with C). what about C#, Java, Python or is that just too much? <snip>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-10 03:04 -0800 |
| Message-ID | <ln39dw9r2c.fsf@nuthaus.mib.org> |
| In reply to | #13004 |
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
> On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote:
> <snip>
[...]
>> Oh, and try getting agreement from the C++ standard committee while
>> you're at it. And Objective-C (I don't know whether there's a
>> committee for that, but Objective-C is closely upward-compatible
>> with C).
>
> what about C#, Java, Python
> or is that just too much?
If C made such a change, there would be no particular motivation
for C#, Java, or Python to follow suit. C++ and Objective-C have
C compatibility as a significant selling point.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2011-11-10 15:20 +0000 |
| Message-ID | <j9gq39$odc$1@news.xmission.com> |
| In reply to | #13011 |
In article <ln39dw9r2c.fsf@nuthaus.mib.org>, Keith Thompson <kst-u@mib.org> wrote: >Nick Keighley <nick_keighley_nospam@hotmail.com> writes: >> On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote: >> <snip> >[...] >>> Oh, and try getting agreement from the C++ standard committee while >>> you're at it. And Objective-C (I don't know whether there's a >>> committee for that, but Objective-C is closely upward-compatible >>> with C). >> >> what about C#, Java, Python >> or is that just too much? > >If C made such a change, there would be no particular motivation >for C#, Java, or Python to follow suit. C++ and Objective-C have >C compatibility as a significant selling point. Add AWK & Perl to the list. The point is that one of the selling points of those languages is that the syntax (including the structure and the operators) is C-like. If you change C, then they'd either have to change as well, or lose that selling point. And anyway, isn't it a standard dogma of this group that C and C++ are completely different languages with almost nothing in common? That's what I hear all the time... -- (This discussion group is about C, ...) Wrong. It is only OCCASIONALLY a discussion group about C; mostly, like most "discussion" groups, it is off-topic Rorsharch [sic] revelations of the childhood traumas of the participants...
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2011-11-12 23:22 +0000 |
| Message-ID | <slrnjbtvue.1bk.grahn+nntp@frailea.sa.invalid> |
| In reply to | #13024 |
On Thu, 2011-11-10, Kenny McCormack wrote: ... > And anyway, isn't it a standard dogma of this group that C and C++ are > completely different languages with almost nothing in common? That's what I > hear all the time... They are completely different languages, with a lot in common. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-13 01:44 +0000 |
| Message-ID | <20111112174254.211@kylheku.com> |
| In reply to | #13216 |
On 2011-11-12, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > On Thu, 2011-11-10, Kenny McCormack wrote: > ... >> And anyway, isn't it a standard dogma of this group that C and C++ are >> completely different languages with almost nothing in common? That's what I >> hear all the time... > > They are completely different languages, with a lot in common. Your English dictionary must have something bizarre under the "completely" entry.
[toc] | [prev] | [next] | [standalone]
| From | "Charles Richmond" <netnews@aquaporin4.com> |
|---|---|
| Date | 2011-11-13 04:18 -0600 |
| Message-ID | <j9o5i9$l9i$1@dont-email.me> |
| In reply to | #13223 |
"Kaz Kylheku" <kaz@kylheku.com> wrote in message news:20111112174254.211@kylheku.com... > On 2011-11-12, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >> On Thu, 2011-11-10, Kenny McCormack wrote: >> ... >>> And anyway, isn't it a standard dogma of this group that C and C++ are >>> completely different languages with almost nothing in common? That's >>> what I >>> hear all the time... >> >> They are completely different languages, with a lot in common. > > Your English dictionary must have something bizarre under the "completely" > entry. It is analogous to what George Bernard Shaw said: "England and America are two countries separated by a common language." -- +<><><><><><><><><><><><><><><><><><><>+ | Charles Richmond numerist@aquaporin4.com | +<><><><><><><><><><><><><><><><><><><>+
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-13 16:57 +0000 |
| Message-ID | <20111113084111.100@kylheku.com> |
| In reply to | #13242 |
On 2011-11-13, Charles Richmond <netnews@aquaporin4.com> wrote: > "Kaz Kylheku" <kaz@kylheku.com> wrote in message > news:20111112174254.211@kylheku.com... >> On 2011-11-12, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >>> On Thu, 2011-11-10, Kenny McCormack wrote: >>> ... >>>> And anyway, isn't it a standard dogma of this group that C and C++ are >>>> completely different languages with almost nothing in common? That's >>>> what I >>>> hear all the time... >>> >>> They are completely different languages, with a lot in common. >> >> Your English dictionary must have something bizarre under the "completely" >> entry. > > It is analogous to what George Bernard Shaw said: > > "England and America are two countries separated by a common language." I'm working on a program that can be built either with a C or C++ compiler. Most of the time I forget about this, losing my awareness of "this has to be valid C++ too", and I neglect to build it as C++ for weeks or months. Yet, the C++ port very rarely breaks and is easy to fix. I just tried a C++ build: zero warnings! According to the ChangeLog, the last time I did C++-related maintenance was on Oct 2, which was 131 commits ago. So did 131 commits to a C program without caring that it's also C++, yet it still compiles cleanly as C++. C++ is a very close dialect of C, and can easily be treated as another porting target for a C program.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2011-11-13 11:59 -0600 |
| Message-ID | <h110c75g7f5thgp88m3d1i77u7jh9r2jpa@4ax.com> |
| In reply to | #13253 |
On Sun, 13 Nov 2011 16:57:37 +0000 (UTC), Kaz Kylheku <kaz@kylheku.com> wrote: >On 2011-11-13, Charles Richmond <netnews@aquaporin4.com> wrote: >> "Kaz Kylheku" <kaz@kylheku.com> wrote in message >> news:20111112174254.211@kylheku.com... >>> On 2011-11-12, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >>>> On Thu, 2011-11-10, Kenny McCormack wrote: >>>> ... >>>>> And anyway, isn't it a standard dogma of this group that C and C++ are >>>>> completely different languages with almost nothing in common? That's >>>>> what I >>>>> hear all the time... >>>> >>>> They are completely different languages, with a lot in common. >>> >>> Your English dictionary must have something bizarre under the "completely" >>> entry. >> >> It is analogous to what George Bernard Shaw said: >> >> "England and America are two countries separated by a common language." > >I'm working on a program that can be built either with a C or C++ compiler. >Most of the time I forget about this, losing my awareness of "this has to be >valid C++ too", and I neglect to build it as C++ for weeks or months. > >Yet, the C++ port very rarely breaks and is easy to fix. > >I just tried a C++ build: zero warnings! According to the ChangeLog, the last >time I did C++-related maintenance was on Oct 2, which was 131 commits ago. So >did 131 commits to a C program without caring that it's also C++, yet it still >compiles cleanly as C++. > >C++ is a very close dialect of C, and can easily be treated as another porting >target for a C program. I think that (fairly rare) case has been acknowledged a number of times. The point is that, outside a few specialized requirements, and while you can produce programs that compile under either, C and C++ are sufficiently different languages, such that essentially no meaningful well written C programs could be considered a well written C++ program. IOW, good C code is bad C++ code, even if it does compile and run under the latter.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2011-11-13 18:54 +0000 |
| Message-ID | <j9p3po$t26$1@news.xmission.com> |
| In reply to | #13253 |
In article <20111113084111.100@kylheku.com>, Kaz Kylheku <kaz@kylheku.com> wrote: ... >C++ is a very close dialect of C, and can easily be treated as another porting >target for a C program. uh oh. Kiki isn't going to like this... -- Just for a change of pace, this sig is *not* an obscure reference to comp.lang.c...
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2011-11-13 14:47 -0800 |
| Message-ID | <lnobwf4p2d.fsf@nuthaus.mib.org> |
| In reply to | #13253 |
Kaz Kylheku <kaz@kylheku.com> writes:
[...]
> I'm working on a program that can be built either with a C or C++ compiler.
> Most of the time I forget about this, losing my awareness of "this has to be
> valid C++ too", and I neglect to build it as C++ for weeks or months.
[...]
Out of curiosity, why are you doing this? What advantage do you gain
by writing code that can compile in either language? Conversely,
what would you lose by not worrying at all about C++ compatibility
(go ahead and call that variable "class" if you like)?
My impression is that the actual need for this is much rarer than
many people seem to think it is. (I do not include you in those
"many people").
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-14 03:43 +0000 |
| Message-ID | <20111113191456.538@kylheku.com> |
| In reply to | #13258 |
On 2011-11-13, Keith Thompson <kst-u@mib.org> wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
> [...]
>> I'm working on a program that can be built either with a C or C++ compiler.
>> Most of the time I forget about this, losing my awareness of "this has to be
>> valid C++ too", and I neglect to build it as C++ for weeks or months.
> [...]
>
> Out of curiosity, why are you doing this? What advantage do you gain
> by writing code that can compile in either language?
I can write in a "better C", which is safer, but still compiles with C
compilers.
> Conversely,
> what would you lose by not worrying at all about C++ compatibility
> (go ahead and call that variable "class" if you like)?
One example would be that I can't build the code any more with C++ to check
that all external names are meeting type-safe linkage and the one-definition
rule.
In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
in another. It will link.
If you change a C program such that a function has different parameters, but
due to some broken dependencies in your build system, some dependent modules
are not recompiled, you will get a broken link. Of course, it goes away
if you do a complete rebuild, but you could waste time chasing a bug
which isn't there.
This is fixed in C++: it will catch your broken build system. Type
safe linkage won't let an int (int, char *) call go to an
int (int, char *, char *) function.
(Ironically, I had such a problem recently and didn't catch it because
I had the project configured for the C compiler!)
The real question is, why not break away from C compatibility
and just use arbitrary C++?
That's the real reason for doing this: portability. I believe that C compilers
are still more widely available. Also more widely installed. If we look at just
GNU/Linux systems, g++ will never be present without gcc. But gcc will be
present without g++.
By the way, coding this way may come upon you as a feature request
from users! Years ago I developed that Kazlib library and I made sure
the headers were squeaky clean for C++ use.
But what did some people do? They took the .c files into their C++ projects and
compiled them as C++. So I got e-mails like, "hey your code breaks C++,
can we patch it".
This is probably one niche area where you need to write
in this common dialect: whitebox-reuse libraries that can be dropped
into C or C++ projects.
That's probably when I became more receptive to the idea that hey;
you can write C and C++ at the same time.
> My impression is that the actual need for this is much rarer than
> many people seem to think it is. (I do not include you in those
> "many people").
It's usually not a need, but an easily obtained "nice to have".
You won't see this done very often not because it is awkward or cumbersome
(which it isn't) but because (no surprise) most of the development world
doesn't really care about portability at all, let alone portability of C++ code
to C compilers.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@sverige.freeshell.org> |
|---|---|
| Date | 2011-11-14 09:00 +0000 |
| Message-ID | <slrn3vfsjc1m4l.34h.ike@sverige.freeshell.org> |
| In reply to | #13261 |
On 2011-11-14, Kaz Kylheku <kaz@kylheku.com> wrote:
> One example would be that I can't build the code any more with C++ to check
> that all external names are meeting type-safe linkage and the one-definition
> rule.
>
> In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
> in another. It will link.
>
> If you change a C program such that a function has different parameters, but
> due to some broken dependencies in your build system, some dependent modules
> are not recompiled, you will get a broken link. Of course, it goes away
> if you do a complete rebuild, but you could waste time chasing a bug
> which isn't there.
>
> This is fixed in C++: it will catch your broken build system. Type
> safe linkage won't let an int (int, char *) call go to an
> int (int, char *, char *) function.
Using a C++ compiler (GCC 4.1.2), the following:
/* a.cxx */
extern int x;
int main() { return x; }
/* b.cxx */
struct foo { double d; } x;
compiles/links (c++ -ansi -pedantic -Wall a.cxx b.cxx)
and runs without any complaints.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-14 18:30 +0000 |
| Message-ID | <20111114101818.819@kylheku.com> |
| In reply to | #13265 |
On 2011-11-14, Ike Naar <ike@sverige.freeshell.org> wrote:
> On 2011-11-14, Kaz Kylheku <kaz@kylheku.com> wrote:
>> One example would be that I can't build the code any more with C++ to check
>> that all external names are meeting type-safe linkage and the one-definition
>> rule.
>>
>> In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
>> in another. It will link.
>>
>> If you change a C program such that a function has different parameters, but
>> due to some broken dependencies in your build system, some dependent modules
>> are not recompiled, you will get a broken link. Of course, it goes away
>> if you do a complete rebuild, but you could waste time chasing a bug
>> which isn't there.
>>
>> This is fixed in C++: it will catch your broken build system. Type
>> safe linkage won't let an int (int, char *) call go to an
>> int (int, char *, char *) function.
>
> Using a C++ compiler (GCC 4.1.2), the following:
>
> /* a.cxx */
> extern int x;
> int main() { return x; }
>
> /* b.cxx */
> struct foo { double d; } x;
>
> compiles/links (c++ -ansi -pedantic -Wall a.cxx b.cxx)
> and runs without any complaints.
Ah yes, g++ is broken in this regard.
But the ODR still kicks in.
In a program where there are duplicate uses of an external name like this,
there are likely to be multiple definitions. E.g. two modules in some large
program both happen to use a global variable x.
Perhaps two developers did parallel commits in different modules, both
introducing it, and you, the build master, pull both changes from the repo.
$ cat a.cc
int x;
$ cat b.cc
struct foo { int a; } x;
int main()
{
}
$ g++ a.cc b.cc
/tmp/ccJExOCi.o:(.bss+0x0): multiple definition of `x'
/tmp/ccbKi3U5.o:(.bss+0x0): first defined here
collect2: ld returned 1 exit status
So at least there is that. Of course if one module, by mistake, neglects to
define its global, then the ball gets by the goalkeeper, so to peak.
If these changes are made separately (e.g. two developers in separate
sandboxes) the one with the missing definition will hopefully catch it, since
it doesn't link.
But change to C:
$ cp a.cc a.c
$ cp b.cc b.c
$ gcc a.c b.c
Multiple defs; not a peep.
If "perfect" is not available, I will still take "better".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2011-11-14 14:44 -0500 |
| Message-ID | <4EC16F88.9000908@verizon.net> |
| In reply to | #13299 |
On 11/14/2011 01:30 PM, Kaz Kylheku wrote:
> On 2011-11-14, Ike Naar <ike@sverige.freeshell.org> wrote:
>> On 2011-11-14, Kaz Kylheku <kaz@kylheku.com> wrote:
>>> One example would be that I can't build the code any more with C++ to check
>>> that all external names are meeting type-safe linkage and the one-definition
>>> rule.
>>>
>>> In C, I can have "extern int x;" in in one module, and "struct foo x = { 0 };"
>>> in another. It will link.
>>>
>>> If you change a C program such that a function has different parameters, but
>>> due to some broken dependencies in your build system, some dependent modules
>>> are not recompiled, you will get a broken link. Of course, it goes away
>>> if you do a complete rebuild, but you could waste time chasing a bug
>>> which isn't there.
>>>
>>> This is fixed in C++: it will catch your broken build system. Type
>>> safe linkage won't let an int (int, char *) call go to an
>>> int (int, char *, char *) function.
>>
>> Using a C++ compiler (GCC 4.1.2), the following:
>>
>> /* a.cxx */
>> extern int x;
>> int main() { return x; }
>>
>> /* b.cxx */
>> struct foo { double d; } x;
>>
>> compiles/links (c++ -ansi -pedantic -Wall a.cxx b.cxx)
>> and runs without any complaints.
>
> Ah yes, g++ is broken in this regard.
>
> But the ODR still kicks in.
There's only one definition of 'foo' in this program; the one in b.cxx.
a.cxx only contains a declaration of the object. Even if this were a
violation of the ODR, section 3.2p3 of the C++ standard says, very
explicitly, "no diagnostic required", which would make it no different
from C in this regard.
The relevant rule is actually in section 3.5p10 of the C++ standard:
"... the types specified by all declarations referring to a given object
or function shall be identical, ...", but in that case, too, it says
very explicitly that "A violation of this rule on type identity does not
require a diagnostic." So again, it's no different from C.
If some C++ compilers provide diagnostics that are not required, that's
a feature of those particular compilers, not a feature of the C++
language itself, and a feature that could have been put into C compilers.
(all citations are from n3035.pdf, which is the closest thing I have to
the actual C++ standard that is readily available. However, I don't
believe that either of these citations are significantly different from
previous versions of the standard, nor from more recent drafts of the
next standard).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2011-11-14 20:13 +0000 |
| Message-ID | <0.905013d4c702c207ec5e.20111114201316GMT.87obwev4wz.fsf@bsb.me.uk> |
| In reply to | #13299 |
Kaz Kylheku <kaz@kylheku.com> writes:
> On 2011-11-14, Ike Naar <ike@sverige.freeshell.org> wrote:
<snip>
>> Using a C++ compiler (GCC 4.1.2), the following:
>>
>> /* a.cxx */
>> extern int x;
>> int main() { return x; }
>>
>> /* b.cxx */
>> struct foo { double d; } x;
>>
>> compiles/links (c++ -ansi -pedantic -Wall a.cxx b.cxx)
>> and runs without any complaints.
>
> Ah yes, g++ is broken in this regard.
>
> But the ODR still kicks in.
>
> In a program where there are duplicate uses of an external name like this,
> there are likely to be multiple definitions. E.g. two modules in some large
> program both happen to use a global variable x.
<snip>
> But change to C:
>
> $ cp a.cc a.c
> $ cp b.cc b.c
> $ gcc a.c b.c
>
> Multiple defs; not a peep.
>
> If "perfect" is not available, I will still take "better".
-fno-common is handy for this.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Nick Keighley <nick_keighley_nospam@hotmail.com> |
|---|---|
| Date | 2011-11-14 00:21 -0800 |
| Message-ID | <9c7b5e84-6237-4e4b-8178-466cf14addcb@x7g2000yqb.googlegroups.com> |
| In reply to | #13253 |
On Nov 13, 4:57 pm, Kaz Kylheku <k...@kylheku.com> wrote: > On 2011-11-13, Charles Richmond <netn...@aquaporin4.com> wrote: > > > > > > > "Kaz Kylheku" <k...@kylheku.com> wrote in message > >news:20111112174254.211@kylheku.com... > >> On 2011-11-12, Jorgen Grahn <grahn+n...@snipabacken.se> wrote: > >>> On Thu, 2011-11-10, Kenny McCormack wrote: > >>> ... > >>>> And anyway, isn't it a standard dogma of this group that C and C++ are > >>>> completely different languages with almost nothing in common? That's > >>>> what I > >>>> hear all the time... > > >>> They are completely different languages, with a lot in common. > > >> Your English dictionary must have something bizarre under the "completely" > >> entry. > > > It is analogous to what George Bernard Shaw said: > > > "England and America are two countries separated by a common language." > > I'm working on a program that can be built either with a C or C++ compiler. > Most of the time I forget about this, losing my awareness of "this has to be > valid C++ too", and I neglect to build it as C++ for weeks or months. > > Yet, the C++ port very rarely breaks and is easy to fix. > > I just tried a C++ build: zero warnings! According to the ChangeLog, the last > time I did C++-related maintenance was on Oct 2, which was 131 commits ago. So > did 131 commits to a C program without caring that it's also C++, yet it still > compiles cleanly as C++. > > C++ is a very close dialect of C, and can easily be treated as another porting > target for a C program. "the C subset of C++ is a very close dialect of C..."
[toc] | [prev] | [next] | [standalone]
| From | Lauri Alanko <la@iki.fi> |
|---|---|
| Date | 2011-11-10 15:26 +0000 |
| Message-ID | <j9gqfr$drq$2@oravannahka.helsinki.fi> |
| In reply to | #13004 |
In article <83205f44-2ef4-4f1c-b278-d2be35c7da89@y7g2000vbe.googlegroups.com>, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote: > On Nov 9, 9:25 pm, Keith Thompson <ks...@mib.org> wrote: > > Changing "=" to ":=" as you propose is an all-or-nothing change. > > Oh, and try getting agreement from the C++ standard committee while > > you're at it. > what about C#, Java, Python > or is that just too much? Python does not have assignment expressions, so the issue is moot. Lauri
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web