Why the C committee doesn't provide an implementation when the standard is published?

[Mark McIntyre]

Why the C standard committee doesn't provide a standard implementation
including the C compiler and library when the language standard
document is published?

Why doesn't the government build a car once they publish emission
laws? Why doesn't the FA own football clubs, once it publishes the
rules? Why don't business analysts develop software, once they've
written the spec?

Answer: the task of definiing how to do something, and the task of
building it, are rightly separate jobs.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[jjf]

They are Obsolete standards. The compilers are NOT C compliant as
defined by ISO. Ie ISO9899:1999 (any other version of ISO9899 is
OBSOLETE)

Agreed. So what? As quoted above, I was responding to the OP's claim
that there are no C compilers which are 100% compliant to the C
Standards as they were 10 years ago.

Why?

Because people who want to write portable code need a standard to do
so, and clearly need compilers which implement that standard. The fact
that C90 and C95 are no longer ISO Standards is not relevant to
anything in the real world. They are very well defined ex-standards
which many compilers implement fully and correctly (and they conformed
to the Standards for as long as those Standards existed, and still
would if the Standards were magically to come back into existence).

The fact that earlier Standards become non-Standard and obsolete when a
new version is published is one of the bigger sillinesses of the ISO
process. The real world almost invariably lags the ISO process in
conformance terms, often by many years. There's no real reason why
compilers couldn't continue to claim formal compliance to the C90
Standard (say) instead of the current theoretical (and silly, and
ignored) situation that all C compilers stopped being Standard C
compilers the moment C99 was published.

Few (if any) Standard C compilers (as formally interpreted by ISO) now
exist, and it looks rather like few ever will unless the C committee
comes to its senses. "Standard C" does exist in the real world,
however, and is defined in terms of conformance to C90, C95, or
whatever.

 

[P.J. Plauger]

You have the problem that on the desktop most(?) users use MS compilers.
MS have stopped doing C and do C++.

But they still offer a compiler used by millions of C programmers.

BTW There is no such language as C/C++.

Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...

C++ was developed from C90 and
diverged one way whilst C went a different way 95 and C99.

Perhaps, but Standard C++ is based on C95. And the next revison of C++
(aka C++0X) has already adopted the *entire* C99 preprocessor, the
*entire* C99 library, and quite a number of C99 language features.
Posix also now requires C99. Maybe the way isn't all that different
in the end.

So C written
in a C++ compiler is not C.

Right, as is often pointed out in the heated subset/superset debates
that erupt spontaneously from time to time. But they're demonstrably
fellow travelers.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction

Well, yes, but they seem to have gotten religion about standards
conformance lately. They haven't done export for C++ yet (because
it's damned hard and next to nobody is asking for it) but they have
yet to proclaim they *aren't* going to do it. Similarly, they have
quite good conformance to C90 and C95, and haven't done C99 (because
once again it takes a lot of work and next to nobody is asking for it).

added to which there is a lot of
use of Java, C# etc and other languages. So there is a lot less interest
in the desktop community to chase the ISO C99 standard that there used
to be when the industry wanted a common specification for the language
and C++ had not arrived.

The embedded community, probably the largest C community there is, is
sticking with C90/5 and not following C99. Most of the embedded world
still use 8 and 16 bit MCU's and most of the embedded standards relate
to C90 anyway.

Mostly true, except for the compiler vendors (desktop and embedded) who
use the EDG front end and Dinkumware libraries, who get full C99 and C++
compliance for free. They don't brag about it because, as mentioned above,
it ain't a selling point.

GNU follows it's own path, though is does have a C90 mode and I think
they are "working towards" C99, but slowly.

In short no one really needed the new features of C99. Some it is
claimed are broken anyway. The maths model for example.

There are many claims about various features of C and C++, with
dubious "real world" justification. Works for me.

The UK C panel has got a bad reputation over the last few years for
saying "NO!" to adding anything to C99 before fixing some of the major
problems in the standard.

No, they've got a bad reputation for saying NO! to damn near everything,
including things they once promised to support. *Nothing* normative has
been added to Standard C since C99 and nothing of that sort is currently
planned. Where's the beef?

In fact there was a suggestion that we Should
go back to C95 and start again! However this has been ignored.

"Considered briefly and properly rejected" is how I'd characterize it.

So in my view (and others on the panel but I will let them speak for
themselves) There is a LOT of DR (defect report) work to be done on C99
before we add anything new to C99.

Probably true, and you should note that the C committee is cooperating
in this approach by working diligently on DRs and not starting a revision
of C99. Where's the beef?

However other panels want to add lots of new things. "Building on
quicksand" as one C panel member said to me. So in my view C99 will
continue to wander off into the wilderness.

ECMA is doing it's own thing with C++

ECMA has standardized an extension to C++ that's highly compatible with
Standard C++, if that's what you mean.

and you are likely to find that
the ISO C++ also goes off into the wilderness in the next few years just
like ISO BASIC.

Could be, but there seem to be people actively implementing what the
C++ committee is standardizing. And in our (Dinkumware's) experience,
there seems to be at least some market for the major additions. The
wilderness isn't empty.

Somewhere along the line ISO C and C++ have lost their way and I am not
sure how to get them back.

Could also be, but if so neither you nor I will "get them back" just
by advancing our own notions of where "back" might be.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jesper]

Chris Hills wrote:

In short no one really needed the new features of C99.

I disagree and I am a bit confused why people are so unhappy about the
C99 standard. I am no expert and I recognise that when people like
Richard Heathfield are not convinced that C99 is any good I should not
either. Also, it is mentioned that some parts may even be broken.
Nevertheless, features like mixed declarations and code, isnan, isinf,
__func__ , variable-length arrays, etc is really nice and in my opinion
very very useful.

The C community is extremely large and every programmer has their own
opinion about how things should be done. Maybe people are even a bit
affectionate about the language and do not wish to see it ruined or
moved in a direction that they do not want it to. But if no one makes
any compromises, no new standard will ever be adopted and the standard
C language will stop at C89.

Regards, Jesper

 

[Frank Silvermann]

Chris Hills wrote:



I disagree and I am a bit confused why people are so unhappy about the
C99 standard. I am no expert and I recognise that when people like
Richard Heathfield are not convinced that C99 is any good I should not
either. Also, it is mentioned that some parts may even be broken.
Nevertheless, features like mixed declarations and code, isnan, isinf,
__func__ , variable-length arrays, etc is really nice and in my opinion
very very useful.

The C community is extremely large and every programmer has their own
opinion about how things should be done. Maybe people are even a bit
affectionate about the language and do not wish to see it ruined or
moved in a direction that they do not want it to. But if no one makes
any compromises, no new standard will ever be adopted and the standard
C language will stop at C89.

The C community is not sufficiently large that things can 'should'.
Only persons can 'should' and Hume's is-ought gap looms as large as
ever. I've now read parts of n1124.pdf and I really don't know what to
think about the normative question. If clc solved it, they would be the
first to do so. frank

 

[Chris Hills]

Agreed. So what? As quoted above, I was responding to the OP's claim
that there are no C compilers which are 100% compliant to the C
Standards as they were 10 years ago.


Because people who want to write portable code

I rarely see portability high on anyone's list out side C.l.c

need a standard to do
so, and clearly need compilers which implement that standard. The fact
that C90 and C95 are no longer ISO Standards is not relevant to
anything in the real world.

It is VERY relevant. In a legal sense in some areas.

They are very well defined ex-standards
which many compilers implement fully and correctly (and they conformed
to the Standards for as long as those Standards existed, and still
would if the Standards were magically to come back into existence).

This is true

The fact that earlier Standards become non-Standard and obsolete when a
new version is published is one of the bigger sillinesses of the ISO
process.

Yes and no. The new one has to supersede the old and in some cases there
are legal requirements to use the current ISO standard. ISO does a lot
more than programming languages.

The real world almost invariably lags the ISO process in
conformance terms, often by many years. There's no real reason why
compilers couldn't continue to claim formal compliance to the C90
Standard (say) instead of the current theoretical (and silly, and
ignored) situation that all C compilers stopped being Standard C
compilers the moment C99 was published.

I agree completely so I got BSI C95 reissued at a sensible price.
Unfortunately they have not run out so I am doing a deal to get the ISO
version revised at a sensible price. It is currently over 150USD

Few (if any) Standard C compilers (as formally interpreted by ISO) now
exist, and it looks rather like few ever will unless the C committee
comes to its senses.

I agree.

"Standard C" does exist in the real world,
however, and is defined in terms of conformance to C90, C95, or
whatever.

I agree, that is the reality that is the practical answer but legally
C99 is the standard and this can cause problems.

 

[Malcolm]

The Vulgate

I was going to say.
There is an obsession with taking decisions in committee. The British
government works that way, so does my Catholic club. So does the Faculty of
Biological Sciences, at least for decisons such as to stop providing milk,
because of tax implications, and take awy the wastepaper bins to encourage
recycling. However my group doesn't take research decision in committee.

There was some research recently that deterimined that when people make
trivial decisions, a considered response is best. However when the decision
is complex and important, first instincts are usally right. Virtually all
politicians work like this - they instinctively know whether it is right to
cut taxes or raise them, because of ideology; they don't look at pages of
closely reasoned economic arguments about inflationary pressures, capacity,
fiscal expansion, and money M0.

 

[Chris Hills]

But they still offer a compiler used by millions of C programmers.

I agree. It is THE de-facto standard on the desktop. That is my point.
Most desktop "C" programmers are in fact using a C++ compiler. As you
have pointed out recently the current crop of MS compilers are very good
and do adhere to the C++ standards.

Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...

I can also find millions of hits to show that Elvis lives, Roswell was a
fake AND that it was real aliens, That the Davinci code is ALL real and
all fake. Also that there are WMD in Iraq... Just because lots of
people believe it does not make it true.

Just because you can find millions of hits on google proves absolutely
nothing. I think it was Robert HeinLein who said "never underestimate
the power of human stupidity".

Perhaps, but Standard C++ is based on C95.

OK and C95 != C99.

And the next revison of C++
(aka C++0X) has already adopted the *entire* C99 preprocessor, the
*entire* C99 library, and quite a number of C99 language features.

That is the *next* version of C++ BTW when is it due out?

Posix also now requires C99. Maybe the way isn't all that different
in the end.


Right, as is often pointed out in the heated subset/superset debates
that erupt spontaneously from time to time. But they're demonstrably
fellow travelers.

Close yes but not the same.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction

Well, yes, but they seem to have gotten religion about standards
conformance lately.

Yes, they have put a lot of work into ECMA and as you have pointed out
become a lot more ISO compliant.

They haven't done export for C++ yet (because
it's damned hard and next to nobody is asking for it)

This is a bit of a recurring theme where no one is pushing for
compatibility with the latest standards.

but they have
yet to proclaim they *aren't* going to do it. Similarly, they have
quite good conformance to C90 and C95, and haven't done C99 (because
once again it takes a lot of work and next to nobody is asking for it).

This is where we all came in. Why does no one (very few) want C99
conformance?

Mostly true,

thanks

except for the compiler vendors (desktop and embedded) who
use the EDG front end and Dinkumware libraries, who get full C99 and C++
compliance for free.

I know. AFAIK most of the major embedded compilers use that combination.
See http://www.edg.com & http://www.dinkumware.com I will put the
advert in for you

As you say they do give C99 but.....

They don't brag about it because, as mentioned above,
it ain't a selling point.

though AFAIK not all of the embedded implimenters do a full C99 back
end.

There are many claims about various features of C and C++, with
dubious "real world" justification. Works for me.

What works for you?

No, they've got a bad reputation for saying NO! to damn near everything,
including things they once promised to support.

I know. Bloody nightmare. But probably not the place to go into it in
detail.

*Nothing* normative has
been added to Standard C since C99 and nothing of that sort is currently
planned. Where's the beef?

Ask the usual suspects.... Though one or two seem to have given up and
wandered off.

"Considered briefly and properly rejected" is how I'd characterize it.

OK. Though you have said there are parts of C99 you wish had not been
put in.

Probably true, and you should note that the C committee is cooperating
in this approach by working diligently on DRs and not starting a revision
of C99. Where's the beef?

They were arguing against adding any TR's or anything else until all the
DR's had been fixed. Also that is Nick's worries about the whole maths
model.

ECMA has standardized an extension to C++ that's highly compatible with
Standard C++, if that's what you mean.

Let's leave that can un-opened. the last thread on it ran to
hundreds of posts and had more heat than light. I can see both sides of
the argument.

Could be,
but there seem to be people actively implementing what the
C++ committee is standardizing. And in our (Dinkumware's) experience,
there seems to be at least some market for the major additions. The
wilderness isn't empty.

That's good. However as MS is the defacto standard on the desktop and
they are going ECMA C++/CLI isn't that where the vast majority of C++
users will go?

Somewhere along the line ISO C and C++ have lost their way and I am not

Could also be, but if so neither you nor I will "get them back" just
by advancing our own notions of where "back" might be.

I think you have more influence than I do in that respect.

Chris

 

[Richard Heathfield]

Chris Hills said:

C99 is the standard and this can cause problems.

Gotta love selective quotation.

<g,d&r>

 

[Mark McIntyre]

Then why does Google give me 61 million hits on C/C++?

Same reason it gives me a million on "martian president" and a scary
eighteen thousand on "gonad sandwich". Google isn't a repository of
correct information. It isn't even a repository of accurate
information. Its merely a huge bucket of all the stuff ever published
on the web.

You're the one who keeps invoking the real world...

Newsflash: google isn't the real world.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[P.J. Plauger]

I rarely see portability high on anyone's list out side C.l.c

Interesting. I've made a living since 1978 supplying people with tools
to write portable code. Not exactly true -- many of our customers are
simply happy we've ported our tools to their favorite platform -- but
a serious fraction of cour customers want and need portability. Not
a one of those customers has ever mentioned C.l.c...

It is VERY relevant. In a legal sense in some areas.

C95 retains some official life if only as the document incorporated
by reference in C++98, the current C++ Standard. But I agree that
ISO's rules for recording tape thickness don't apply nearly as well
to programming languages.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Friedrich Dominicus]

Interesting. I've made a living since 1978 supplying people with tools
to write portable code. Not exactly true -- many of our customers are
simply happy we've ported our tools to their favorite platform -- but
a serious fraction of cour customers want and need portability. Not
a one of those customers has ever mentioned C.l.c...

I'd argue that you'll find that all groups with languages which do
have some official standard do stress portability.

All the other have to run with the masses and re-write their software
every other year.

Regards
Friedrich

 

[P.J. Plauger]

I agree. It is THE de-facto standard on the desktop. That is my point.
Most desktop "C" programmers are in fact using a C++ compiler. As you
have pointed out recently the current crop of MS compilers are very good
and do adhere to the C++ standards.

Not sure what your point is then. AFAIK, *every* C++ compiler is also
a C compiler these days. If each side of the compiler honors its
particular standard well enough, most programmers think of them as two
different compilers implementing two different but closely related
programming languages.

I can also find millions of hits to show that Elvis lives, Roswell was a
fake AND that it was real aliens, That the Davinci code is ALL real and
all fake. Also that there are WMD in Iraq... Just because lots of
people believe it does not make it true.

Just because you can find millions of hits on google proves absolutely
nothing. I think it was Robert HeinLein who said "never underestimate
the power of human stupidity".

Sorry, but it does prove something, human capacity for stupidity
notwithstanding. Google ain't the real world, but it is a first-order
estimator of what's out there. Same for C.l.c. No matter how many
times someone pedantically insists that there is no such language as
C/C++, lots of folks out in the real world continue to use the term
to refer to the mix of code they use to solve real-world problems.

By contrast, I just Googled:

Pascal/Cobol and got one hit in Korean,

Eiffel/PL/I and got two hits, one in Japanese

So those combinations of languages seem to make less sense treated as
a single entity than C and C++. Also, FWIW, I wrote an article a year
or two ago called "The C/C++ Programming Language" which did *not*
drown in derision from subsequent letters to the editor.

There's something there that has meaning to people, deny it as much
as you'd like. Wouldn't it be more helpful to get out of denial and
start considering the role C.l.c. could play in helping the millions
of programmers, managers, etc. who profitably assume that C/C++ is
a term that makes sense?

OK and C95 != C99.

No, but it's a step closer, and it shows that C++ walked alongside
C as far as it could to make a standard published before 1999.

That is the *next* version of C++ BTW when is it due out?

The "0" in C++0X indicates a fervent hope that it'll happen before
2010. (Remember C9X?) And it once again indicates that the languages
are making serious efforts to converge, after several years of
drifting in different directions.

Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
taken this off on their own direction

Well, yes, but they seem to have gotten religion about standards
conformance lately.

Yes, they have put a lot of work into ECMA and as you have pointed out
become a lot more ISO compliant.

They haven't done export for C++ yet (because
it's damned hard and next to nobody is asking for it)

This is a bit of a recurring theme where no one is pushing for
compatibility with the latest standards.

You misunderstand the emphasis. It has almost never been the case ever
that a vendor has aimed for 100 per cent conformance to a programming
language standard. (I say this despite the free use of ANSI and ISO
in advertising.) I remember a decade ago Tom Plum expressing frustration
that he couldn't get any of his customers to eliminate the last three to
five test failures when running their C compilers against his validation
suite. Each had damn good reasons -- usually involving backward
compatibility -- why they wouldn't close the gap completely. With C++,
a way more complex language, the fuzz level is typically measured in
the dozens or hundreds of tests, but the same reasons apply. And both
C++ and C99 have made matters worse by setting such a high bar for
100 per cent conformance that few vendors are motivated to approach that
Apollonian ideal.

Nevertheless, the C and C++ Standards carry weight, if only because
many enterprises insist that *certain* portions of each language
implementation conform closely, and there are tools from Plum Hall and
Perennial to probe those portions. So the paucity of 100 per cent
conforming implementations should not be taken as proof that standards
have failed. Their success these days is just somewhat less absolute
than we all hoped for a decade and a half ago.

This is where we all came in. Why does no one (very few) want C99
conformance?

See above. And other reasons given. C99 is an asymptote these days,
not a pressing goal. Same for C++ (which is also a moving target).

thanks


I know. AFAIK most of the major embedded compilers use that combination.
See http://www.edg.com & http://www.dinkumware.com I will put the
advert in for you

As you say they do give C99 but.....


though AFAIK not all of the embedded implimenters do a full C99 back
end.

I just plain don't know. I've stopped asking folks like Green Hills,
Wind River, etc. what they're going to release when. Practically all
of our support for our OEMs is helping them give their customers what
they want *now*.

What works for you?

All those things in C99 that people say are broken. They also seem to
work for our customers. But what do we know?

I know. Bloody nightmare. But probably not the place to go into it in
detail.


Ask the usual suspects.... Though one or two seem to have given up and
wandered off.

Well, that'll make for a refreshing interlude.

OK. Though you have said there are parts of C99 you wish had not been
put in.

Of course. Every programming language standard has oodles of compromises,
many made for "political" reasons (as if that were a bad thing). I didn't
like all aspects of ANSI C89, yet I voted to approve the final draft.
I certainly didn't like C++98, yet I did the same. I have no trouble
griping about the problems in the standards I try to implement, while
trying at the same time to implement them well and acknowledging a
committee's right to go against the will of any minority. A standard
doesn't have to be 100 per cent lovely, in the eyes of every admirer,
to be useful. Quite the contrary.

They were arguing against adding any TR's or anything else until all the
DR's had been fixed.

At least the TRs are non-normative. And, thanks to the persistence of
John Benito, the WG14 Convener, the DRs are well under control. If there
are still massive flaws not addressed by open DRs, that's the fault of
those who perceive the flaws, not the diligence of WG14.

Also that is Nick's worries about the whole maths
model.

Yes, I've gotten a dose or two of Nick's worries lately. And been
somewhat surprised about what he doesn't know about what he's
criticizing.

That's good. However as MS is the defacto standard on the desktop and
they are going ECMA C++/CLI isn't that where the vast majority of C++
users will go?

Dunno. Maybe. I know quite a few people who use VC++ as a Standard C
and a Standard C++ compiler (I hesitate to say C/C++ here). The lure
of the managed environment will doubtless draw many, but there are
also many who want nontrivial code to work on Windows, Linux, Unix,
and other platforms. The siren call is not always obeyed.

I think you have more influence than I do in that respect.

Perhaps, but much of the time my influence is bugger all. Particularly
in C++. But at least that gives me more opportunities to gripe...

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

Same reason it gives me a million on "martian president" and a scary
eighteen thousand on "gonad sandwich".

No, not quite the same reason. Put quotes around C/C++ (forcing a
more exact match) and you still get 60 million plus hits. Then look
at the first dozen or so hits and pass your own judgment on how
grounded each is in reality. Do the same for "martian president" and
you drop to 89 hits, each as fruity as you'd expect. "gonad sandwich"
gives two hits, by ignoring the punctuation between the words.
(One is more or less sanely medical, the other is demonstrably
random "Greeked" text.) 60 million is not 89 is not 2, no matter
how much rhetorical flair you apply for top spin.

Google isn't a repository of
correct information. It isn't even a repository of accurate
information.

Didn't say it was. But as I mentioned in an earlier posting, it's
a practical and effective first-order indicator of what's out there.
You can then quickly sample the offerings and perform independent
sanity checks on the result.

Its merely a huge bucket of all the stuff ever published
on the web.

Merely? That's quite a resource IME.

Newsflash: google isn't the real world.

It's closer to it than your denial rooted in glib sophistry. And
C/C++ is way more real than a Martian president (or that, uh, other
thing), and you deny its presence in your chosen professional
field at your peril.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Chris Hills]

But they still offer a compiler used by millions of C programmers.


Then why does Google give me 61 million hits on C/C++? You're the
one who keeps invoking the real world...

GWB managed to convince 60 million that there were WMD in Iraq when we
knew there weren't any.

 

[Chris Hills]

Sorry, but it does prove something, human capacity for stupidity
notwithstanding. Google ain't the real world, but it is a first-order
estimator of what's out there. Same for C.l.c. No matter how many
times someone pedantically insists that there is no such language as
C/C++, lots of folks out in the real world continue to use the term
to refer to the mix of code they use to solve real-world problems.

Point taken

There's something there that has meaning to people, deny it as much
as you'd like. Wouldn't it be more helpful to get out of denial and
start considering the role C.l.c. could play in helping the millions
of programmers, managers, etc. who profitably assume that C/C++ is
a term that makes sense?

Well I have been asking for a widening of c.l.c a bit

The "0" in C++0X indicates a fervent hope that it'll happen before
2010. (Remember C9X?)

There was a suggestion from JB that we would have C05 by rolling in the
two TC's

And it once again indicates that the languages
are making serious efforts to converge, after several years of
drifting in different directions.

I hope so.

You misunderstand the emphasis. It has almost never been the case ever
that a vendor has aimed for 100 per cent conformance to a programming
language standard. (I say this despite the free use of ANSI and ISO
in advertising.)

I agree. They all say "ANSI C" on the box but never claim full
compliance to the standard.

I remember a decade ago Tom Plum expressing frustration
that he couldn't get any of his customers to eliminate the last three to
five test failures when running their C compilers against his validation
suite. Each had damn good reasons -- usually involving backward
compatibility -- why they wouldn't close the gap completely.

I can understand that. It is a commercial world and there is not death
penalty for not using a conforming compiler.

I just plain don't know. I've stopped asking folks like Green Hills,
Wind River, etc. what they're going to release when. Practically all
of our support for our OEMs is helping them give their customers what
they want *now*.

that is usually out of the box support for various targets with target
specific projects i.e. peripherals and boot loaders rather than
standards conformance or portability

Of course. Every programming language standard has oodles of compromises,
many made for "political" reasons (as if that were a bad thing).

It depends where you stand. Is there a pure technical argument in a
commercial world? Politics will always intrude.

I didn't
like all aspects of ANSI C89, yet I voted to approve the final draft.
I certainly didn't like C++98, yet I did the same.

Why vote yes then?

 

[Mark McIntyre]

No, not quite the same reason.

Sure, I was being disingenuous. But then so were you, using google as
a reference. You understand my point perfectly.

Didn't say it was.

Now /you're/ being disingenuous. Lets both stop shall we, and
reference only actual real sources of data, instead of the sum total
of all human drivel.

It's closer to it than your denial rooted in glib sophistry.

Ah, insults /and/ sophistry. Excellent, padawan, you pass the test.
You may diminish and go into the west.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Keith Thompson]

Not sure what your point is then. AFAIK, *every* C++ compiler is also
a C compiler these days. If each side of the compiler honors its
particular standard well enough, most programmers think of them as two
different compilers implementing two different but closely related
programming languages.

As far as I know, gcc (which officially stands for "GNU Compiler
Collection") has separate frontends for C and C++ -- and also for Ada,
Fortran, and probably a few other languages. I don't know whether
there's any common code between the C and C++ frontends.

 

[Ben Pfaff]

As far as I know, gcc (which officially stands for "GNU Compiler
Collection") has separate frontends for C and C++ -- and also for Ada,
Fortran, and probably a few other languages. I don't know whether
there's any common code between the C and C++ frontends.

There's actually a lot of common code between the C and C++ front
ends to GCC.

 

[Malcolm]

It's closer to it than your denial rooted in glib sophistry. And
C/C++ is way more real than a Martian president (or that, uh, other
thing), and you deny its presence in your chosen professional
field at your peril.

That's the problem.
C/C++ has the potential to destroy the C language. If no one sticks to the C
subset of the language, pretty soon everyone needs a C++ compiler to compile
the most basic code. As a C newgroup, this isn't a development most regs
want to see.

There is also a very good argument that C/C++ is bad C and bad C++.
C's virtue is that it is simple, "portable assembler". Once you admit
complex constructs you lose that simplicity, interfaces become hard to
understand, and it is difficult to profile code.
Similarly, to do an effective object-oriented design in C++, you need to use
the whole of the language and use it consistently. For instance a
constructor needs to throw an exception if it is to fail. Exceptions go hand
in hand with constructors, and banning them is a poor idea. It is no use
writing a C sort routine, because when the C++ programmer passe it objects,
he expects them to be copied from palce to place in memory correctly. If he
is using STL, he also expects to sort any controlled sequence witht he
appropriate characteristics.

I've seen a lot of C/C++ in my time. Almost always it is nightmarish mess
that combines the worst features of both languages.

Incidentally I am not a professional. I am not a member of any chartered
body with the power to restrict entry to the field.