Re: Brian Kernighan, maybe I'm not worthy, maybe I'm scum

On Mon, 31 Dec 2007 04:31:25 -0600, spinoza1111 wrote
(in article
<bb6c296e-6f1a-4956-bfd5-d0a3421bd17f@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>):

On Dec 31, 5:26 pm, Richard Heathfield <r...@xxxxxxxxxxxxxxx> wrote:
Look, mate. C isn't portable, because Brian Kernighan is an honest
man, and he says in a book published this year that Rob Pike's code is
C. But when I put this into the .Net development environment's C++
compiler, char * becomes sbyte and has to be converted byte by byte to
work with a test harness that uses the String. C is PART of C++, so
you are wrong in your claims that C is portable.

This will likely come as a huge surprise to you, but C is /not/ part of
C++. There are certainly a lot of similarities, and you could
arbitrarily construct some sub-C that might appear to be directly part
of C++, but not for C89, ISO C90, or C99 (especially the latter, but
all of them to a degree. There are some very surprising at times
differences between them to the novice C programmer, which you have
apparently discovered.

I know you won't believe anyone here that contradicts you, so I'll
point you at Stroustrup himself, who addresses this all too common
misconception personally. It is common enough that he has a FAQ entry
on it, entitled, not surprisingly, "Is C a subset of C++?"

http://www.research.att.com/~bs/bs_faq.html#C-is-subset

It covers a number of examples of how although programs can be ported
back and forth between the two in some cases, there are compatibility
problems. It is somewhat limited on first blush in its listing of the
areas of conflict, until you notice that he has limited his comparisons
to classic pre-ansi C and C89, omitting C99 completely until the very
end. There he says "C++ and C99 are siblings. C99 introduces several
novel opportunities for C/C++ incompatibilities".

There is a link (to another part of the same page) where he discusses
whether or not C and C++ should be merged:

http://www.research.att.com/~bs/bs_faq.html#merge

It's reasonable to assume he would not recommend doing so if they were
not currently distinct.

See also:
http://www.research.att.com/~bs/3rd_compat.pdf

He also wrote a brief article on the topic for Dr. Dobb's Journal in
2002, you can read it here:
http://www.ddj.com/cpp/184401555

There are alternate, and arguably less biased sources available here,
along with more concrete examples:

This being probably the most exhaustive coverage I have seen:
http://david.tribble.com/text/cdiffs.htm

http://www.kuro5hin.org/story/2001/2/23/194544/139
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=325&rl=1
Since you seem to be a fan of wikipedia, see also:
http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B


In light of the above, which you will no doubt use to correct your
misunderstanding about C being "a part of C++", can you still not
understand why moving C code to a C++ environment might introduce
issues? In particular for someone like yourself, who recently
admitted that you did not spend much effort mastering C anyway.

A language is portable when it can be ported, without a line by line
audit for conversions, for example to bit, which think they know the
length of the type.

No one credible argues that general C code will compile cleanly in a
C++ environment without change. Not one.

Portable code can with great difficulty written in C, mostly by
violating the general rule, don't use macros because they suck.

Incorrect, but we are used to that by now.

THIS DOES NOT MEAN THAT C IS PORTABLE. A portable language is one that
ports. One in which even code-that-sucks ports.

A "portable language" does not mean that code written in language A
will compile in language B without any effort. It means, which I once
would have been shocked to learn is news to you, that code written in
language A, compiled, executed and tested on Platform X, will work on
Platform Y with an appropriate compiler for that environment. It does
not mean that you can take C code, and run it through a compiler for a
/different/ language, and expect it to just blindly work.

Java is portable.

To another Java environment. Not to a BASICA ROM, or a Pascal
compiler. Java. Get it?

C# is portable as long as there is infrastructure outside Microsoft.

That's entertaining. You wish to pretend that Mono is baked. Cute,
but not buying today.

Even old Basic for Babies was more portable than C will ever be.

False.

In
the 1970s, programs were shared successfully in the old Byte magazine
in Basic source form. Whereas to type in a C program (for example, the
code in Mathematical Methods in C) is always an adventure.

Any code written in a dialect of a language outside of the guaranteed
industry standard will be difficult to port from the platform for which
it was originally intended to one that does not support that same
dialect. That is one of the major reasons that people working on code
for which portability is a major concern try to minimize the impact of
code which uses features not in the baseline standard.

Even if the standard legislates legacy code away, what managers and
their programmers MEAN by C remains, and you as a tech author are
doing the industry a disservice by making claims that are passed along
as rumours.

The standard has not legislated legacy code away. It has sadly left a
few things in the standard which can be legitimately argued are
deserving of being permanently expunged, for example, gets(), but the
standard body to date has held that existing code is important, and
even highly suspect or outright broken interfaces remain, although no
credible programmer is likely to use them in newly written code today.

So basically, what we have above, is you making a completely unfounded
assumption, and jumping from that to a bunch of false claims about
portability, the C language itself, C authors, the wonderfulness of
BASIC as a portable language relative to others, and across the board,
pretty much all of them are wrong. Congratulations.


--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





.

Relevant Pages

  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... >> considered to be a convenience by those who use the C language. ... I make no claims to being a VB.NET programmer. ... Ritchie SCREWED UP in designing the for loop because ... I do not believe that you are capable of writing a conforming C compiler. ...
    (comp.programming)
  • Re: why still use C?
    ... > to be at the mercy of the compiler and its designer, ... as a programmer I am no ... > program using templates and expect it to work identically on different ... > in mind that a programming language is a tool to make programs. ...
    (comp.lang.c)
  • Re: Natural size: int
    ... 001 DECLARE MYPAY PACKED-DECIMAL PICTURE "999999999999V999" ... Well, it's still a C group, so let's look at how far our language of topicality gets us. ... It's true that this shifts the burden to the programmer in a way that may be considered inappropriate for many applications, ... "De facto" assumptions are the reason programmers get the worst of both worlds: C leaves the types relatively unconstrained to promote portability, yet programmers will assume that the integer types will be identical across platforms. ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... The document that defines the C language requires that ... > a clause somewhere that allows a compliant compiler to exist and yet not ... > A translation unit can be object code. ... > anyone who thinks portability means moving C source code between C ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Letter to US Sen. Byron Dorgan re unpaid overtime
    ... a professional programmer however. ... >> The 'compiler mechanisms' for handlng for loops in various languages, ... I know Richard isn't so incompetent as to attempt to implement a compiler ... the defined semantics for that language. ...
    (comp.programming)