In <3u0v50$gj5@News1.mcs.net>, jim.fleming@bytes.com (Jim Fleming) writes:
>
>Can you give us an update on the C++ ANSI Standards activities?
>
>Also, since half of the standard is embodied in the class library,
>isn't it important to evaluate that class library in terms of OOA
>and OOD before everyone adopts it as a standard?
>
>Should more emphasis be placed on the class library than the language?
>


Actually, I think that's the approach the Smalltalk committe has taken.  I
 believe they split into two main groups; one concentrating on language
issues, the other addressing the class hierarchy.  This is not to be suprising
in a language like Smalltalk which is mostly class hierachy.  The Smalltalk
 syntax is relatively straightforward, it's the class hierarchy that has all the
complexity.

< tongue in cheek, no flames please >
What do you say about a language that has maybe two synatx rules:
Either
 object message

Or a variation of
 object message: object

I mean that's IT.  That's Smalltalk syntax summed up.  How much can a
standards committee do?

James O'Connor
Framework Technologies
oconnnor@basenet.net

In article <3tu9n1$1hkj@watnews1.watson.ibm.com>, ncohen@watson.ibm.com
says...
>
>In article <3t9uhj$kef@gensym1.gensym.com>, jsa@gensym.com () writes:
>|>
>|>
>|> >The positive attributes enumerated for C++ are availability on a wide
>|> >number of platforms, portability based on a stable and accepted
standard,
>|>                       ^^^^^^^^^^^            ^^^^^^     ^^^^^^^^
^^^^^^^^^
>|> >efficiency, early detection of errors, generality, and ability to
>|> >interface with libraries.  The same attributes apply to Ada 95, in some
>|> >cases more strongly than they apply to C++.
>|>
>|> I hope they had their tongue firmly in cheek when they wrote this
>|> peculiar set of comments...
>
>Since your judgment is based on my paraphrase, it seems only fair for me
>to quote the authors in full, so that you can judge them on their own
>words:
>
>   _Portablility_.  We move our programs between machines: We need an
>   official standard, or at least a de facto language definition.
>   Currently the book _The_Annotated_C++_Reference_Manual_ [44] is the
>   de facto standard.  Methodical improvements in the language by its
>   designer, Bjarne Stroustrup [105,107,109], have essentially
>   eliminated nonstandard language extensions.  ANSI (American
>   National Standards Institute) committee X3J16 and ISO
>   (International Standards Organization) committee WG21 are working
>   together toward an official standard.  Meanwhile most C++ compiler
>   vendors are tracking the decisions of the committees so that new
>   features accepted by the committees are appearing in commercial
>   compilers.
>
>--
>Norman H. Cohen    ncohen@watson.ibm.com
@@@@@@@@@@@@@@@@

Can you give us an update on the C++ ANSI Standards activities?

Also, since half of the standard is embodied in the class library,
isn't it important to evaluate that class library in terms of OOA
and OOD before everyone adopts it as a standard?

Should more emphasis be placed on the class library than the language?

@@@@@@@@@@@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

jhs@edg.com (John H. Spicer) writes:

>bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>>
>>Here is the complete claim as found in ``The C++ Programming Language
>>(2nd Edition)'' Addison-Wesley. ISBN 0-201-53992-6. Appendix B, pg 626-627:
[...]
>> With the following three exceptions, programs that are both C++ and
>> ANSI C have the same meaning in both languages:
>>
>> In C, sizeof('a') equals sizeof(int); in C++, it equals sizeof(char).
>>
>> In C, given
>>
>>  enum e { A };
>>
>> sizeof(A) equals sizeof(int) ; in C++, it equals sizeof(e), which need
>> not equal sizeof(int).
>>
>> A structure name declared in an inner scope can hide the name of an
>> object, function, enumerator, or type in an outer scope. [...]
>
>There are a couple more cases that I believe are similar to the ones
>described above. They involve the relatively recent addition of bool
>to the language.

I haven't seen Bjarne's post or the one he was replying to, except
for what John Spicer quoted.  But the claim in C++PL 2nd Ed is not completely
accurate, and not just because of the recent addition of `bool'.
Here's an additional case based on C++ comments (the important two
lines of this code come from the ARM, section 2.2, pg 6):

 #include <stdio.h>
 int main(void) {
  int a = 4;
  int b = a//* divide by 4 */4;
  -a;
  puts(b ? "C" : "C++");
  return 0;
 }

This program prints "C" when compiled with a C compiler, and "C++" when
compiled with a C++ compiler.

The claim in the C++PL 2nd Ed is also made in Appendix B of the ARM
(This appendix is the same in both books.)
It does seem a little strange that ARM page 401 claims there are
only three differences, but ARM page 6 lists an additional difference.

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
"The Internet interprets censorship as damage and routes around it" - anon.

In article <rshapiro-1406951359100001@esb.bbn.com> rshapiro@bbn.com (R Shapiro) writes:
<In article <3r48d0$mj6@watnews2.watson.ibm.com>, jjb@watson.ibm.com (John
<Barton) wrote:
<>C++ is suitable for most people using it today.
<
<I have no idea whether or not this is really true, or even how one would
<know if it weren't true (especially in the case of all the C++ programmers
<who have never used anything other than C/C++ and hence have no concept of
<languages that might be more suitable).

But such people *do* know C++ is suitable even if they *don't* know
other languages.  Paradoxical, perhaps, but that's life.  The way
it works is this: a company X sells a program, oh, about 10 million
lines of C code long that took 5-10 years to develop.  Guess what
language they'll choose if they decide to go OO?
--
Jan Bielawski
Biosym Technologies        )\._.,--....,'``.
San Diego, CA             /,   _.. \   _\  ;`._ ,.       | ph.: (619) 458-9990
jpb@biosym.com        fL `._.-(,_..'--(,_..'`-.;.'       | fax: (619) 458-0136
--
****************************************************************************
* DISCLAIMER: Unless indicated otherwise, everything in this note is       *
* personal opinion, not an official statement of Biosym Technologies, Inc. *
****************************************************************************

In article <3roaeo$504@golem.wcc.govt.nz> rodgers@aladdin.wcc.govt.nz (Mark Rodgers) writes:
>From: rodgers@aladdin.wcc.govt.nz (Mark Rodgers)
>Subject: Re: C++ not OOP? (Was: Language Efficiency
>Date: 15 Jun 1995 03:46:32 GMT

>In article <rshapiro-1406951359100001@esb.bbn.com>,
>R Shapiro <rshapiro@bbn.com> wrote:
>>One thing I know for sure: some programmers are switching to C++ because,
>>as they say, resistance is futile. It's at least as much a marketing
>>decision as a technical one in many cases I'm familiar with. Which is not
>>to say the language is unsuitable for those people and those cases, only
>>that the question hasn't been studied at all. No one sits down and asks
>>"Would Smalltalk be better here?" because, for business reasons, the
>>answer doesn't matter.

>I often hear how Smalltalk is better than C++ for OOP and how C++ is not
>really OO, etc.  Can I turn the hypothetical question asked in the above
>paragraph on its head and ask:

>                What does Smalltalk give you that C++ doesn't?

I think that's an excellent question.  Being that I've only been programming
in C++ for only 2 years (a converted C-guy for the last 7-8 years), my opinion
might not mean "squat", but....

* Since "SmallTalk" is not a hybrid language, you're forced to design and
  implement your applications truely object-oriented.  This is not to say that
  you can't get away with a poorly designed OO application.

* Being that SmallTalk is non-hybrid, every class you create (no matter if it's
  at the top of the class hierarchy will be inherited from a "SuperClass".

* I think C++ is powerful in such that you're not limited to developing a
  truely OO system (don't get me wrong, I'm not encouraging the development
  and implementation here of a non-oo system using C++ as it's tool of choice).
  Being that there's millions of C/C++ programmers in the market place (or
  at least people who know how to read "C" code), making the transition into
  an OO paradigm will be less "painful" if they can see the tool in somewhat
  of a language that they are "used" to.  C++ might be more robust in the sense
  that (and I don't know SmallTalk, never seen a line of code from it so I
  could be wrong) there's probobly alot more vendor class libraries using C++
  that you can just "use" and not go thru the hassle of "interfacing 2"
  separate languages together.   I don't know the answer to this question:
  Can you merge an application together using SmallTalk AND C++ both using
  the same common classes???  Is it possible???  Does SmallTalk allow you
  to create class libraries that you can use in C++ and vice/versa???

  I totally enjoy the benefits that C++ gives you (the efficiency, the
  portability, and most importantly the flexibility that SmallTalk may/
  may not provide).  I do NOT enjoy creating makefiles to get our C++ apps
  to run with g++.

Thanks,
Theron B. Kousek

In article <DA2Au7.DzE@research.att.com>,
Andrew Koenig <ark@research.att.com> wrote:
>It is funny to hear someone try to convince us by an informal argument
>that informal statements have no meaning.
>--
>    --Andrew Koenig
>      ark@research.att.com


The argument is that informal statements give rise to ambiguities that
can make programmers and compiler writer lives' difficult.  In the
case of C++, the lack of a formal specification of the semantics of
the language make it difficult to decipher precisely what behavior and
abritrary example results in.  In addition, a formal semantics (and
set of type checking rules) provide a solid framework in which to
analyze and discuss features of a language.

I have spent the last year developing an operational semantics of the
object-oriented core of C++.  Point you web browser to
http://cs.williams.edu/~95als
or ftp://cs.williams.edu/pub/students/95als/main.ps  (or main.dvi)

I am eager to get feedback on this work.

Regards,
  Adam Seligman
  adams@pets.sps.mot.com

Adam Seligman (adams@pets.sps.mot.com) wrote:
: The argument is that informal statements give rise to ambiguities that
: can make programmers and compiler writer lives' difficult.

...and the person who has to maintain your code.

As a practical matter, stay away from the arcana -- no matter how well
defined the behavior is. It will save people from making bad assumptions
or hitting the manual to debug your crud^H^H^H^Hcode.

Hey, I can take this pedantic tone. Of course, it doesn't work with the
kids either...

--
Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3156 days!
aishdas@haven.ios.com                     (16-Oct-86 - 20-Jun-95)
<a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Worship, Kindness</a>
<a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>

In article <3rg8ug$g3g@steel.interlog.com>,
Herb Sutter <herbs@interlog.com> wrote:
>In article <3reegn$mm9@hustle.rahul.net>,
>   "Ronald F. Guilmette" <rfg@rahul.net> wrote:
>>
>>Ya know, just once it would be nice to see someone who _knew_ what they
>>were talking about say something on this subject.
>>
>>Boys and girls, it _is_ true (I hope anyway) that every program which is
>>both a valid ANSI C program _and_ a valid ANSI C++ program has the same
>>semantics when viewed either way.
>
>Ahem; not true, though there aren't many counterexamples.  Scope hiding is
>one:
>
> int X[100];
>
> int main (int, char**)
> {
>  struct X { ... };
>  int i = sizeof(X); // sizeof array or struct?
> }
>
>It's a legal program in both, but the answer is different.

OK.  You caught me.  I should have said ``for the most part''.

Counterexamples are indeed rare.
--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

In article <1892675582.123728@dbx1.nugraphix.com>, Davros,timd-Starbase.NeoSoft.COM@nugraphix.com (Davros,timd@Starbase.NeoSoft.COM) writes:
In article <rshapiro-1406951359100001@esb.bbn.com>,
R Shapiro <rshapiro@bbn.com> wrote:
>In article <3r48d0$mj6@watnews2.watson.ibm.com>, jjb@watson.ibm.com (John
>Barton) wrote:
>>C++ is suitable for most people using it today.
>
>[...] some programmers are switching to C++ because,
>as they say, resistance is futile. [...]

Resistance is fu-tile.

Exterminate.

Exterminate.

-Davros  :)



--
   Resistance is fu-tile.
   Exterminate!
   Exterminate!

--- Internet Message Header Follows ---
Path:
noc.tor.hookup.net!hookup!newshost.marcam.com!zip.eecs.umich.edu!panix!news.mathworks.com!udel!news.sprintlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!news.ecn.bgu.edu!newspump.wustl.edu!newsfeed.rice.edu!news.sesqui.net!uuneo.neosoft.com!Starbase.NeoSoft.COM!not-for-mail
From: timd@Starbase.NeoSoft.COM (Davros)
Newsgroups: comp.object,comp.lang.c++,comp.std.c++
Subject: Re: C++ not OOP? (Was: Language Efficiency
Date: 14 Jun 1995 16:16:59 -0500
Organization: NeoSoft Internet Services   +1 713 968 5800
Lines: 23
Message-ID: <3rnjkb$f94@Starbase.NeoSoft.COM>
References: <dewar.797512974@gnat> <3qnlo5$hfn@ornews.intel.com>
<3r48d0$mj6@watnews2.watson.ibm.com> <rshapiro-1406951359100001@esb.bbn.com>
NNTP-Posting-Host: starbase.neosoft.com
Xref: noc.tor.hookup.net comp.object:21515 comp.lang.c++:86868
comp.std.c++:12241

EXTERMINATE EXTERMINATE EXTERMINATE !!!!!!!!!!!

--
------------------------------------------------------------------------------
Andrew Staniszewski
staniszewski@mayo.edu
" ... is everybody else going forwards,
 or are we just going backwards ??" MDE
------------------------------------------------------------------------------

R Shapiro (rshapiro@bbn.com) wrote:

|> One thing I know for sure: some programmers are switching to C++ because,
|> as they say, resistance is futile. It's at least as much a marketing
|> decision as a technical one in many cases I'm familiar with. Which is not
|> to say the language is unsuitable for those people and those cases, only
|> that the question hasn't been studied at all. No one sits down and asks
|> "Would Smalltalk be better here?" because, for business reasons, the
|> answer doesn't matter.

This poses the question of what is meant by `suitable'.  I would argue
that commercial considerations (like the availability of a compiler for
your target machine) *are* important in determining suitability.
--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle--
                             --Beratung in industrieller Datenverarbeitung

In article <3rru43$20q@gabi.gabi-soft.fr>, kanze@gabi-soft.fr (J. Kanze) wrote:

>R Shapiro (rshapiro@bbn.com) wrote:
> > No one sits down and asks
>|> "Would Smalltalk be better here?" because, for business reasons, the
>|> answer doesn't matter.
>
>This poses the question of what is meant by `suitable'.  I would argue
>that commercial considerations (like the availability of a compiler for
>your target machine) *are* important in determining suitability.


I think it was pretty clear from the context that suitability meant
technical suitability. That should include availability and quality of
compilers and development environments - I agree with you completely. In
practice, this doesn't make that much difference much of the time, since
the most popular machines out there right now all have good Smalltalk and
Lisp implementations. But sometimes it's an important technical issue.

"Business reasons" otoh refers to something else altogether:  C++ is
something of a buzzword  and clients will therefore sometimes *insist* on
it being used, without any particular reason except that they've heard of
it. Similarly, it's important for the same reason to be able to advertise
C++ expertise. In other words, it's often more a matter of sales and
marketing than anything else. If you want to include these factors in
"suitability", I'm afraid the term simply loses any meaning. The argument
becomes nothing more than a fashion statement: C++ is the most suitable
choice because it's the most fashionable choice right now. That's not very
convincing to software developers (I hope).

There's also the very serious problem of know-what-I-like-and-like-what-I-know.
Software houses which only have C++ expertise in-house have no way to
examine the options in the first place, and no way to support a non-C++
choice even if it's clearly the right one. The same thing is of course
true for any single-language software company. This is another kind of
"business reason" why a language is chosen, and another reason which
should be unconvincing to software developers.

There are plenty of good technical reasons to use C++ in plenty of
situations. There are also plenty of situations in which it's not the most
"suitable" choice, but in which it's being used anyway for one
(non-technical) reason or another. Has anyone ever made a study of this?
Not that I've ever heard of. In which case, any claim about how "suitable"
the language is in its general use is simply without foundation and
support: not necessarily wrong, just unsupported.

--
rs/rshapiro@bbn.com

In article <rshapiro-1406951359100001@esb.bbn.com> rshapiro@bbn.com (R
Shapiro) writes:
> In article <3r48d0$mj6@watnews2.watson.ibm.com>, jjb@watson.ibm.com
(John
> Barton) wrote:
> >C++ is suitable for most people using it today.
>
> I have no idea whether or not this is really true, or even how one would
> know if it weren't true (especially in the case of all the C++
programmers
> who have never used anything other than C/C++ and hence have no concept
of
> languages that might be more suitable).
                          ^^^^^^^^^^^^^
John said was suitable, he did *not* say most suitable. A language can be
most suitable for a job, but that says nothing about the suitability of
other languages, only that they are no so suitable.
> I'm curious how *you* know it's true. Have you done surveys?

If C++ was not suitable they (the programmers using it) could not use it
to do the job. Assembler is suitable for any programming task. It is
rarely (in general) the most suitable - also it is rarely the least
suitable (eg. logo will often be less suitable!)

> One thing I know for sure: some programmers are switching to C++
because,
> as they say, resistance is futile. It's at least as much a marketing
> decision as a technical one in many cases I'm familiar with. Which is
not
> to say the language is unsuitable for those people and those cases, only
> that the question hasn't been studied at all. No one sits down and asks
> "Would Smalltalk be better here?" because, for business reasons, the
> answer doesn't matter.

For a programming job of fairly short length (less than 1 person-year
say) the costs of learning and coming up to speed with a new language may
well out-weigh the advantages... especially as it is often
non-programmers who will make the decision (that is those who sign the
purchase requisition for compilers, libraries, training, etc).

> Your pronouncement sounds arbitrary and unsupported to me, but I'm ready
> to be convinced otherwise.

I have a feeling your were answering a different point! :-)

--------------------------------------------------------------
Richard Cox: Data Innovation Group, SMS United Kingdom Limited
#include <std-disclaimer.h>
richardcox@cix.compulink.co.uk

In article <3r48d0$mj6@watnews2.watson.ibm.com>, jjb@watson.ibm.com (John
Barton) wrote:
>C++ is suitable for most people using it today.

I have no idea whether or not this is really true, or even how one would
know if it weren't true (especially in the case of all the C++ programmers
who have never used anything other than C/C++ and hence have no concept of
languages that might be more suitable). I'm curious how *you* know it's
true. Have you done surveys?

One thing I know for sure: some programmers are switching to C++ because,
as they say, resistance is futile. It's at least as much a marketing
decision as a technical one in many cases I'm familiar with. Which is not
to say the language is unsuitable for those people and those cases, only
that the question hasn't been studied at all. No one sits down and asks
"Would Smalltalk be better here?" because, for business reasons, the
answer doesn't matter.

Your pronouncement sounds arbitrary and unsupported to me, but I'm ready
to be convinced otherwise.

--
rs/rshapiro@bbn.com

In article <rshapiro-1406951359100001@esb.bbn.com>,
R Shapiro <rshapiro@bbn.com> wrote:
>In article <3r48d0$mj6@watnews2.watson.ibm.com>, jjb@watson.ibm.com (John
>Barton) wrote:
>>C++ is suitable for most people using it today.
>
>[...] some programmers are switching to C++ because,
>as they say, resistance is futile. [...]

Resistance is fu-tile.

Exterminate.

Exterminate.

-Davros  :)



--
   Resistance is fu-tile.
   Exterminate!
   Exterminate!

In article <3roaeo$504@golem.wcc.govt.nz>, rodgers@aladdin.wcc.govt.nz
(Mark Rodgers) wrote:

>R Shapiro <rshapiro@bbn.com> wrote:
>> No one sits down and asks
>>"Would Smalltalk be better here?" because, for business reasons, the
>>answer doesn't matter.
>
>I often hear how Smalltalk is better than C++ for OOP and how C++ is not
>really OO, etc.

Of course I didn't say any of those things. A language can be "better" for
a specific application, but you can't know that unless you ask the
question for that application, and spend some time considering the
answers. And of course you have to understand the options well enough to
know which would be more suitable in any given context. This doesn't
happen very often, in my experience, certainly not enough to make any
generalizations about whether shops are or are not, as a rule, making
suitable language choices.



>                What does Smalltalk give you that C++ doesn't?

This has been discussed to death: meta-object support, dynamic typing,
rapid prototyping, garbage collection, uniform semantics etc etc etc.

I would suggest that you learn Smalltalk, look at some "expert" code for a
large system, and write a couple of medium-sized programs yourself. This
will give you the information you're after, and will also help you
understand the issues a little better. It will also help you present the
case for C++, when that's appropriate, a little more rationally and a
little less defensively.


>I suspect that the reason no-one asks "Would Smalltalk be better here?" is
>that the list I'm after would be so short and the features in it of so
>little use to the average business application (unlike the list of features
>C++ offers that Smalltalk doesn't) that 99.99% of the time the answer is
>going to be "no" anyway.

This is extraordinarily presumptuous. You've admitted that you don't know
anything about Smalltalk, but here you are already decided that it doesn't
offer anything you need!

What better example could there be of choosing a language for reasons
other than technical appropriateness?

--
rs/rshapiro@bbn.com

In article <3roaeo$504@golem.wcc.govt.nz> rodgers@aladdin.wcc.govt.nz (Mark Rodgers) writes:

> I often hear how Smalltalk is better than C++ for OOP and how C++ is not
> really OO, etc.  Can I turn the hypothetical question asked in the above
> paragraph on its head and ask:
>
>   What does Smalltalk give you that C++ doesn't?

I haven't ever used Smalltalk (I've been meaning to; I suppose this
probably isn't the best forum to ask for recommendations about
inexpensive Smalltalk environments that run under Unix or OS/2), but I
think it really is true that Smalltalk has some very useful features
that C++ doesn't.  I also think that the reverse is true, of course.

One of the biggest advantages of Smalltalk is that it has garbage
collection.  I know that some folks here on comp.lang.c++ don't like
garbage collection, but, having used it in other languages, I have to
disagree with them.  So much of C++ programming involves tedious
bookkeeping to make sure that every object has one and only one
"owner" that will delete it at the appropriate time: it's so nice to
be able to do away with all that nonsense, and makes code so much
simpler!  I can understand the reasons why garbage collection wasn't
added to the draft C++ standard, but it's still a shame.

Second, all Smalltalk implementations nowadays come with a fairly
large and stable class library; this isn't yet true of C++
implementations.  Commercial Smalltalk implementations also come with
a complete graphical environment that supports rapid prototyping.

Third, Smalltalk is more uniformly object-oriented.  In C++, for
example, integers aren't objects, while in Smalltalk they are.  In
Smalltalk, in fact, classes themselves are objects, and this makes
certain interesting programming techniques much easier.  (See _Design
Patterns_ for some examples.)

Then there's the big difference between Smalltalk's and C++'s type
system.  In C++, both variables and objects have types: a variable has
a type, declared at compile time, and that tells you (something about)
the type of the object it refers to.  In Smalltalk, though, objects
have types and variables don't.  You can send any message to any
object, and the object will issue a run-time error if the message is
inappropriate for its type.  There are advantages and disadvantages to
both of these kinds of type systems; I'm not going to make a definite
claim about which one is better.  Certainly, though, a difference this
fundamental will affect every aspect of your program.

There are also, I think, several ways in which C++ is better than
Smalltalk, but this article is long enough already.
--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

In article <rshapiro-1406951359100001@esb.bbn.com>,
R Shapiro <rshapiro@bbn.com> wrote:
>One thing I know for sure: some programmers are switching to C++ because,
>as they say, resistance is futile. It's at least as much a marketing
>decision as a technical one in many cases I'm familiar with. Which is not
>to say the language is unsuitable for those people and those cases, only
>that the question hasn't been studied at all. No one sits down and asks
>"Would Smalltalk be better here?" because, for business reasons, the
>answer doesn't matter.

I often hear how Smalltalk is better than C++ for OOP and how C++ is not
really OO, etc.  Can I turn the hypothetical question asked in the above
paragraph on its head and ask:

  What does Smalltalk give you that C++ doesn't?

I'm not interested in subjective features such as "it supports ... better"
or "its a better environment for ...".  I would like to see a factual list
of features.

I suspect that the reason no-one asks "Would Smalltalk be better here?" is
that the list I'm after would be so short and the features in it of so
little use to the average business application (unlike the list of features
C++ offers that Smalltalk doesn't) that 99.99% of the time the answer is
going to be "no" anyway.

I hope this doesn't start a stupid religious war.  I'm after facts not
opinions.

Thanks
Mark

>>>>> Mark Rodgers <rodgers@aladdin.wcc.govt.nz> writes:

>   What does Smalltalk give you that C++ doesn't?

Smalltalk, much like LISP, is intrinsically a dynamically typed and
dynamically bound language.  This means that it is much easier to write
run-time extensible systems in Smalltalk than in C++.  This is not to say
that you cannot write run-time extensible systems in C++ -- one of our
largest customers is doing just that -- but there are a lot more headaches
involved, and you will quickly find yourself beating your head against
operating system bugs.  Believe me, I know; I've been implementing shared
library and dynamic loading support for g++.

Jason

In article <3reegn$mm9@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:

   Boys and girls, it _is_ true (I hope anyway) that every program which is
   both a valid ANSI C program _and_ a valid ANSI C++ program has the same
   semantics when viewed either way.

It is funny to see people argue about equality of semantics of programs in
languages, which so far have successfully resisted all attempts to specify
their semantics formally.

--
-Matthias

Matthias Blume (blume@dynamic.cs.princeton.edu) wrote:
: In article <3reegn$mm9@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:

:    Boys and girls, it _is_ true (I hope anyway) that every program which is
:    both a valid ANSI C program _and_ a valid ANSI C++ program has the same
:    semantics when viewed either way.

: It is funny to see people argue about equality of semantics of programs in
: languages, which so far have successfully resisted all attempts to specify
: their semantics formally.

Perhaps it's the theory of formal semantics that has successfully
resisted all attempts to resolve real issues that humans
find desirable, such as the truth of the first statement above.

 :-(

: --
: -Matthias

In article 95Jun11120648@dynamic.cs.princeton.edu, blume@dynamic.cs.princeton.edu (Matthias Blume) writes:
>In article <3reegn$mm9@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:
>
>   Boys and girls, it _is_ true (I hope anyway) that every program which is
>   both a valid ANSI C program _and_ a valid ANSI C++ program has the same
>   semantics when viewed either way.
>
>It is funny to see people argue about equality of semantics of programs in
>languages, which so far have successfully resisted all attempts to specify
>their semantics formally.

Quite apart from that, there are just a few areas where where the semantics
of C and C++ differ. The simplest example:

#include <stdio.h>
int main()
{
 printf("%u", (unsigned)sizeof('a'));
 return 0;
}

This program prints whatever the size of int is in C, and prints 1 in C++.

---
Steve Clamage, stephen.clamage@eng.sun.com

In article <3reegn$mm9@hustle.rahul.net>,
   "Ronald F. Guilmette" <rfg@rahul.net> wrote:
>
>Ya know, just once it would be nice to see someone who _knew_ what they
>were talking about say something on this subject.
>
>Boys and girls, it _is_ true (I hope anyway) that every program which is
>both a valid ANSI C program _and_ a valid ANSI C++ program has the same
>semantics when viewed either way.

Ahem; not true, though there aren't many counterexamples.  Scope hiding is
one:

 int X[100];

 int main (int, char**)
 {
  struct X { ... };
  int i = sizeof(X); // sizeof array or struct?
 }

It's a legal program in both, but the answer is different.

Stroustrup just posted an article about this recently in one of the three
newsgroups covered by this thread (in fact, it may even have been in this
thread).


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019

In article <3reegn$mm9@hustle.rahul.net>,
   "Ronald F. Guilmette" <rfg@rahul.net> wrote:
>
>Ya know, just once it would be nice to see someone who _knew_ what they
>were talking about say something on this subject.
>
>Boys and girls, it _is_ true (I hope anyway) that every program which is
>both a valid ANSI C program _and_ a valid ANSI C++ program has the same
>semantics when viewed either way.

Ahem; not true, though there aren't many counterexamples.  Scope hiding is
one:

 int X[100];

 int main (int, char**)
 {
  struct X { ... };
  int i = sizeof(X); // sizeof array or struct?
 }

It's a legal program in both, but the answer is different.

Stroustrup just posted an article about this recently in one of the three
newsgroups covered by this thread (in fact, it may even have been in this
thread).


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Herb Sutter                 2228 Urwin, Ste 102         voice (416) 618-0184
Connected Object Solutions  Oakville ON Canada L6L 2T2    fax (905) 847-6019

In article <BLUME.95Jun11120648@dynamic.cs.princeton.edu> blume@dynamic.cs.princeton.edu (Matthias Blume) writes:

> It is funny to see people argue about equality of semantics of programs in
> languages, which so far have successfully resisted all attempts to specify
> their semantics formally.

It is funny to hear someone try to convince us by an informal argument
that informal statements have no meaning.
--
    --Andrew Koenig
      ark@research.att.com

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: In article 95Jun11120648@dynamic.cs.princeton.edu, blume@dynamic.cs.princeton.edu (Matthias Blume) writes:
: >In article <3reegn$mm9@hustle.rahul.net> "Ronald F. Guilmette" <rfg@rahul.net> writes:
: >
: >   Boys and girls, it _is_ true (I hope anyway) that every program which is
: >   both a valid ANSI C program _and_ a valid ANSI C++ program has the same
: >   semantics when viewed either way.
: >
: >It is funny to see people argue about equality of semantics of programs in
: >languages, which so far have successfully resisted all attempts to specify
: >their semantics formally.

: Quite apart from that, there are just a few areas where where the semantics
: of C and C++ differ. The simplest example:

: #include <stdio.h>
: int main()
: {
:  printf("%u", (unsigned)sizeof('a'));
:  return 0;
: }

: This program prints whatever the size of int is in C, and prints 1 in C++.


C'mom people !!!
The claim is "every C program in the *book* called K&R *2nd edition*
is a valid C++ programm". _I_ don't care whether it's right or wrong
but please don't change the meaning of the claim.

-----------------
L.D.


: ---
: Steve Clamage, stephen.clamage@eng.sun.com

In article <D9v23A.228G@austin.ibm.com> browncs@austin.ibm.com (Charlie Brown) writes:

> You are correct but you are misunderstanding the claim in Stroustrup, which
> is that every program
> printed in the K&R book as an example is a valid C++ program. The point is
> that the programs that are valid C but not valid C++ are programs that no
> right thinking C programmer would write anyway.

That's not really true.  Trivial case: C++ has a lot of keywords that
aren't C keywords.  I don't think there's anything stupid or unnatural
about having variable names like "class" or "template" or "public" in
a C program.  In fact, I suspect that a great many large C programs
will fail to compile as C++ for one reason or another.

But I do think it's fair to say that C++ is almost a superset of C,
and that modifying a C program so that it is valid C++ will rarely
be all that difficult.
--
Matt Austern          matt@physics.berkeley.edu
http://dogbert.lbl.gov/~matt

In <MATT.95Jun9162028@godzilla.EECS.Berkeley.EDU>, matt@godzilla.EECS.Berkeley.EDU writes:
>That's not really true.  Trivial case: C++ has a lot of keywords that
>aren't C keywords.  I don't think there's anything stupid or unnatural
>about having variable names like "class" or "template" or "public" in
>a C program.  In fact, I suspect that a great many large C programs
>will fail to compile as C++ for one reason or another.

I stand corrected.  In fact this actually happened in the OS/2 Toolkit
(the .H files for interfacing to OS/2 APIs).  They had named one of the
parameters in a function declaration "class" and had to change it for
C++ use.

Charlie Brown - LAN Server Development - browncs@austin.ibm.com

In article <D9yyrM.4AAo@austin.ibm.com>,
Charlie Brown <browncs@austin.ibm.com> wrote:
>I stand corrected.  In fact this actually happened in the OS/2 Toolkit
>(the .H files for interfacing to OS/2 APIs).  They had named one of the
>parameters in a function declaration "class" and had to change it for
>C++ use.

X's header files had a structure called Visual that had an element named
'class'.  They too had to modify their header files so that it was named
something else (but they had the dusty deck problem, so it is named
c_class in c++ and class in c).

Warner
--
Warner Losh  "VMS Forever"  home: imp@village.org
Cyberspace Development, Inc   work: imp@marketplace.com
Makers of TIA, The Internet Adapter.  http://marketplace.com/

>>>>> "BS" == Bjarne Stroustrup <9758-26353> 0112760 <bs@research.att.com> writes:

 BS> Here is the complete claim as found in ``The C++ Programming Language
 BS> (2nd Edition)'' Addison-Wesley. ISBN 0-201-53992-6. Appendix B, pg
 BS> 626-627:

...and don't forget all the new keywords in C++.

In article <3r5hrm$1hh@news.ox.ac.uk>,
David Hopwood <lady0065@sable.ox.ac.uk> wrote:
>In article <3qnhue$9f2@news.wwa.com>, Robert C. Martin <rmartin@oma.com> wrote:
>>jim.fleming@bytes.com (Jim Fleming) wrote:
>>
>>>C++ has benefited from
>>>this convienant lack of "classification" of C programmers. It is to C++'s
>>>benefit to claim that ALL C programmers are C++ programmers. This is as
>>>misleading as claiming that C++ can be used to do true object-oriented
>>>programming.
>>
>>No such claim has ever been made by reputable sources to my knowledge.
>>The claim that "every program in K&R is also a C++ program" was made by
>>Stroustrup, and is completely true.
>
>Actually, no. The claim is that every program that is both legal K&R C, and
>legal C++, has the same semantics in each language.
>For example, a K&R C program without prototypes is not legal ANSI C++.

Ya know, just once it would be nice to see someone who _knew_ what they
were talking about say something on this subject.

Boys and girls, it _is_ true (I hope anyway) that every program which is
both a valid ANSI C program _and_ a valid ANSI C++ program has the same
semantics when viewed either way.

But the term ``K&R C'' usuaully denotes a whole 'nother language... one
that was never actually standardized, but about which a fair amount _is_
known.  Specifically it _is_ known that a given program can be valid when
viewed as an ANSI C (or ANSI C++) program and can also be valid when viewed
as a K&R C program, but that the semantics in these two cases MAY BE DIFFERENT.

See the sections of the ANSI C rationale document (under the ``Quiet Change''
headings) for more details.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

In article <3qnlo5$hfn@ornews.intel.com>, pdlogan@ornews.intel.com (Patrick Logan) writes:
|> Robert C. Martin (rmartin@oma.com) wrote:
|>
|> : But that does not mean that if BL had produced a language of poor
|> : quality, everybody would have used it.  Rather, I think that if C++
|> : had turned out to be half-baked or have other problems, the industry
|> : would not have adopted it with the enthusiasm that it now shows.
|>
|> It is debatable whether or not C++ is of "poor quality".
|>
|> However from my experience with C++ since 1988, I have observed
|> a lot of adoption without a deep understanding of the language.

   Adopting C++ without a deep understanding of the language
is not evidence of poor judgement.  Quite the contrary: relying
on the judgement of others whose judgement you trust is likely to
be more successful than a private, repeated analysis of your own.

|> I cannot say whether these adopters would have done differently
|> had they done more of an assessment.

   And I say that, had they done differently based on their own
assessment, it would likely have been a mistake in most cases.
C++ is suitable for most people using it today.  A language with
similar advantages and few disadvantages may yet emerge.  More likely
in my opinion is an evolution of C++ through improved programming
environments and libraries to reduce complexity and the emergence of
new languages for new domains of programming where C++ is not suited.

--
John.

John J. Barton        jjb@watson.ibm.com            (914)784-6645
 <http://www.research.ibm.com/xw-SoftwareTechnology>
H1-C13 IBM Watson Research Center P.O. Box 704 Hawthorne NY 10598

lady0065@sable.ox.ac.uk (David Hopwood) wrote:
>In article <3qnhue$9f2@news.wwa.com>, Robert C. Martin <rmartin@oma.com> wrote:
>>jim.fleming@bytes.com (Jim Fleming) wrote:
>>
>>>C++ has benefited from
>>>this convienant lack of "classification" of C programmers. It is to C++'s
>>>benefit to claim that ALL C programmers are C++ programmers. This is as
>>>misleading as claiming that C++ can be used to do true object-oriented
>>>programming.
>>
>>No such claim has ever been made by reputable sources to my knowledge.
>>The claim that "every program in K&R is also a C++ program" was made by
>>Stroustrup, and is completely true.
>
>Actually, no. The claim is that every program that is both legal K&R C, and
>legal C++, has the same semantics in each language.
>For example, a K&R C program without prototypes is not legal ANSI C++.
>

   "...note that every program in Kernighan and Ritchie: The C Programming
   Language (2nd Edition) is a C++ program."

           -- Bjarne Stroustrup,  The C++ Programming Language, 2d. ed.  p6.

Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

In article <3r5hrm$1hh@news.ox.ac.uk> lady0065@sable.ox.ac.uk (David
Hopwood) writes:

|> In article <3qnhue$9f2@news.wwa.com>, Robert C. Martin <rmartin@oma.com> wrote:
|> >jim.fleming@bytes.com (Jim Fleming) wrote:
|> >
|> >>C++ has benefited from
|> >>this convienant lack of "classification" of C programmers. It is to C++'s
|> >>benefit to claim that ALL C programmers are C++ programmers. This is as
|> >>misleading as claiming that C++ can be used to do true object-oriented
|> >>programming.
|> >
|> >No such claim has ever been made by reputable sources to my knowledge.
|> >The claim that "every program in K&R is also a C++ program" was made by
|> >Stroustrup, and is completely true.

|> Actually, no. The claim is that every program that is both legal K&R C, and
|> legal C++, has the same semantics in each language.
|> For example, a K&R C program without prototypes is not legal ANSI C++.

And a C program with prototypes is not K&R C.

I think the claim, if true, would refer to ANSI C, and not K&R.

In fact, there are a few places where the claim is not true, although
I don't think that they would make any difference in a real program.
(The classical example is `sizeof( 'a' )', which is guaranteed to be 1
in C++, but is typically greater in C.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

In <3r5hrm$1hh@news.ox.ac.uk>, lady0065@sable.ox.ac.uk (David Hopwood) writes:
>In article <3qnhue$9f2@news.wwa.com>, Robert C. Martin <rmartin@oma.com> wrote:
>>The claim that "every program in K&R is also a C++ program" was made by
>>Stroustrup, and is completely true.
>
>Actually, no. The claim is that every program that is both legal K&R C, and
>legal C++, has the same semantics in each language.
>For example, a K&R C program without prototypes is not legal ANSI C++.

You are correct but you are misunderstanding the claim in Stroustrup, which
is that every program
printed in the K&R book as an example is a valid C++ program. The point is
that the programs that are valid C but not valid C++ are programs that no
right thinking C programmer would write anyway.

Charlie Brown - LAN Server Development - browncs@austin.ibm.com

In article <3qnhue$9f2@news.wwa.com>, Robert C. Martin <rmartin@oma.com> wrote:
>jim.fleming@bytes.com (Jim Fleming) wrote:
>
>>C++ has benefited from
>>this convienant lack of "classification" of C programmers. It is to C++'s
>>benefit to claim that ALL C programmers are C++ programmers. This is as
>>misleading as claiming that C++ can be used to do true object-oriented
>>programming.
>
>No such claim has ever been made by reputable sources to my knowledge.
>The claim that "every program in K&R is also a C++ program" was made by
>Stroustrup, and is completely true.

Actually, no. The claim is that every program that is both legal K&R C, and
legal C++, has the same semantics in each language.
For example, a K&R C program without prototypes is not legal ANSI C++.

David Hopwood
david.hopwood@lmh.ox.ac.uk

James Kanze (kanze@gabi-soft.fr) wrote:

 > |> >The claim that "every program in K&R is also a C++ program" was made by
 > |> >Stroustrup, and is completely true.
 >
 > |> Actually, no. The claim is that every program that is both legal K&R C, and
 > |> legal C++, has the same semantics in each language.
 > |> For example, a K&R C program without prototypes is not legal ANSI C++.
 >
 > And a C program with prototypes is not K&R C.
 >
 > I think the claim, if true, would refer to ANSI C, and not K&R.
 >
 > In fact, there are a few places where the claim is not true, although
 > I don't think that they would make any difference in a real program.
 > (The classical example is `sizeof( 'a' )', which is guaranteed to be 1
 > in C++, but is typically greater in C.)


Here is the complete claim as found in ``The C++ Programming Language
(2nd Edition)'' Addison-Wesley. ISBN 0-201-53992-6. Appendix B, pg 626-627:

 C++ is based on C (K&R78) and adopts most of the changes specified
 by the ANSI C standard. Converting programs among C++, K&R C, and
 ANSI C may be subject to vicissitudes of expression evaluation.
 All differences between \*C and ANSI C can be diagnosed by a compiler.
 With the following three exceptions, programs that are both C++ and
 ANSI C have the same meaning in both languages:

 In C, sizeof('a') equals sizeof(int); in C++, it equals sizeof(char).

 In C, given

  enum e { A };

 sizeof(A) equals sizeof(int) ; in C++, it equals sizeof(e), which need
 not equal sizeof(int).

 A structure name declared in an inner scope can hide the name of an
 object, function, enumerator, or type in an outer scope. For example,

  int x[99];
  void f()
  {
      struct x { int a; };
      sizeof(x);  /* size of the array in C */
                  /* size of the struct in C++ */
  }

The other quote mentioned in this thread is found of page 6:

 Knowing C is not a prerequisite for learning C++. Programming in C
 encourages many techniques and tricks rendered unnecessary by
 C++ language features. For example, explicit type conversion,
 ``casting,'' is less frequently needed in C++ than it is in C
 (see also the ``Note to C programmers'' below). However, *good*
 C programs tend to be \*C programs. For example, note that every
 program in Kernighan and Ritchie: The C Programming Language
 (2nd Edition)[8] is a C++ program.

There is also a more detailed discussion of the C/C++ compatibility issues
in ``The Design and Evolution of C++'' Addison Wesley, ISBN 0-201-54330-3.

 - Bjarne

In article <D9vHK0.7ou@research.att.com> bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>
>
>Here is the complete claim as found in ``The C++ Programming Language
>(2nd Edition)'' Addison-Wesley. ISBN 0-201-53992-6. Appendix B, pg 626-627:
>
> C++ is based on C (K&R78) and adopts most of the changes specified
> by the ANSI C standard. Converting programs among C++, K&R C, and
> ANSI C may be subject to vicissitudes of expression evaluation.
> All differences between \*C and ANSI C can be diagnosed by a compiler.
> With the following three exceptions, programs that are both C++ and
> ANSI C have the same meaning in both languages:
>
> In C, sizeof('a') equals sizeof(int); in C++, it equals sizeof(char).
>
> In C, given
>
>  enum e { A };
>
> sizeof(A) equals sizeof(int) ; in C++, it equals sizeof(e), which need
> not equal sizeof(int).
>
> A structure name declared in an inner scope can hide the name of an
> object, function, enumerator, or type in an outer scope. For example,
>
>  int x[99];
>  void f()
>  {
>      struct x { int a; };
>      sizeof(x);  /* size of the array in C */
>                  /* size of the struct in C++ */
>  }
>

There are a couple more cases that I believe are similar to the ones
described above. They involve the relatively recent addition of bool
to the langauge.  They also both involve very obscure usage that probably
doesn't exist in any real programs.

This program will print "yes" in ANSI C, but may print "no" in C++
depending on the size of bool.

#include <stdio.h>
int main()
{
 printf("%s\n", sizeof(1<2) == sizeof(int) ? "yes" : "no");
}

Same thing here.  This will print "yes" in ANSI C, but may print
"no" in C++ depending on the size of bool.

#include <stdio.h>
int main()
{
 int(true);
 printf("%s\n", sizeof(true) == sizeof(int) ? "yes" : "no");
}

As I said, these are *really* obscure though.

John Spicer
Edison Design Group

In article <3qnhue$9f2@news.wwa.com> "Robert C. Martin"
<rmartin@oma.com> writes:

|> jim.fleming@bytes.com (Jim Fleming) wrote:

|> >In my opinion, had C++ not been developed at Bell Labs in Murray Hill
|> >New Jersey it would not have made it past a freshman projects course
|> >in Computer Science...

|> This could be so.  After all, BL provided Bjarne with the environment he
|> needed.  Also, there can be little doubt that people were comforted by
|> the fact that C++ was comming from the same source that C had.

|> But that does not mean that if BL had produced a language of poor
|> quality, everybody would have used it.  Rather, I think that if C++
|> had turned out to be half-baked or have other problems, the industry
|> would not have adopted it with the enthusiasm that it now shows.

I can't resist.  Not all languages developed at BL are widely used.
C+@ was developed at BL, and there don't seem to be many people using
it:-).
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung

Orpheus (timd@Starbase.NeoSoft.COM) wrote:

: Well, that is not realistic...it's true that a C programmer is not
: a C++ programmer...but the reverss is not true.

Well, it is to some degree. Whenever I have to write in plain C (rarely,
thank-you), it takes quite a lot of thought to NOT write C++ code. Even
if you throw away inheritance C++ still gives you nice facilities for
structuring and encapsulating code. Doing without even those 'simple'
things is a drag.

James
--
James Brister                                               jamesb@ot.com.au
Open Technology                                          Tel: +61 2 964-9633
                                                         Fax: +61 2 957-5342

In article <3qnia5$9f2@news.wwa.com>, rmartin@oma.com says...
>
>jim.fleming@bytes.com (Jim Fleming) wrote:
>>This is as
>>misleading as claiming that C++ can be used to do true object-oriented
>>programming.
>
>The implication that one cannot do "true object oriented programming" in
>C++ is simply false, or at very least depends upon a very strange
>definition of the word "true".
>
>C++ supports the implementation of object oriented designs, which is
>about the best definition of "true" object oriented programming that
>I can conceive of.
>
>
>Robert C. Martin    | Design Consulting   | Training courses offered:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

AT&T runs ads for something that I think they call "True Voice"...

When you hear those ads do you say, "True Voice is the same as voice".
Therefore, do you define the concept of "True Voice" to be unimportant?

I recently browsed through your "book". I have been trying to figure
out how you came to be so biased and such a C++ zealot. When I read
some of the "acknowledgement" sections it became clear that you have
been indoctrinated by the "True Church of C++"...

...I guess that means that you are the "True Voice of C++"...:)

...there seems to be a *pAT&Tern* to your thinking...:)

(bear with me...I use the word "thinking" here very loosely...)

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

jim.fleming@bytes.com (Jim Fleming) wrote:
>In article <3qnia5$9f2@news.wwa.com>, rmartin@oma.com says...

>>The implication that one cannot do "true object oriented programming" in
>>C++ is simply false, or at very least depends upon a very strange
>>definition of the word "true".
>>
>>C++ supports the implementation of object oriented designs, which is
>>about the best definition of "true" object oriented programming that
>>I can conceive of.

>AT&T runs ads for something that I think they call "True Voice"...
>
>When you hear those ads do you say, "True Voice is the same as voice".
>Therefore, do you define the concept of "True Voice" to be unimportant?

Yes, for the most part it is just marketting BS.

>I recently browsed through your "book". I have been trying to figure
>out how you came to be so biased and such a C++ zealot.

My major bias is against ignorance posing as erudition.

I *do* have a bias for C++, because I have invested a lot of time
learning and mastering it.  More importantly, I have been able to
make very very good use of it in many different projects.

However, I am not biased *against* any other language.  I do not claim
that C++ is superior to all other languages, or even *any* other
languages.  I believe that people who make such claims are acting in
ignorance and arrogance.

As for my zealotry, Scan back through all my articles.  You will find
that I am zealous only in expunging false information, or in correcting
reasoning which I believe to be flawed.  Never once have I been so
foolish or ignorant to claim, or even imply, that everyone should be
using C++.

>When I read
>some of the "acknowledgement" sections it became clear that you have
>been indoctrinated by the "True Church of C++"...

Hmmm.  As alwas you leave out the interesting bits.  Jim, please, I
implore you, identify those characters in my acknoledgements that
have been my indocrinators..

Here, I give you a list of all the names from my Acknowledgements.
You may simply repost this article and put a check mark next to the names of my indoctrinators.  The list is at the end of this article.

In scanning my Acknowledgements I have found a passage that may be
the one to which you refer.  Here, let me quote the guilty paragraph:

       In 1986 I got a copy of Bjanre Stroustrup's first edition of
       the C++ Programming Language.  Its similarity in size and
       style to Kernighan and Ritchie's wonderful "The C Programming
       Language was extremely compelling.  I said to myself, "Oh,
       this must be the next C."

Was this it, Jim?  Was this the moment of my indoctrination?

>...I guess that means that you are the "True Voice of C++"...:)

Interesting, since I have never worked for ATT, never been affiliated
with ATT in any way.  Never taken a cent of money related to ATT.  And
have, in fact, been using MCI as my LD carrier for many years, FYI.

>
>...there seems to be a *pAT&Tern* to your thinking...:)

Jim, I cede to you the award of inane immature innuendo.

>(bear with me...I use the word "thinking" here very loosely...)

That is extremely evident, in all your postings.

Here is the list I promised you.

[] Adelle Goldberg (I read her Smalltalk books)
[] Jim Newkirk
[] Bjarne Stroustrup (I read his first C++ Book)
[] Brian Kernighan (I read "The C programming Langauge")
[] Dennis Ritchie (ditto)
[] Dewhurst
[] Stark
[] Peter Coad
[] Grady Booch
[] Rebecca Wirfs-Brock
[] Wilkerson
[] Wiener
[] Bill Vogel
[] Paul Rogers
[] Bob Weissman
[] Paul Jasper
[] Dae Stevenson
[] Mike Higgs
[] Alan Apt
[] Steve Burroff (reviewed my manuscript)
[] Jim Coplien (reviewed my manuscript)
[] Stan Lippman (reviewed my manuscript)
[] Mike Vilot (reviewed my manuscript)
[] Bret Schuchert (reviewed my manuscript)
[] Ann Marie
[] Angela
[] Micah
[] Gina
[] Justin
[] Jennifer Khonke
[] Mona Pompili
[] Bhama Rao
[] Jim Adcock
[] Steve Clamage
[] Jamshid Afshar
[] Mark Terribile
[] John Skaller
[] Scott Meyers
[] Marshall Cline
[] Paul Lucas
[] Red Mitchell
[] John Goodsen
[] Dave Lasker
[] Ken Finder
[] Jerry Fitzpatrick
[] Tim Conrad

Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

In article <3qlikc$1ph@News1.mcs.com>,
Jim Fleming <jim.fleming@bytes.com> wrote:
>
>Lumping C and C++ together was a "marketing" ploy by the C++ developers.

Well, that is not realistic...it's true that a C programmer is not
a C++ programmer...but the reverss is not true.

>Now that a *large number* of people are discovering the advantages of
>object-oriented programming and OO technology, they are discovering that
>the OO capabilities of C++ are not what they were advertised to be...

I'm sure there is some truth in that.

>In my opinion, had C++ not been developed at Bell Labs in Murray Hill
>New Jersey it would not have made it past a freshman projects course
>in Computer Science...

Well...everyone has there opinion...

>One of the reasons for this is that they are still trying to develop
>a standard version of the language to match their compilers. [...]

It's been my experience that the standards process is long and
arduous...nothing novel about how C++ has gone...

>C++ is a mess. [...]

I'm not sure what that means.  If someone said "C++ is perfect."
then, clearly, that person is wrong.

>The flaws
>in the C++ technology are now starting to show.

Nah...the flaws have been there visible all along.

>It is a shame that a beautiful
>language like C, could be tainted by C++.

Well...opinions again...I would disagree...I think it's great that
the style of programming that I practices in C now has more support
in the compiler.

>C++ and C are very different languages.

Not true.  Every time I write C++ code, I can see the C in it.

>That is one of the reasons that
>there are going to be two different ANSI standards.

The reason is because they are two distinct languges.

>Despite all of the claims made by the C++ developers and the companies
>that promote the language, nobody seems to have any statistics on how many
>people use C++ for object-oriented programming.

Probably true.  In fact, I would venture that those who use more
classically OOP types languages might also have trouble using
the features correctly.  I know that in the Ada would, the term
"Adatran" refers to the programming style of writing Fortran with
Ada syntax.

>[...] It is to C++'s
>benefit to claim that ALL C programmers are C++ programmers.

Okay.  Then let's claim that!  Yeah.  ALL C programmers are C++
programmers!  Yea!

>This is as
>misleading as claiming that C++ can be used to do true object-oriented
>programming.

On, no...more of that alt.religion.OOP spiel...

>Many people have voted with their feet. Smalltalk and Eiffel are growing
>and are good examples of programming languages which can be used to do
>real OO programming.

That's great.  Hopefully, languages like Eiffel will become more
common.  Hopefully, they will become available on more platforms
and provide efficient implementations at reasonable costs.  Hopefully,
there will be engineers that can program in these langugages...
Nothing wrong with progress...

>As people discover that C++ is not well suited to "real" OO programming,

Oops...back to religion, again...

>[...]
>The ++ added to C++ gave everyone an incremental
>"peek" at object-oriented programming but it was not sufficient to carry
>people over the hump.

I guess that remains to be seen...

Something I heard recently...something like "It takes 10 times more
effort to get a new customer than  to keep an old one."  That's because
people don't want to change.  Small changes are easier than big ones.
It is easier to change from C to C++ than from C to Smalltalk...it's
not because C++ is technically superior...it's because we live in a
real world where many factors (including inertia) come into play.

Don't be suprized if the rest of the world ignores your personal
gripes with C++...

-tim d.

--
"This will go down on your permanent record!"

jim.fleming@bytes.com (Jim Fleming) wrote:

>Lumping C and C++ together was a "marketing" ploy by the C++ developers.

I think it is more accurate to say that the lumping of C and C++
together was an attempt to make a language which people would find
useful and accessible.  There is a very strong case to be made that
C++'s current overwhelming popularity is directly related to its
relationship to C.

>Now that a *large number* of people are discovering the advantages of
>object-oriented programming and OO technology, they are discovering that
>the OO capabilities of C++ are not what they were advertised to be...

C++ has never been advertised to be anything other than what it is,
a language that is derived from C and provides support for the
implementation of OO designs.

There has been a great deal of hype about OO in general, and many
people have been disappointed by it because they did not understand
the principles of OO and thought that an OOPL was good enough.
This is unfortunate, but has nothing whatever to do with C++, or
any other OOPL.  It is simply related to the fact that lots of people
tend to go off half-cocked.

>In my opinion, had C++ not been developed at Bell Labs in Murray Hill
>New Jersey it would not have made it past a freshman projects course
>in Computer Science...

This could be so.  After all, BL provided Bjarne with the environment he
needed.  Also, there can be little doubt that people were comforted by
the fact that C++ was comming from the same source that C had.

But that does not mean that if BL had produced a language of poor
quality, everybody would have used it.  Rather, I think that if C++
had turned out to be half-baked or have other problems, the industry
would not have adopted it with the enthusiasm that it now shows.

>C++ is a mess. The developers like to claim it is a "marketing" mess
>and there is nothing wrong with the technology. I disagree. The flaws
>in the C++ technology are now starting to show.

Most people who use C++ are well aware of the flaws.  Or rather, they
are well aware that the language comprises a set of engineering
trade offs.  Most of us are also well aware that it is those very
trade-offs that give the language its nearly universal appeal.

>Many people have been
>looking at these flaws for over 10 years. It is a shame that a beautiful
>language like C, could be tainted by C++.

Not everyone agrees that C is such a beautiful language.  It too is full
engineering trade offs, and problems.  Some claim that these problems are
at the heart of the flaws in C++.  I disagree on all accounts.  C has
proven its utility by being heavily used.  C++ has done the same.

>C++ and C are very different languages. That is one of the reasons that
>there are going to be two different ANSI standards. Hopefully, there
>will not be any movement to merge the two languages and ANSI C can live
>on as ANSI C++ dies a quiet death.

Actually, I think that just the opposite will occur.  C programmers
and C projects will slowly and inevitably migrate to C++.  Bit by
bit the number of C users will decline and the number of C++ users
will increase.

>Despite all of the claims made by the C++ developers and the companies
>that promote the language, nobody seems to have any statistics on how many
>people use C++ for object-oriented programming.

There are, of course, several problems with this.  First, there is not
central regulating body that is in a position to gather such
statistics.  Second, there is no universally accepted definition
of OO programming.  My definition is probably very different from yours.
Third, there is no real demand for this information.  About the only
folks who want to see this information are the ones who have an
ulterior motive for asking a question they know cannot be answered.
IMHO.

>C++ has benefited from
>this convienant lack of "classification" of C programmers. It is to C++'s
>benefit to claim that ALL C programmers are C++ programmers. This is as
>misleading as claiming that C++ can be used to do true object-oriented
>programming.

No such claim has ever been made by reputable sources to my knowledge.
The claim that "every program in K&R is also a C++ program" was made by
Stroustrup, and is completely true.  But this does not make C programmers
C++ programmers.  There is a very wide difference as every C++ programmer
knows.

>Many people have voted with their feet.

Indeed!  The sheer number of C++ compilers that have been sold is well into
7 orders of magnitude.

>Smalltalk and Eiffel are growing
>and are good examples of programming languages which can be used to do
>real OO programming.

Agreed.

> As people discover that C++ is not well suited to
>"real" OO programming, they will likely regress to using just the ANSI C
>features of C++.

I don't think that many people will discover this, because it isn't true.
In my experience, people who take the time to learn OOD can make very
good use of C++.


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

jim.fleming@bytes.com (Jim Fleming) wrote:
>This is as
>misleading as claiming that C++ can be used to do true object-oriented
>programming.

The implication that one cannot do "true object oriented programming" in
C++ is simply false, or at very least depends upon a very strange
definition of the word "true".

C++ supports the implementation of object oriented designs, which is
about the best definition of "true" object oriented programming that
I can conceive of.


Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

Robert C. Martin (rmartin@oma.com) wrote:

: But that does not mean that if BL had produced a language of poor
: quality, everybody would have used it.  Rather, I think that if C++
: had turned out to be half-baked or have other problems, the industry
: would not have adopted it with the enthusiasm that it now shows.

It is debatable whether or not C++ is of "poor quality".

However from my experience with C++ since 1988, I have observed
a lot of adoption without a deep understanding of the language.
I cannot say whether these adopters would have done differently
had they done more of an assessment.

--
Patrick_D_Logan@ccm.jf.intel.com
Intel/Personal Conferencing

"Form follows function." -Le Corbusier

In article <MATT.95Jun1143338@dogbert.lbl.gov>, matt@dogbert.lbl.gov says...
>
>In article <3ql7oe$17a@uuneo.neosoft.com> timd@starbase.neosoft.com (Loki)
writes:
>
>> Lots (most?) of PC software is written in C/C++.  Many database engines
>> are, too.  What languages does Microsoft use?  Are they among
>> the ignorant, too?  And all that network/telecom software...
>> And so much UNIX software...X windows?
>
>C and C++ are two very different languages: lumping them together as
>"C/C++" obscures too much.
>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Lumping C and C++ together was a "marketing" ploy by the C++ developers.

Now that a *large number* of people are discovering the advantages of
object-oriented programming and OO technology, they are discovering that
the OO capabilities of C++ are not what they were advertised to be...

Have people been mislead...???...you have to be the judge...

In my opinion, had C++ not been developed at Bell Labs in Murray Hill
New Jersey it would not have made it past a freshman projects course
in Computer Science...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

>X itself is written in C, not C++, and so are most of the X toolkits
>out there.  (Although there are some C++ X toolkits now.)  Similarly,
>I'm not aware of any popular Unix freeware that is written in C++.
>TeX is sort of written in Pascal, and gcc, f2c, Emacs, gnuplot,
>ghostscript, Perl, ispell, and the FSF shell utilities are written in
>C.  Quite a few of the C programs I've named, in fact, are written in
>K&R C.
>
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

One of the reasons for this is that they are still trying to develop
a standard version of the language to match their compilers. It is
difficult to develop a large base of freeware when most of the compilers
can not compile average programs. Also, in some cases one generation of
a company's C++ compiler does not compile programs it once compiled.

C++ is a mess. The developers like to claim it is a "marketing" mess
and there is nothing wrong with the technology. I disagree. The flaws
in the C++ technology are now starting to show. Many people have been
looking at these flaws for over 10 years. It is a shame that a beautiful
language like C, could be tainted by C++.

C++ and C are very different languages. That is one of the reasons that
there are going to be two different ANSI standards. Hopefully, there
will not be any movement to merge the two languages and ANSI C can live
on as ANSI C++ dies a quiet death.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

>Certainly C++ compilers sell well in the micro world.  I have no idea,
>though, how many of them are really used for C++ programming and how
>many are simply used as C compilers.  I doubt if any good numbers
>for that exist.
>
>                        --matt
>--
>Matt Austern                                  matt@physics.berkeley.edu
>http://dogbert.lbl.gov/~matt

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Despite all of the claims made by the C++ developers and the companies
that promote the language, nobody seems to have any statistics on how many
people use C++ for object-oriented programming. C++ has benefited from
this convienant lack of "classification" of C programmers. It is to C++'s
benefit to claim that ALL C programmers are C++ programmers. This is as
misleading as claiming that C++ can be used to do true object-oriented
programming.

Many people have voted with their feet. Smalltalk and Eiffel are growing
and are good examples of programming languages which can be used to do
real OO programming. As people discover that C++ is not well suited to
"real" OO programming, they will likely regress to using just the ANSI C
features of C++. At that point, we should get in the habit of using the
term "C" to describe the language used by the majority of systems
programmers in the world. The ++ added to C++ gave everyone an incremental
"peek" at object-oriented programming but it was not sufficient to carry
people over the hump.

How does that song go...???

 American The Beautiful....from C to shining C...:)

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
jrf@tiger.bytes.com  /  | \     One Naperville Plaza   184 Shuman Blvd. #100
%Techno Cat I       /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       http:199.3.34.13 telnet: port 5555
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

jpb@iris85.biosym.com (Jan Bielawski) writes:

>In article <3nlppb$fs@News1.mcs.com> jim.fleming@bytes.com (Jim Fleming) writes:
><
><Please bear with the C++ people. For the past 15 years they have been
><deluding themselves into thinking that they have been doing Object Oriented
><Programming.

>Who cares?  What counts is: "can the job be done?"  Yes, it can.
>End of conversation.  As to "what" exactly is OOP, people who write
>software profesionally for the marketplace couldn't care less.

If I may amplify this statement:  There are many programmers who take
a pragmatic view.    They don't care about what pure OOP is.  Rather
they care about good design principles.  There is a difference.

In my view, there are many good design principles to be learned from
OO, and many good tools for creating and implementing good designs.

><This is what results from a language like C++ that allows you to slip
><in and out of the paradigm.

>What nonsense.  Just because a paradigm exists and has a name doesn't
>mean using it exclusively is in any way superior to using several
>whenever situation demands.

Right.  Purity of Paradigm (POP) is probably less effective than
applying experienced judgement to any design problem.


--
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++

In article <3nlppb$fs@News1.mcs.com> jim.fleming@bytes.com (Jim Fleming) writes:
<
<Please bear with the C++ people. For the past 15 years they have been
<deluding themselves into thinking that they have been doing Object Oriented
<Programming.

Who cares?  What counts is: "can the job be done?"  Yes, it can.
End of conversation.  As to "what" exactly is OOP, people who write
software profesionally for the marketplace couldn't care less.

<This is what results from a language like C++ that allows you to slip
<in and out of the paradigm.

What nonsense.  Just because a paradigm exists and has a name doesn't
mean using it exclusively is in any way superior to using several
whenever situation demands.
--
Jan Bielawski    |\      _,,,---,,_
Biosym Technologies   /,`.-'`'    -.  ;-;;,_
San Diego, CA   |,4-  ) )-,_. ,\ (  `'-'   | ph.: (619) 458-9990
jpb@biosym.com  '---''(_/--'  `-'\_)        fL   | fax: (619) 458-0136
--
****************************************************************************
* DISCLAIMER: Unless indicated otherwise, everything in this note is       *
* personal opinion, not an official statement of Biosym Technologies, Inc. *
****************************************************************************

jim.fleming@bytes.com (Jim Fleming) writes:

>In article <3nmbnl$3gm@booch.legent.com>, jtsay@pit.legent.com says...
>>
>>In article <3nlppb$fs@News1.mcs.com>,
>>   jim.fleming@bytes.com (Jim Fleming) wrote:
>>>One thing for sure, no one will make much progress in the 90's using C++.
>>
>>Bear with me not knowing where you are coming from. But what is your
>proposal?
>>What is your language of choice and why?

>@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>LanguageS of Choice:

>1. C for systems programming...
> ...using procedural programming techniques.

>2. C+@ for programming systems...
> ...using Object Oriented programming techniques.

>C+@ (CAT) is a "companion" language to C. It has the power of Smalltalk
>with a C syntax. The language is clean, elegant, and easy to understand.
>The C+@ binaries are architecture neutral and can be reused across the
>Internet WITHOUT recompiling for the processor of an end-user. Classes,
>objects, methods, etc. can be exchanged via a distributed object platform.
>C is used for low-level systems programming and is rarely needed by a
>C+@ programmer much like assembly language for a C programmer.

Does C+@ exist? Or are you just it's are you hired to give it publicity.
It sounds like something possible but then my mind is open.  C in my mind is
nearly a portable assembly language.  C++ adds some very nice features to that
portable assembly language such as objects, encapsulation, and code reuse.
It does have an ugly syntax as compared to C but that's manegable.  It also
has the nice feature of very few hidden mechanisms, at least to the implementor
who is writing the secion.

Now C+@ has some very serious hidden mechanisms, first of all if your ftp site
is any indication it has no source code, and no object code.  I agree that
implementation independant binarys could be quite useful, and of course some
constant factor slower and less efficient than implementation specific
binaries.  If C++ truly succeeds then perhaps your C+@ programers may never
need to sink to C they could use C++ and all it's objects for systems work.

>Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

All languages have their place and system independant binaries are cool, but
please void is a little more system independant then I like.  Now if you

In article <3nmbnl$3gm@booch.legent.com>, jtsay@pit.legent.com says...
>
>In article <3nlppb$fs@News1.mcs.com>,
>   jim.fleming@bytes.com (Jim Fleming) wrote:
>>One thing for sure, no one will make much progress in the 90's using C++.
>
>Bear with me not knowing where you are coming from. But what is your
proposal?
>What is your language of choice and why?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
LanguageS of Choice:

1. C for systems programming...
 ...using procedural programming techniques.

2. C+@ for programming systems...
 ...using Object Oriented programming techniques.

C+@ (CAT) is a "companion" language to C. It has the power of Smalltalk
with a C syntax. The language is clean, elegant, and easy to understand.
The C+@ binaries are architecture neutral and can be reused across the
Internet WITHOUT recompiling for the processor of an end-user. Classes,
objects, methods, etc. can be exchanged via a distributed object platform.
C is used for low-level systems programming and is rarely needed by a
C+@ programmer much like assembly language for a C programmer.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
%Techno Cat I        /  | \     One Naperville Plaza   184 Shuman Blvd. #100
Penn's Landing      /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       e-mail: jim.fleming@bytes.com
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <D7nnz4.Jwy@research.att.com>, 9758-26353 says...
>
>
>
>Article 81291 of comp.lang.c++:
>
>ian@syacus.acus.oz.au (Ian Joyner):
>
> > My point about C++ is that it is
> > currently being pushed into domains where it doesn't fit. And
> > I think from what Bjarne Stroustrup says, his view would not
> > be much different.
>
>C++ is being tried out in MANY areas, and naturally it will not
>be equally successful in all of those. However, I suspect that
>my estimate of the set of appropriate areas for C++ use would be
>significantly larger than Mr. Joyner's.
>
>A major reason that people are willing to try out C++ in new
>areas is that it has often proven successful in areas where
>someone predicted utter failure. This complicates the task of
>estimating where C++ will and will not deliver benefits
>commensurate with the effort needed to use it.
>
>        - Bjarne
>

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

When you talk about successes, are you referring to the OO extensions
 of C++ or just the ANSI C portions of C++?
  (or just the added comment format // comments?)

Can you provide any hard numbers on these successes?

How about starting with your company, AT&T?

Can you document the history of "success" with C++ in Switching System
 developments?

Does AT&T 5ESS Switching System Development use the OO extensions
 of C++?

When other "people" report in this group they are consistently asked
 to back up their claims with hard facts. Do you think you
 should be held accountable to the same standards?

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
%Techno Cat I        /  | \     One Naperville Plaza   184 Shuman Blvd. #100
Penn's Landing      /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       e-mail: jim.fleming@bytes.com
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <3nlj4q$f4c@atlantis.utmb.edu>,
cbass%intmeds1.utmb@mhost.utmb.edu says...
>
>dewar@cs.nyu.edu (Robert Dewar) wrote:
>>
>> Curtis, I find your long tirade on "pure" peculiar. Are you trying to
make
>> a technical point here, or just continue a flame war? If you are trying
to
>> make a technical point, then it should by now be clear to you that this
>> technical point is likely to get missed because of the confusion over
>> irrelevant connotations of the word pure.
>>
>> So, if you are interested in actually making a technical point, you might
>> consider the choice of a better term that would make your point clearer.
>> If you only use "pure" to mean "homogenous", then why not use the latter
>> word directly, I think you would find that your point is clearer to
others,
>> and generally that should always be the aim of technical discussion.
>>
>> Of course anyone can use any terms they like, but the use of loaded terms
>> in my experience tends to intefere with effective technical discussion.
>
>-- snip --
>
>From "Software Development" magazine, vol. 3 no. 6, May, 1995,
>page 18, "Hello World" column, author is Bill Lazar:
>
>        Smalltalk is a "pure" object-oriented language that
>        supports single inheritance, encapsulation, and
>        polymorphism; everything is an object, and so there
>        are none of the dislocations found in C++, in which
>        some variables represent objects and others do not.
>
>From "Software Development" magazine, vol. 1 no. 4, Oct, 1993,
>page 65, "Product Wrap-up" column, author is Kyle Brown:
>
>        Since its introduction by Xerox in the 1980s as the
>        world's first pure object-oriented language, Smalltalk
>        has grown to be a powerful tool for developing many
>        types of applications in MIS and engineering.
>
>From "Dr. Dobb's Journal" magazine, vol. 14. no. 12, Dec, 1989,
>page 3, Table of Contents by-line:
>
>        Eiffel's been described as the only pure object-oriented
>        currently around.
>
>From "Object-Oriented Systems Design" 1994 Prentice Hall,
>page 295, author is Ed Yourdon:
>
>        . . . most projects that have committed themselves to
>        OOA and OOD can be expected to use a "pure" or at least
>        a "quasi" OOPL.
>
>From page 296:
>
>        Similarly, Eiffel is much more "pure" in it's object-
>        oriented features than C++, but it also suffers from
>        minor-league status . . .
>
>From "Object-Oriented Design with Applications" 1991 Benjamin/Cummings,
>appendix A.2, page 474, author is Grady Booch:
>
>        [Smalltalk] is a "pure" object-oriented programming
>        language, in that everything is viewed as an object --
>        even integers and classes.
>
>The point here is that I, Curtis Bass, did NOT invent the term
>"pure OOPL," nor did I decree that the term "pure" would be
>used in this context. All I have done is to adopt the terminology
>that has been widely used throughout the trade press since at
>least 1989, SIX YEARS ago. My question is: Where have y'all
>been these past six (or more) years?
>

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Curtis,

Please bear with the C++ people. For the past 15 years they have been
deluding themselves into thinking that they have been doing Object Oriented
Programming.

This is what results from a language like C++ that allows you to slip
in and out of the paradigm. All of this "in and out" over the past 15
years has not gotten these people very far, with respect to the rest of
the industry.

Fortunately or unfortunately, C++ people are harmless because they do not
know enough to know what they do not have. This is similar to the situation
10 years ago when "PC-people" tried to talk to "mainframe-people". C++
people are the new MIS of the 90's. Their brains and knowledge are MISsing
but their intentions are good. All they want to do is hold a steady job
and to feed their children. No one can fault them for having priorities
which do not involve remaining at the "leading edge" of the industry.

The consesus is that C++ people have been lead down the garden path by
a well orchestrated group of technical prima donnas who derive substantial
financial benefit from the "C++ industry". As long as the "followers"
continue to put coins in the collection plates of the high priests, the
priests will continue to preach. That is the nature of the beast.

All of this is justified by what is now called "market" accpetance. Since
there is a huge market for people that want to be "told" that they are doing
OO when they are not even close, there is a huge supply of people willing
to tell these people they are "doing it". This is no different than the
religious communities that thrive on telling people that they are holy
because they pay the religious leaders money to tell them this. Everyone
feels good. This is called a "win-win" situation.

In the "old days" of mainframes, IBM made a fortune telling MIS directors
that they were "doing it". MIS directors were paid a fortune by their
companies to continue "doing it" with IBM. Everyone was happy, until the
PC came along. Maybe IBM, should have kept it "under wraps"?

C++ is the PL/I of the 90's. The C++ community operates just like the old
mainframe groups of the 80's. They do not want to hear anything that is
not what they have been told and they do not understand what other options
are available to them. I suggest that this group will go the way of the
mainframers. Unfortunately, it will take a lot of time and the time wasted
to date on C++ is lost. The people that have been deluded into thinking
they are doing OO are also lost. It is not their fault they are ignorant.
It is unfortunate that their ignorance can not be hidden from the public
view. It is also unfortunate that they do not know how far behind they are.

Even though there is not a lot of humor in this situation it is interesting
to note that many of the leaders of the C++ movement were supported by
organizations that helped to destroy the mainframers. Maybe this is true
justice. Maybe the mainframers of the 80's will be recycled and become
the "real" OO people of the 90's and will have the last laugh. One thing
for sure, no one will make much progress in the 90's using C++. Anyone
that has not been brainwashed by the C++ machine AND that spends the time
evaluating the alternatives AND spends the time projecting where the future
will be...will not spend more than 21 days studying C++...

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

>No, I am not interested in flame wars. But then again, I am
>also not interested in confusing the issue further by adopting
>or proposing new terminology, when the extant terminology is
>quite sufficient.
>
>The fact that many people are ignorant re: the use of the
>term "pure" in the discussion of OOPLs is simply something
>that is beyond my control. I cannot stop this widespread
>ignorance -- all I can do is to attempt to educate those
>who are willing to listen. Unfortunately, there are many
>who will not listen -- they would rather put up straw man
>arguments as to why a "pure" OOPL is not really pure after
>all, and how, therefore, the terminology is meaningless.
>I have said numerous times that, if you don't find the term
>to be useful, then don't use it. Just don't try and tell me
>that I can't use it.
>
>
>                                Curtis Bass
>                                Software Systems Specialist II
>                                University of Texas Medical Branch
>

--
Jim Fleming            /|\      Unir Corporation       Unir Technology, Inc.
%Techno Cat I        /  | \     One Naperville Plaza   184 Shuman Blvd. #100
Penn's Landing      /   |  \    Naperville, IL 60563   Naperville, IL 60563
East End, Tortola  |____|___\   1-708-505-5801         1-800-222-UNIR(8647)
British Virgin Islands__|______ 1-708-305-3277 (FAX)   1-708-305-0600
                 \__/-------\__/       e-mail: jim.fleming@bytes.com
Smooth Sailing on Cruising C+@amarans  ftp: 199.3.34.12 <-----stargate----+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\____to the end of the OuterNet_|

In article <3nlppb$fs@News1.mcs.com>,
   jim.fleming@bytes.com (Jim Fleming) wrote:
>One thing for sure, no one will make much progress in the 90's using C++.

Bear with me not knowing where you are coming from. But what is your proposal?
What is your language of choice and why?