jars@coho.halcyon.com (Juan Rodriguez) writes:
>
>In article <1994Sep14.134109.20677@csrd.uiuc.edu>,
>Luddy Harrison <harrison@sp10.csrd.uiuc.edu> wrote:
>>And you could call the result "Eiffel".  Or maybe since the C
>>would be removed, you could call it "++".  (:
>
>Pronounced "naught plus plus?"

void plus plus?

harrison@sp10.csrd.uiuc.edu (Luddy Harrison) writes:

>chase@michaelcenterline.com (David Chase) writes:
>
>>It is also difficult for me to understand exactly what "removing
>>the C" means, or what's so horrible about it, assuming it
>>is what I think it is.
>
>Removing the C means, roughly, breaking all of the installed C++ code
>in existence.

In that case, you don't have to worry about the "Safe C++" proposal
"removing the C" from C++.  The only programs that the proposal
would break are those that use the couple of new keywords it introduces.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <1994Sep14.134109.20677@csrd.uiuc.edu>,
Luddy Harrison <harrison@sp10.csrd.uiuc.edu> wrote:
>And you could call the result "Eiffel".  Or maybe since the C
>would be removed, you could call it "++".  (:

Pronounced "naught plus plus?"


Juan Antonio Rodriguez-Sero; jars@halcyon.com
----------------------------------------------------------------
We know that what we do may be only provisional. But that is all
right; in the terrifying time in which we live and create, eter-
nity is not our inmmediate concern.
                                Yosef Hayim Yerushalmi, "Zakhor"

chase@michaelcenterline.com (David Chase) writes:

>It is also difficult for me to understand exactly what "removing
>the C" means, or what's so horrible about it, assuming it
>is what I think it is.

Removing the C means, roughly, breaking all of the installed C++ code
in existence.  Whether it's horrible or not depends, I guess, on
whether your application is among those that is made illegal by
the change.  (I frequently compile C code using a C++ compiler
so that it can be tightly integrated into my C++ programs.  Surely
I'm not alone in the practice.  If not, then removing the C means
rewriting such C code as well.)

>The ability to refer to arrays and
>subarrays with what also looks like a pointer causes
>trouble for toolbuilders -- if this ambiguity were removed,
>it would be much easier to build these tools.

It doesn't merely look like a pointer, it is a pointer; and there
is nothing ambiguous about it.  The C standard makes it perfectly
plain to what it points, and C++ has adopted that meaning.
I guess that it goes without saying that to break a zillion lines
of user code for the convenience of tool builders is, well, probably
not in the spirit of standardization.

>You could
>get a better garbage collector, and it would be easier to
>implement.  You could get built-in support for marshalling
>data structures (complicated ones, with cycles in them, and
>containing objects with "virtual member functions") to disk
>or over the net.  Your debugger could do a better job of
>displaying data (I know I get tired of trying to remember
>the incantation required when I want a "pointer" displayed
>like the array that it really is).  You could have tighter
>interface specifications.  You could get (gasp!) run-time
>checking of array bounds.

And you could call the result "Eiffel".  Or maybe since the C
would be removed, you could call it "++".  (:

>David Chase

-Luddy Harrison