"Chris Hills" <chris@phaedsys.org> wrote in message
news:LShQnqAO6niEFA7u@phaedsys.demon.co.uk...
[color=blue]
> In article <3dudnZQEooQyqRfZnZ2dnUVZ_qydnZ2d@giganews.com>, P.J. Plauger
> <pjp@dinkumware.com> writes[color=green]
>>"Chris Hills" <chris@phaedsys.org> wrote in message
>>news:8BUtzzAYLUiEFAtY@phaedsys.demon.co.uk...
>>[color=darkred]
>>> You have the problem that on the desktop most(?) users use MS compilers.
>>> MS have stopped doing C and do C++.[/color]
>>
>>But they still offer a compiler used by millions of C programmers.[/color]
>
> 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.[/color]
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.
[color=blue][color=green][color=darkred]
>>> BTW There is no such language as C/C++.[/color]
>>
>>Then why does Google give me 61 million hits on C/C++? You're the
>>one who keeps invoking the real world...[/color]
>
> 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".[/color]
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?
[color=blue][color=green][color=darkred]
>>> C++ was developed from C90 and
>>> diverged one way whilst C went a different way 95 and C99.[/color]
>>
>>Perhaps, but Standard C++ is based on C95.[/color]
>
> OK and C95 != C99.[/color]
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.
[color=blue][color=green]
>>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.[/color]
>
> That is the *next* version of C++ BTW when is it due out?[/color]
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.
[color=blue][color=green][color=darkred]
>>> Most(?) desktop users of C actually use a [MS]C++ compiler and MS has
>>> taken this off on their own direction[/color]
>>
>>Well, yes, but they seem to have gotten religion about standards
>>conformance lately.[/color]
>
> Yes, they have put a lot of work into ECMA and as you have pointed out
> become a lot more ISO compliant.
>[color=green]
>>They haven't done export for C++ yet (because
>>it's damned hard and next to nobody is asking for it)[/color]
>
> This is a bit of a recurring theme where no one is pushing for
> compatibility with the latest standards.[/color]
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.
[color=blue][color=green]
>>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).[/color]
>
> This is where we all came in. Why does no one (very few) want C99
> conformance?[/color]
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).
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>>Mostly true,[/color]
>
> thanks :-)
>[color=green]
>> 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.[/color]
>
> 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.....
>[color=green]
>>They don't brag about it because, as mentioned above,
>>it ain't a selling point.[/color]
>
> though AFAIK not all of the embedded implimenters do a full C99 back
> end.[/color]
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*.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>>There are many claims about various features of C and C++, with
>>dubious "real world" justification. Works for me.[/color]
>
> What works for you?[/color]
All those things in C99 that people say are broken. They also seem to
work for our customers. But what do we know?
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>>No, they've got a bad reputation for saying NO! to damn near everything,
>>including things they once promised to support.[/color]
>
> I know. Bloody nightmare. But probably not the place to go into it in
> detail.
>[color=green]
>> *Nothing* normative has
>>been added to Standard C since C99 and nothing of that sort is currently
>>planned. Where's the beef?[/color]
>
> Ask the usual suspects.... Though one or two seem to have given up and
> wandered off.[/color]
Well, that'll make for a refreshing interlude.
[color=blue][color=green][color=darkred]
>>> In fact there was a suggestion that we Should
>>> go back to C95 and start again! However this has been ignored.[/color]
>>
>>"Considered briefly and properly rejected" is how I'd characterize it.[/color]
>
> OK. Though you have said there are parts of C99 you wish had not been
> put in.[/color]
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.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>>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?[/color]
>
> They were arguing against adding any TR's or anything else until all the
> DR's had been fixed.[/color]
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.
[color=blue]
> Also that is Nick's worries about the whole maths
> model.[/color]
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.
[color=blue][color=green][color=darkred]
>>> 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.[/color]
>>
>>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.[/color]
>
> 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?[/color]
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.
[color=blue][color=green]
>>Somewhere along the line ISO C and C++ have lost their way and I am not[color=darkred]
>>> sure how to get them back.[/color]
>>
>>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.[/color]
>
> I think you have more influence than I do in that respect.[/color]
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 
