ellis@parc.xerox.com (John Ellis) writes:

>I wrote that casts from pointers to integers and back need to be
>prohibited to allow safe operation of C++ garbage collectors.  Fergus
>Henderson responds:
>
>    Yes, it's hardly a restriction at all, since the code wasn't
>    strictly conforming C++ anyway.
>
>I disagree -- according to the ARM and the June '94 draft:
>
>    A pointer converted to an integer of sufficient size (if any such
>    exists on the implementation) [...]
>
>Has this been changed in later versions of the draft working paper?

No.  "Strictly conforming" code is code that is works on ALL
conforming implementations.  Code that uses this feature won't
work on some implementations, hence it's not strictly conforming.

I was probably being a little bit overly legalistic.

bhawley@orion.it.luc.edu (Brian Hawley) writes:
>Ah, finally something that I have competency in!
>It would be much easier to retrofit Eiffel, Scheme, Oberon and such with
>a custom garbage collector because those languages have been specifically
>designed to allow GC. These languages place restrictions on the behavior
>of pointers, do not allow integers to be used as pointers (or don't trace
>them), and have certain structures in memory that facilitate GC. These
>structures and restrictions can be used to implement your alternate GC in
>the same way that they were used in the standard.

>C++ does not have these restrictions, nor does it have the necessary
>structures to do GC with the same ease that Eiffel and such do. Therefore
>if you intend to use GC _of_any_kind_ in your system, it is better that
>you start with a language that was designed with that ability in mind.

      But see the Ellis/Detlefs paper on garbage collection for
C++, and a safe subset of C++ that makes it work.  They impose very
few restrictions on C++, and use Boehm's garbage collector.  If
you send E-mail to "ellis@parc.xerox.com", he'll send you his
paper on the subject.

     John Nagle

ichudov@wiltel.com (Igor Chudov) writes:
>None of existing Eiffel vendors provides incremental garbage collector that
>can work in parallel with the execution (or stealing LITTLE pieces of
>processor time), although Tower informed that they have been working on this
>problem. This type of GC can enable the apps to be really (sorry for the
>clumsiness) real-time.

>To be able to use the latter type of GC, however, whole runtime system has to
>be modified along with the GC, so it is hardly possible to add realtime GC
>without changes in runtime. The argument that we can add our own realtime
>GC to existing runtime sounds too optimistic.

I'm not an expert on real-time programming.  But I'm always confused
by these discussions.  It seems to me that "real-time" is usually
intended to mean one of the following two extremes, or anything
in between:

1. Reasonable interactive response on a fast machine.  Maybe good enough
so that a video game isn't too jerky.

2. Part of a safety critical system that requires millisecond or so
GUARANTEED response, and GUARANTEED space bounds.

At the first extreme, even stop-the-world collectors may be adequate,
and VM-synchronized collectors are usually fine.  It's possible
to provide this sort of collector largely as an add-on library, even for (very
slightly restricted) C, at least with appropriate OS support.

My impression is that essentially no application at the second extreme
currently uses any form of dynamic memory allocation, either malloc/free
style, or garbage collected.  (They also don't use VM, or conventional
networks.  They may avoid processor caches.)  My guess is that there are such
applications that could benefit from dynamic allocation, but they're probably
in the minority (which doesn't make them uninteresting).  There are several
obstacles in the way:

a. If you use a malloc/free style facility you have to bound allocation
time and fragmentation overhead.  Most standard implementations don't
have terribly useful worst-case bounds on either (though their average
performance may be very good).

b. Most (all?) language specifications say nothing useful about resource
consumption, and particularly not space consumption.
Most conventional implementation specifications aren't much better.
You clearly need (at least) compiler-dependent tools to analyze worst-case
resource consumption.

c. A compacting real-time GC avoids problem (a), but requires compiler
support, and some run-time overhead.  But point (b) also requires
specialized compiler support.

d. Since you have to statically bound worst-case space usage, it may
often be just as easy to allocate space statically.  (I would love to know
how often this is really the case.  Any informed opinions?)

I suspect this discussion is really about points somewhere between the
above 2 extremes.  But it would be nice to make that explicit.

Hans-J. Boehm
(boehm@parc.xerox.com)
Standard disclaimer ...

In article <3e1rqn$ouh@news.parc.xerox.com>,
Hans Boehm <boehm@parc.xerox.com> wrote:

>I'm not an expert on real-time programming.  But I'm always confused
>by these discussions.  It seems to me that "real-time" is usually
>intended to mean one of the following two extremes, or anything
>in between:
>
>1. Reasonable interactive response on a fast machine.  Maybe good enough
>so that a video game isn't too jerky.
>
>2. Part of a safety critical system that requires millisecond or so
>GUARANTEED response, and GUARANTEED space bounds.

Actually, neither is really correct.  Typically real-time == real-fast.
However, real-fast != real-time.  Also, real-time !-> real-fast
(read: does not imply).

It's easiest to just remember that real-time applications factor time
into their performance specification.  Contrast this with non-real-time
applications, whether batch or interactive:
  - the IRS processing tax returns
        batch, obviously wants to be VERY fast since there are so
        many returns to be processed, but NOT real-time; if a return
        isn't processed in the next mS, S or even day, the application
        *still* continues to function properly
  - a PC user editing a document
        interactive, would like to be reasonably fast soas not to annoy
        the user; again not real-time...
By contrast, an ABS break system for a car is real-time as it must respond
within a predefined time window.  This example is moderately fast (on the
order of milliseconds) but it need not be "real-fast".  I guess to stretch
the analogy, a pacemaker could also be considered a "slow" real-time
system... it deals with evcents on theorder of a second.

These two examples also can be used to distinguish between soft and
hard real time applications; but, you could make a case for either one
being the HRT case (or both or neither, depending on your system
specification).  For example, you could envision the brakes as HRT in
that they MUST be serviced "now" -- or, as is typical in most available
ABS systems, the manual system functions even in the absence of ABS
and so failure to service the brake event could be undesirable, but
tolerable occasionally.  Likewise, the pacemaker could be HRT if
you assume the patient's heart must be kicked NOW... or, you could
envision it as soft real-time figuring "better late than never".
The distinction lies in the value function you associate with the
task's deadline.

>At the first extreme, even stop-the-world collectors may be adequate,
>and VM-synchronized collectors are usually fine.  It's possible
>to provide this sort of collector largely as an add-on library, even for (very
>slightly restricted) C, at least with appropriate OS support.

Yes. Assuming the OS deal's with "real-time" and not just "real-fast"...

>My impression is that essentially no application at the second extreme
>currently uses any form of dynamic memory allocation, either malloc/free
>style, or garbage collected.  (They also don't use VM, or conventional
>networks.  They may avoid processor caches.)  My guess is that there are such
>applications that could benefit from dynamic allocation, but they're probably
>in the minority (which doesn't make them uninteresting).  There are several
>obstacles in the way:
>
>a. If you use a malloc/free style facility you have to bound allocation
>time and fragmentation overhead.  Most standard implementations don't
>have terribly useful worst-case bounds on either (though their average
>performance may be very good).
>
>b. Most (all?) language specifications say nothing useful about resource
>consumption, and particularly not space consumption.
>Most conventional implementation specifications aren't much better.
>You clearly need (at least) compiler-dependent tools to analyze worst-case
>resource consumption.
>
>c. A compacting real-time GC avoids problem (a), but requires compiler
>support, and some run-time overhead.  But point (b) also requires
>specialized compiler support.
>
>d. Since you have to statically bound worst-case space usage, it may
>often be just as easy to allocate space statically.  (I would love to know
>how often this is really the case.  Any informed opinions?)
>
>I suspect this discussion is really about points somewhere between the
>above 2 extremes.  But it would be nice to make that explicit.

Again, all of this depends upon your application's real-time criteria.
It depends upon whether or not you are HRT or SRT.  And, it also depends
on whether your OS can detect missed deadlines and how you recover from
this...

I'm working on an application which uses all of these "no-no's":
malloc/free (actually new/delete), VM and GC.  The trick is making
sure that a mechanism is suited to the particular area of
application.  For instance, all my interrupt drivers are wired down
to avoid the chance of encountering a page fault when least expected ;-)
Yet, other parts of the application are free to swap to fit the
hardware implementation I choose.

Brian Hawley writes:

    These languages [Eiffel, Scheme, Oberon] place restrictions on the
    behavior of pointers, do not allow integers to be used as pointers
    (or don't trace them) ... C++ does not have these restrictions ...

Contrary to the received wisdom, no significant restrictions need be
placed on the C++ language to allow for efficient garbage collection.
Compared to other GC langauges such as Eiffel, Oberon, Modula-3, Lisp,
etc. there are only three C++ language features that raise specific
issues for garbage collection: interior pointers, unions, and casts
from pointers to integers and back.  Of these, only the last needs to
be restricted.

In implementations where a sufficiently large integer type exists, C++
allows a pointer to be cast to an integer and back to a pointer,
potentially hiding the pointer from the garbage collector.  This
dubious language feature is not portable, since some implementations
may not have an integer type sufficiently large to hold a pointer.
There is no practical way for a collector to handle this language
feature, so its use must be prohibited when using GC.  This is not an
important restriction.

For more information on C++ garbage collection, see "Safe, Efficient,
Garbage Collection for C++", by myself and Dave Detlefs
(ftp://ftp.parc.xerox.com/pub/ellis/gc).

     I had to make the same restrictions on C++ behavior that Oberon
     has. Unfortunately, since these restrictions couldn't be
     enforced, the C++ code was slower than the corresponding Oberon
     code (although it was at least as fast as code made in the normal
     C++ style).

Can you give details about which restrictions on C++ code caused its
garbage collection to be slower than the corresponding Oberon code?

I wrote that casts from pointers to integers and back need to be
prohibited to allow safe operation of C++ garbage collectors.  Fergus
Henderson responds:

    Yes, it's hardly a restriction at all, since the code wasn't
    strictly conforming C++ anyway.

I disagree -- according to the ARM and the June '94 draft:

    A value of integral type can be explicitly converted to a pointer.
    A pointer converted to an integer of sufficient size (if any such
    exists on the implementation) and back to the same pointer type
    will have its original value; mappings between pointers and
    integers are otherwise implementation-defined. [5.2.9]

Has this been changed in later versions of the draft working paper?
(This is a wierd corner of the language, since it explicitly defines
the behavior of a feature that won't work on all implementations.  It
was inherited from C.)


Fergus also says that the following byte scrambling is conforming and
that therefore a garbage-collection proposal must prohibit it:

    int i, *p;
    unsigned char buf[sizeof(int*)], *p_rep = (char *) &p;

    p = (int *)malloc(sizeof(int));
    *p = 0;

    for (i = 0; i < sizeof(int*); i++)
        buf[i] = p_rep[sizeof(int*) - 1 - i];

I disagree.  While this code "conforms", its behavior is unspecified
(implementation-dependent):

    A pointer to an object can be explicitly converted to a pointer to
    an object of different type.  In general, the results of this are
    unspecified... [5.2.9]

(Has this changed recently?)

Such constructs do not need to be explicitly prohibited by the
garbage-collection language proposal.  According to the C++
specification, the behavior of any program that uses an
implementation-dependent construct is by definition
implementation-dependent, regardless of whether it uses garbage
collection.  How an implementation's collector behaves in the presence
of such constructs is thus up to the implementation.

Our proposal contains a complete discussion of these safety issues.

John Ellis (ellis@parc.xerox.com) wrote:
: Brian Hawley writes:
:      I had to make the same restrictions on C++ behavior that Oberon
:      has. Unfortunately, since these restrictions couldn't be
:      enforced, the C++ code was slower than the corresponding Oberon
:      code (although it was at least as fast as code made in the normal
:      C++ style).

: Can you give details about which restrictions on C++ code caused its
: garbage collection to be slower than the corresponding Oberon code?

The garbage collection code itself was not slower; all of the converted
code was. I believe that the difference arose when the C++ compiler tried
to optimize code that was logically structured to be efficient Oberon.
Certain common operations like type-tests are typically more efficient in
a single-inheritance system, and certain arithmetic operators behave
differently in Oberon. These differences had to be adjusted for, and the
adjusted operations were not as efficient.

It was not restrictions in C++ that caused the slowdown in any case. The
natural flexibility of C++ (mostly inherited from C) was the problem in
the situations where restriction was a factor. Because the restrictions
that were placed on the C++ code by its source (Oberon) were not known to
the C++ compiler, they could not be depended on for extra optimizations.
Also, the common expressions of the two languages aren't the same. A native
code compiler for Oberon has this knowledge and can take advantage of it.

Thanks for the gc reference. I look forward to reading it.

Brian Hawley
bhawley@orion.it.luc.edu and math.luc.edu

ellis@parc.xerox.com (John Ellis) writes:

>Contrary to the received wisdom, no significant restrictions need be
>placed on the C++ language to allow for efficient garbage collection.
>Compared to other GC langauges such as Eiffel, Oberon, Modula-3, Lisp,
>etc. there are only three C++ language features that raise specific
>issues for garbage collection: interior pointers, unions, and casts
>from pointers to integers and back.  Of these, only the last needs to
>be restricted. [...] This is not an important restriction.

Yes, it's hardly a restriction at all, since the code wasn't strictly
conforming C++ anyway.

But there is one feature C and C++ that you missed: byte manipulation
of pointers.  Now that particular feature is not used very often, but
it *is* strictly conforming, and it does need to be disallowed if you
want to use GC.

For example, the following program is strictly conforming C and C++ (or at least
could be made strictly conforming - it's possible that it contains
some bugs ;-), but would cause problems with a garbage-collected implementation.

 void force_garbage_collection() {
  for (int i = 0; i < 10000000; i++)
   if (!malloc(1000)) break;
 }
 int main() {
  int i, *p;
  unsigned char buf[sizeof(int*)], *p_rep = (char *) &p;

  // allocate space for object, and initialize it
  p = (int *)malloc(sizeof(int));
  *p = 0;

  // scramble the bytes of the pointer
  for (i = 0; i < sizeof(int*); i++)
   buf[i] = p_rep[sizeof(int*) - 1 - i];
  p = 0;

  // this will cause the GC to collect the object
  force_garbage_collection();

  // unscramble the bytes of the pointer
  for (i = 0; i < sizeof(int*); i++)
   p_rep[sizeof(int*) - 1 - i] = buf[i];

  // access the object whose memory has already been collected
  return *p;
 }

If you want GC, you need to explicitly forbid programs like that.

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

James McKim (jcm@hgc.edu) wrote in comp.lang.c++:

[ ... many absolutely right things ... ]

: >
: >To be able to use the latter type of GC, however, whole runtime system has to
: >be modified along with the GC, so it is hardly possible to add realtime GC
: >without changes in runtime. The argument that we can add our own realtime
: >GC to existing runtime sounds too optimistic.

: Well, I didn't say it would be _easy_ :-). But why would building
: your own garbage collector be more difficult for an Eiffel system
: than it would be for a C++ system?

Well, it seems like another holy war is about to start... Let us postpone
it.

--
Happy Holidays!
----------------------------------------------------------------------------
IMHO. Igor Chudov,      Resource Solutions Intl         office (918)588-2309
Systems Engineer,       for WilTel.                     home   (918)585-5862
                                          E-mail:     igor_chudov@wiltel.com
                                          http://m-net.arbornet.org/~ichudov
                                     1819 South Jackson #32-P Tulsa OK 74107

                 f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

James McKim (jcm@hgc.edu) wrote:
: In article <3da1nd$fss@gateway.wiltel.com> igor_chudov@wiltel.com (Igor Chudov) writes:
 [snip unrelated stuff]
: >
: >To be able to use the latter type of GC, however, whole runtime system has to
: >be modified along with the GC, so it is hardly possible to add realtime GC
: >without changes in runtime. The argument that we can add our own realtime
: >GC to existing runtime sounds too optimistic.

: Well, I didn't say it would be _easy_ :-). But why would building
: your own garbage collector be more difficult for an Eiffel system
: than it would be for a C++ system?

Ah, finally something that I have competency in!

It would be much easier to retrofit Eiffel, Scheme, Oberon and such with
a custom garbage collector because those languages have been specifically
designed to allow GC. These languages place restrictions on the behavior
of pointers, do not allow integers to be used as pointers (or don't trace
them), and have certain structures in memory that facilitate GC. These
structures and restrictions can be used to implement your alternate GC in
the same way that they were used in the standard.

C++ does not have these restrictions, nor does it have the necessary
structures to do GC with the same ease that Eiffel and such do. Therefore
if you intend to use GC _of_any_kind_ in your system, it is better that
you start with a language that was designed with that ability in mind.

As to my competency, I had to retrofit C++ with GC when I was working on
a compiler for Oberon-2 (a fast GCed procedural/oop language) to Ansi C++
that would generate human-editable code with no macros. In order to do
the GC (and several other things) I had to make the same restrictions on
C++ behavior that Oberon has. Unfortunately, since these restrictions
couldn't be enforced, the C++ code was slower than the corresponding
Oberon code (although it was at least as fast as code made in the normal
C++ style). Your mileage may vary, but mine usually hasn't.

: *------------------------------------------------------------------------------*
: Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few
: Internet:  jcm@hgc.edu   minutes to 5:00.

Brian Hawley
bhawley@orion.it.luc.edu and math.luc.edu

In article <3da1nd$fss@gateway.wiltel.com> igor_chudov@wiltel.com (Igor Chudov) writes:
>James McKim (jcm@hgc.edu) wrote in comp.lang.c++:
>: In article <3ckb8g$841@gateway.wiltel.com> igor_chudov@wiltel.com (Igor Chudov) writes:
>: >How are you going to work with realtime with a system with garbage collection
>: >(namely, Eiffel)? You don't have much control over GC to ensure that your
>: >system will be responsive enough.
>
>: Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
>: GC. Not sure about the other vendors. If such fine-tuning is still
>: insufficient then you can always turn automatic GC off, write your
>: own collector and be no worse off than in any language that did not support
>: automatic GC.
>
>As for Eiffel, I worked with SiG Eiffel compiler. For 'fine tuning' it
>provides only the way to enable and disable garbage collection and also to
>set some limits and criteria when to start the garbage collection.
>
>AFAIK, both Tower and ISE provide approximately the same kind of fine
>tuning. I'll appreciate if you post your corrections in the news if I am
>wrong.

Another poster also asked for more info. As I sit here looking at both
Tower's and ISE's MEMORY classes, they appear to provide at least a bit
more capability than you ascribe to SiG. OTOH I have not had occasion to
use these facilities and so cannot speak with authority about them. Perhaps
we can get someone from each vendor to speak up?

>
>This kind of fine tuning along with non-incremental GC, being nice in
>general, does not provide enough flexibility for real-time applications.
>
>None of existing Eiffel vendors provides incremental garbage collector that
>can work in parallel with the execution (or stealing LITTLE pieces of
>processor time), although Tower informed that they have been working on this
>problem. This type of GC can enable the apps to be really (sorry for the
>clumsiness) real-time.

This is surprising as Meyer has always advocated incremental collection,
see OO Software Construction and Eiffel: The Language. In fact in the
latter he implies that ISE's collector _is_ incremental. We really need
someone from ISE to speak up here.

>
>To be able to use the latter type of GC, however, whole runtime system has to
>be modified along with the GC, so it is hardly possible to add realtime GC
>without changes in runtime. The argument that we can add our own realtime
>GC to existing runtime sounds too optimistic.

Well, I didn't say it would be _easy_ :-). But why would building
your own garbage collector be more difficult for an Eiffel system
than it would be for a C++ system?

>
>You are right that in general nothing prevents Eiffel to be able to work in
>RT.
>
>Best regards,
>----------------------------------------------------------------------------
>IMHO. Igor Chudov,      Resource Solutions Intl         office (918)588-2309
>Systems Engineer,       for WilTel.                     home   (918)585-5862
>                                          E-mail:     igor_chudov@wiltel.com
>                                          http://m-net.arbornet.org/~ichudov
>                                     1819 South Jackson #32-P Tulsa OK 74107
>
>                 f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.


Happy Holidays,
-- Jim
--

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few
Internet:  jcm@hgc.edu   minutes to 5:00.

In article <1994Dec21.151952.8902@merlin.hgc.edu> jcm@hgc.edu (James McKim) writes:

   >How are you going to work with realtime with a system with garbage collection
   >(namely, Eiffel)? You don't have much control over GC to ensure that your
   >system will be responsive enough.

   Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
   GC. Not sure about the other vendors. If such fine-tuning is still
   insufficient then you can always turn automatic GC off, write your
   own collector and be no worse off than in any language that did not support
   automatic GC.

This is _very_ interesting to me.  Could you (or someone else) explain
how this is done?  How does one write a collector?  Can you use
explicit calls to deallocate individual objects?

I work in a real time environment, and we've pretty much given up on
the idea of using a garbage-collected language for any of our
time-critical tasks.  If we could eliminate (I don't think "reduce"
would be enough) the risk of a GC kicking off at an inopportune time,
we might be able to consider higher-order languages.

Are there any papers, etc, that I could access?  Thanks much for any
help.
--
Kevin K. Lewis               | My opinions may be unreasonable
lewikk@aud.alcatel.com       | but such is the voice of inspiration

James McKim (jcm@hgc.edu) wrote in comp.lang.c++:
: In article <3ckb8g$841@gateway.wiltel.com> igor_chudov@wiltel.com (Igor Chudov) writes:
: >How are you going to work with realtime with a system with garbage collection
: >(namely, Eiffel)? You don't have much control over GC to ensure that your
: >system will be responsive enough.

: Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
: GC. Not sure about the other vendors. If such fine-tuning is still
: insufficient then you can always turn automatic GC off, write your
: own collector and be no worse off than in any language that did not support
: automatic GC.

As for Eiffel, I worked with SiG Eiffel compiler. For 'fine tuning' it
provides only the way to enable and disable garbage collection and also to
set some limits and criteria when to start the garbage collection.

AFAIK, both Tower and ISE provide approximately the same kind of fine
tuning. I'll appreciate if you post your corrections in the news if I am
wrong.

This kind of fine tuning along with non-incremental GC, being nice in
general, does not provide enough flexibility for real-time applications.

None of existing Eiffel vendors provides incremental garbage collector that
can work in parallel with the execution (or stealing LITTLE pieces of
processor time), although Tower informed that they have been working on this
problem. This type of GC can enable the apps to be really (sorry for the
clumsiness) real-time.

To be able to use the latter type of GC, however, whole runtime system has to
be modified along with the GC, so it is hardly possible to add realtime GC
without changes in runtime. The argument that we can add our own realtime
GC to existing runtime sounds too optimistic.

You are right that in general nothing prevents Eiffel to be able to work in
RT.

Best regards,
----------------------------------------------------------------------------
IMHO. Igor Chudov,      Resource Solutions Intl         office (918)588-2309
Systems Engineer,       for WilTel.                     home   (918)585-5862
                                          E-mail:     igor_chudov@wiltel.com
                                          http://m-net.arbornet.org/~ichudov
                                     1819 South Jackson #32-P Tulsa OK 74107

                 f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

same here.  maybe it should be posted.

thanks

pat.brulotte@asix.com

wagnermi@Informatik.TU-Muenchen.DE (Michael Wagner) wrote:
>
>
> I missed the beginning of this thread.
> Could someone who saved Bjarne Stroustrups defense send a copy to me ?
>
> Thanks
>
>  Mike

In article <3cm0j0$5b3@news-2.csn.net> perez@oldcolo.com (Carlos Perez) writes:
|Let's see... $5,000 for the pentium, $300 for the OS, $40 to 50K/year for the
|programmer.... so broke can only afford a $99 compiler :-)

Nit:  Where do you shop for computers?  My local store has good pentiums
for < $2000, good 486 machines for < $1000.  That leaves you $4099 to
ship to whatever your favorite compiler team ;-)

In article <3ckb8g$841@gateway.wiltel.com> igor_chudov@wiltel.com (Igor Chudov) writes:
>David Siegel (dsiegel@panix.com) wrote in comp.lang.c++:
>: In <787227087snz@wslint.demon.co.uk> kevlin@wslint.demon.co.uk (Kevlin Henney) writes:
>
>: >We are developing a realtime system that must be portable across a number of
>: >platforms conforming to the standard POSIX spec (the standard binding is in
>: >C), the realtime POSIX spec/draft (the standard binding for which is in C),
>: >accessing BSD sockets (the standard API defined in C), allow low level
>: >access and run on systems that use standard UNIX linkers.
>
>: The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
>: the features you mention as essential.
>
>How are you going to work with realtime with a system with garbage collection
>(namely, Eiffel)? You don't have much control over GC to ensure that your
>system will be responsive enough.

Hmmm... Both Tower and ISE Eiffel vendors provide means for fine-tuning
GC. Not sure about the other vendors. If such fine-tuning is still
insufficient then you can always turn automatic GC off, write your
own collector and be no worse off than in any language that did not support
automatic GC.

>----------------------------------------------------------------------------
>IMHO. Igor Chudov,      Resource Solutions Intl         office (918)588-2309
>Systems Engineer,       for WilTel.                     home   (918)585-5862
>                                          E-mail:     igor_chudov@wiltel.com
>                                          http://m-net.arbornet.org/~ichudov
>                                     1819 South Jackson #32-P Tulsa OK 74107
>
>                 f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.


Hope this helps,
-- Jim
--

*------------------------------------------------------------------------------*
Jim McKim  (203)-548-2458     In exactly 3.2 seconds it will be a few
Internet:  jcm@hgc.edu   minutes to 5:00.

< From: thant@disney.com (Thant Tessman)
<
< No, C++ is hindered by C.  The advantage that C++ has in the market place
< is that people who know C or who have a stable of C programmers are fooled
< into thinking that they can take advantage of more advanced computer
< programming concepts with less effort than it would take to learn an
< entirely new programming language.  Maybe Stroustrup thinks this is the
< case, but it is definitely not my experience.  And even Stroustrup warns
< that it is a mistake to consider C++ "simply a more complicated C".

Interestingly enough, my experience with various groups has been the
opposite from yours. Perhaps it's all in how you approach the learning of
the more advanced computer programming concepts that C++ supports.

     Tony Hansen
       hansen@pegasus.att.com, tony@attmail.com
    att!pegasus!hansen, attmail!tony

nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

>If you can't think of a least one area where a language is better
>than your prefered language then you probably aren't competent
>to comment on it.


This statement should be named: "Nebbe's Rule" and should be made a
rule of net ettiquette.


--
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 <D0t6DL.7KD@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>A more useful question is probably

> "In _what_ contexts is it best to use C++,
> or some other language?"

Granted.

>And for me the answer is "all of them" because if I cant
>use C++ I'm unlikely to be (commercially) interested in the job.

And for me: "Virtually none", since the cost of developing infrastructure
in C++ that's unneeded by more thoroughly OO languages is prohibitive.

-dms

In article <D0qBoC.6Bx@inter.NL.net> Miguel Carrasquer, mcv@inter.NL.net
writes:
>"... making a C++ implementation 100% type-safe -- would require either
>linker support or a mechanism (an environment) allowing the compiler
>access to information from separate compilations."
>

...and this of course is where Ada fits in! :-)

Dale
-------------------------------------------------------------
Dale Stanbrough, RMIT, Melbourne, Australia, dale@rmit.edu.au
GNU Ada 94 (GNAT) => the best $0 you'll ever spend.
Available for DOS, Linux, OS/2, Sun Sparc, Sun Solaris, ...
Coming to a GNU supported platform near you soon...

In article <D0rAy3.Lu6@lcpd2.SanDiegoCA.NCR.COM>, Peter Lohmann (peter.lohmann@sandiegoca.attgis.com) writes:
>[nice defence/commentary deleted]
>
>You should consider where most people get their 'information' about
>C++ and put this into perspective.  If you were to walk into a popular
>bookstore and look at the material on C++, you would think that
>C++ was either:
>
>   1.  invented by Microsoft to do Windows programming, or
>   2.  an academic diversion for research scientists at Bell Labs
>
>In fact, I found that from the criticisms of C++ on the net and elsewhere,
>most are out of ignorance.
>And, when these C++ programer want-to-be's look turn to net news
>for answers, they see discussion on subtle nuances of advanced
>C++ design issues.  They get flamed for asking simple questions, although
>in some cases deserving it.
>If C++ were not successful, people would not use it, there would not
>be hundreds of postings weekly on net news about it, and prominent
>compiler vendors wouldn't work so hard to pump out implementations
>of new language extensions.
>

I tend to disagree on the book portion.  I have found souce for
serial port programming, oop in realtime, and many others that
don't relate to MS-Windows or AT&T.  True, though the majority are
for windows..... But than again I would have to say the majority
of C++ programmers are PC realted people so it is the market
speaking........

My complaint is why must every C++ book start by telling me how to
move from C to C++.  I would much rather forget C and program in
C++. It is a lot easier to program in OOP rather that try to write
a C program in C++.  To be successful that is the message that
needs to get out.  Learn OOP, than lean C++, smalltalk or whatever
you prefer.  Inheritance and the rest make a lot more sense if you
learn how to program the pond scenerio in OOP first before getting
bogged down in language constructs.  It is one of the beauties of
the system as a whole.

Also, remember the newbie posting today may have been you a few
years ago.

ecs@ecsd.win.net

In article <1994Dec15.181002.1941@rcmcon.com> rmartin@rcmcon.com (Robert Martin) writes:
>From: rmartin@rcmcon.com (Robert Martin)
>Subject: Re: Widespread C++ Competency Gap?
>Date: Thu, 15 Dec 1994 18:10:02 GMT

>nebbe@lglsun.epfl.ch (Robb Nebbe) writes:

>>If you can't think of a least one area where a language is better
>>than your prefered language then you probably aren't competent
>>to comment on it.


>This statement should be named: "Nebbe's Rule" and should be made a
>rule of net ettiquette.


>--
>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++


I'll second this motion ;->

Bob

In article <3cj96p$mp4@panix.com> dsiegel@panix.com (David Siegel) writes:
>In <D0MrGr.1p6@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>
>> In that case you completely miss the point of C++.
>>Its _principle_ advantage is that it gains leverage off C.
>>That is why it is popular -- it preserves the large C code
>>base, programmer base, and it it permitted a portable
>>implementation to be written (CFront).
>
>It's principle distinction, anyway, and most of the reason the language's
>so much uglier than, say, Eiffel or Modula-3.  Advantage?  A matter of
>opinion, to be sure.

 Its my opinion this explains why C++ is popular, and thus
_available_.
>
>>Bjarne tried to design a language which provided an
>>upgrade path which would ensure it's popularity and which
>>would introduce programmers to modern concepts.
>
>It's clear that was the attempt.  The argument (at least, the sensible
>part of it), is about whether the compromises overshadow the benefits.

 But the argument is pointless. In a given commercial
situation someone has to make a commercial decision: whether
to use C++ or some other language. That choice is quite
rightly affected by a lot of things other than the "quality"
of the language.

 For example: Eiffel may well be a better language,
but I don't have a commercial quality compiler so it is,
at present, useless to me, except perhaps for experimentation.

 OTOH I have 4 excellent C++ compilers. (Not counting
GNU, which would make 5). And I have access to a lot of
useful software -- libraries, programs, public domain
and commercial code. Some of it is actually C code,
for example Funnel Web (literate programming tool).

 Often in the commercial world, it is just
necessary to write code to meet a commercial need.
There may not be any difficult design issues -- often
its just a simple matter of hack work.

 So your question is valid -- but only in
a given context. A more useful question is probably

 "In _what_ contexts is it best to use C++,
 or some other language?"

And for me the answer is "all of them" because if I cant
use C++ I'm unlikely to be (commercially) interested in the job.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <D0MrGr.1p6@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU writes:

[...]

>  In that case you completely miss the point of C++.
> Its _principle_ advantage is that it gains leverage off C.

[...]

No, C++ is hindered by C.  The advantage that C++ has in the market
place is that people who know C or who have a stable of C programmers
are fooled into thinking that they can take advantage of more advanced
computer programming concepts with less effort than it would take to
learn an entirely new programming language.  Maybe Stroustrup thinks
this is the case, but it is definitely not my experience.  And even
Stroustrup warns that it is a mistake to consider C++ "simply a more
complicated C".

thant

In article <3cl1me$jd@panix.com>, dsiegel@panix.com (David Siegel) writes:
|> In <3ckb8g$841@gateway.wiltel.com> ichudov@wiltel.com (Igor Chudov) writes:
|> >How are you going to work with realtime with a system with garbage collection
|> >(namely, Eiffel)? You don't have much control over GC to ensure that your
|> >system will be responsive enough.
|>
|> Exactly the way you do in C++ -- by being careful about the objects you
|> create and free (leave scope, release, whatever).
|>
|> Given C++'s penchant for behind the scenes memory management, C++ is one
|> of the worst languages to use, if this is your yardstick.
|>
|> -dms

Actually, there are GC schemes that interpolate structure creation
with space reclamation so that even over relatively small time
intervals (e.g. much less than a millisecond, perhaps a microsecond),
the fraction of time spent in GC can be bounded.

There is a rather extensive literature on GC now doing back for
thirty years.  Maybe someone from the lisp community could compile
a bibliography and post it here...

In article <3ckb8g$841@gateway.wiltel.com> ichudov@wiltel.com (Igor Chudov) writes:

| : The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
| : the features you mention as essential.
|
| How are you going to work with realtime with a system with garbage collection
| (namely, Eiffel)? You don't have much control over GC to ensure that your
| system will be responsive enough.

There are, of course, real time GC's, and in fact we have one running in
the lab working with our Eiffel compiler. Depending on your realtime
requirements (everyone has a different definition of "realtime"... :-)),
it may indeed be possible to use a GC'd language like Eiffel for your
realtime system.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
TowerEiffel: Have your cake and eat it too.

Steve Tynor  Internet: Steve.Tynor@atlanta.twr.com
Tower Technology UUCP:     twratl!Steve.Tynor
   WWW:      http://www.cm.cf.ac.uk/Tower/

In article <D0MrGr.1p6@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU (John Max Skaller) writes:
|> In article <3cdnj2$quf@panix.com> dsiegel@panix.com (David Siegel) writes:
|> >In <D0IysF.1Jz@research.att.com> bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
|> >
|> >Well, I believe most of the "rubbish" posted about C++, but I'd like to
|> >hear the other side of the story.  I'd be surprised to find it convincing,
|> >though, since some of the frequently cited C++ "advantages" are unconvincing,
|> >at best (compatibility with C and ancient linkers come immediately to
|> >mind).
|>
|>  In that case you completely miss the point of C++.
|> Its _principle_ advantage is that it gains leverage off C.
|> That is why it is popular -- it preserves the large C code
|> base, programmer base, and it it permitted a portable
|> implementation to be written (CFront).
|>

There are other IMHO better languages which have the same benefits.
These benefits do not imply that the language has to be a superset
of C.

|>  The issue here is not whether C++ is the best
|> language which one could design, but to design one that
|> was worth the effort working on -- that is, one which
|> would have widespread use.

To design it was worthwhile.
Not so sure about the using it bit.

|>
|> >Valid point, but I think you're underplaying the problems stemming from
|> >the interactions of novices and needlessly complicated languages.
|>
|>  And you are ignoring the commercial realities of the
|> world. Bjarne tried to design a language which provided an
|> upgrade path which would ensure it's popularity and which
|> would introduce programmers to modern concepts.

Unfortunately commercial success is always an argument which
wins over any valid engineering argument.

|>
|>  And succeeded. Of course there is a compromise
|> in a language which supports both machine level programming
|> and OO!

Of course there is always compromise.

I just think that some of the compromises which were taken,
in particular source level compatability with 'C', and the
'C' compilation model where not the best ones which could have
been made.

--
Mike Chapman

In article <D0r6Gs.452@research.att.com> ark@research.att.com (Andrew Koenig) writes:
> In article <3cj96p$mp4@panix.com> dsiegel@panix.com (David Siegel) writes:
> > It's principle distinction, anyway, and most of the reason the language's
> > so much uglier than, say, Eiffel or Modula-3.  Advantage?  A matter of
> > opinion, to be sure.
>
> As is beauty.  When one knows something well enough, beauty
> and ugliness tend to give way to familiarity.

So? I am familiar with many things in both categories, which
doesn't mean I still don't prefer the beautiful things (speaking
metaphorically, let's say Modula-3), to the ugly things (I'll
leave this one open).

steve

--
- - - - - - - - - - - - - - - - - - - - - - - - - -
Dr. Steve Freeman, Research Scientist, Rank Xerox France.

Surface:  Rank Xerox Research Centre,
          6, chemin de Maupertuis, 38240 Meylan, France.
Internet: steve.freeman@xerox.fr
Phone:    +33 76 61 50 21
Fax:      +33 76 61 50 99


but wotthehel wotthehel
toujours gai
  -- mehitabel the cat

In article <3cna31INNaud@ford.is.wdi.disney.com> thant@disney.com (Thant Tessman) writes:
>
>In article <D0MrGr.1p6@ucc.su.OZ.AU>, maxtal@physics.su.OZ.AU writes:
>
>[...]
>
>>  In that case you completely miss the point of C++.
>> Its _principle_ advantage is that it gains leverage off C.
>
>[...]
>
>No, C++ is hindered by C.

 Of course! The two claims are not inconsistent -- on
the contrary they are tightly coupled!

>The advantage that C++ has in the market
>place is that people who know C or who have a stable of C programmers
>are fooled into thinking that they can take advantage of more advanced
>computer programming concepts with less effort than it would take to
>learn an entirely new programming language.

 They can.

>Maybe Stroustrup thinks
>this is the case, but it is definitely not my experience.  And even
>Stroustrup warns that it is a mistake to consider C++ "simply a more
>complicated C".

 The reason they can is not that it easier to learn C++,
but that it is easier to learn C++ than learn language X AND
convert all your code to X, AND convince management to convert
all their systems to X, AND find a compiler for X, AND find
support for X, AND find a good specification of X AND find
good books on X AND find peers who understand X ....

 Converting C to C++ is usually easy. Sometimes,
as easy as falling off a greasy compiler switch and writing

 extern "C" { .. :-}
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

I missed the beginning of this thread.
Could someone who saved Bjarne Stroustrups defense send a copy to me ?

Thanks

 Mike

One thing to consider is that C++ is surely catching some of the
backlash from those who are the victums of OO hype.  Despite Brooks'
admonition that "there is no silver bullet," too many articles have
been written that describe how OO will save the world.  Since C++
is an OOL, it has the responsibility to save the world.  When people
discover that it doesn't make the task of programming something that
any idiot can do flawlessly, people are disappointed.  Being people,
their disappointment may turn to vindictiveness.  Their spite should
be turned agains those who made the inflated promises rather than
the language, but if they were the sort to engage in that sort
of reasoning, they would not have been taken in by the hype in the
first place.

Other examples of this process include COBOL, AI and 4GLs.  COBOL was
to save the world because it would let managers understand what their
programmers were up to and all managers understood that the problem
with getting working code delivered on time was that programmers were
not being effectively managed.  More recently, AI in general, and
expert systems in particular, was going to save the world because
declarative programming eliminates the need to say *how* to solve
a problem; one only need state the problem and the expert system
will produce the solution.  (Or throw some data sets at a neural net
and let it learn the solution from them.)  Next, 4GLs promised to
save the world: simple example programs showed how fast and easy
this approach is when compared to writing the whole example program
from scratch but these tools suffer considerably when given real
industrial-strength problems to solve.

These paneceas all overlook the fact that programming is and I suspect
will remain hard work that requires creative, intelligent and well-
trained practitioners to produce reliable results.  "There is no silver
bullet" but there are tools that help.  C++ is one very useful tool as
are Prolog, LISP and application generators.  All of these must be used
for the correct reasons at the correct time to be effective.

For myself, both my productivity and quality doubled while constructing
my first large C++ program when compared to my previous experience with
the C lanaguage.  Since this was my first production C++ program, I
did this while learning much of the language.  The code proved to
be quite extendable; adding features to the program was very easy.
In short, I got what I wanted from the language.  Perhaps my success
was due to the fact that I had already had several years experience
with OO before moving to C++.  Data abstraction was by no means a new
concept.

Another thing to consider is our educational system.  Almost every
programmer I've every worked with or spoken to on this subject
defines programming as coding.  Analysis and design (and test)
are steps that are considered to be mere formalities and to be
eliminated whenever possible.  I beleive that the reason for this
attitude is that from the start, our educators evaluate programming
students by running the code and comparing the results with expected
program output.  Design documentation is not required and would not be
looked at if the student created it.  By the time that a programmer
enters the professional ranks, the programmer has 4 years of
experience in doing it wrong.  When presented with programming
techniques that require analysis and design, the typical programmer
is at a loss and turns this feeling against the tool.


Eric Peabody

In <D0MrGr.1p6@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:

>In article <3cdnj2$quf@panix.com> dsiegel@panix.com (David Siegel) writes:
>>In <D0IysF.1Jz@research.att.com> bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>>
>>Well, I believe most of the "rubbish" posted about C++, but I'd like to
>>hear the other side of the story.  I'd be surprised to find it convincing,
>>though, since some of the frequently cited C++ "advantages" are unconvincing,
>>at best (compatibility with C and ancient linkers come immediately to
>>mind).

> In that case you completely miss the point of C++.
>Its _principle_ advantage is that it gains leverage off C.
>That is why it is popular -- it preserves the large C code
>base, programmer base, and it it permitted a portable
>implementation to be written (CFront).

It's principle distinction, anyway, and most of the reason the language's
so much uglier than, say, Eiffel or Modula-3.  Advantage?  A matter of
opinion, to be sure.

>Bjarne tried to design a language which provided an
>upgrade path which would ensure it's popularity and which
>would introduce programmers to modern concepts.

It's clear that was the attempt.  The argument (at least, the sensible
part of it), is about whether the compromises overshadow the benefits.

-dms

In <787227087snz@wslint.demon.co.uk> kevlin@wslint.demon.co.uk (Kevlin Henney) writes:

>We are developing a realtime system that must be portable across a number of
>platforms conforming to the standard POSIX spec (the standard binding is in
>C), the realtime POSIX spec/draft (the standard binding for which is in C),
>accessing BSD sockets (the standard API defined in C), allow low level
>access and run on systems that use standard UNIX linkers.

The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
the features you mention as essential.

I've personally built real-time systems in Smalltalk, portable across
most major Unix platforms.

C binding and low-level access are _not_ sufficient reasons to use C++.

-dms

In article <D0IysF.1Jz@research.att.com> bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:

|Below, I present abbreviated versions of common unfair attacks on C++
|in quotes and then comment on them. [ ... ]

|``C++ programmers are idiots''

IMHO, I find people who are gifted with a spark of silliness or
lunacy quite a creative type of programmers if I may say so. This
doesn't just apply to C++ programmers. I consider it a pro if
someone happens to be `slightly idiot.'

kind regards,

Jos aka jos@and.nl

ps. No smiley here, I'm serious about this ...

In article <D0IysF.1Jz@research.att.com>, bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>
> This message is a response to a lot of outrageous inaccuracies, innuendo,
> rudeness, and flat-out false statements about C++ and its user community.
 ...
> I consider a large portion of the bashing of C++ and the C++ users
> unwarranted, ill-informed, self-serving, and intellectually dishonest.
> Sadly, one must expected some mud to be thrown at anything successful,
> but I think some posters have gone too far in their attacks on C++.

I've thought that for a long time, Bjarne, because they are abusing this
newsgroup (IMO) if for no other reason.

Let them spend as much ASCII bashing CLOS on a CLOS newsgroup, or Ada on
an Ada newsgroup, or any other language on its own ground.  The result
will be a flurry of angry mail as the newsgroup is buried under their
postings, and enough of that mail will ring with outrage at their ignorance
that they might just think about it.

But C++ is large enough, and this newsgroup is busy enough, to survive
both their ignorant postings and the continuous flurry of FAQs from
newbies, so they get away with posting articles which ought not be posted.
--
 (This man's opinions are his own.)
 From mole-end    Mark Terribile
 mat@mole-end.matawan.nj.us, Somewhere in Matawan, NJ
 (Training and consulting in C, C++, UNIX, etc.)

In article <3cj96p$mp4@panix.com> dsiegel@panix.com (David Siegel) writes:

> > In that case you completely miss the point of C++.
> >Its _principle_ advantage is that it gains leverage off C.
> >That is why it is popular -- it preserves the large C code
> >base, programmer base, and it it permitted a portable
> >implementation to be written (CFront).

> It's principle distinction, anyway, and most of the reason the language's
> so much uglier than, say, Eiffel or Modula-3.  Advantage?  A matter of
> opinion, to be sure.

As is beauty.  When one knows something well enough, beauty
and ugliness tend to give way to familiarity.
--
    --Andrew Koenig
      ark@research.att.com

David Siegel (dsiegel@panix.com) wrote in comp.lang.c++:
: In <787227087snz@wslint.demon.co.uk> kevlin@wslint.demon.co.uk (Kevlin Henney) writes:

: >We are developing a realtime system that must be portable across a number of
: >platforms conforming to the standard POSIX spec (the standard binding is in
: >C), the realtime POSIX spec/draft (the standard binding for which is in C),
: >accessing BSD sockets (the standard API defined in C), allow low level
: >access and run on systems that use standard UNIX linkers.

: The other staticly typed OO languages (Eiffel, Modula-3, Sather) support all
: the features you mention as essential.

How are you going to work with realtime with a system with garbage collection
(namely, Eiffel)? You don't have much control over GC to ensure that your
system will be responsive enough.
----------------------------------------------------------------------------
IMHO. Igor Chudov,      Resource Solutions Intl         office (918)588-2309
Systems Engineer,       for WilTel.                     home   (918)585-5862
                                          E-mail:     igor_chudov@wiltel.com
                                          http://m-net.arbornet.org/~ichudov
                                     1819 South Jackson #32-P Tulsa OK 74107

                 f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng.

In <3ckb8g$841@gateway.wiltel.com> ichudov@wiltel.com (Igor Chudov) writes:
>How are you going to work with realtime with a system with garbage collection
>(namely, Eiffel)? You don't have much control over GC to ensure that your
>system will be responsive enough.

Exactly the way you do in C++ -- by being careful about the objects you
create and free (leave scope, release, whatever).

Given C++'s penchant for behind the scenes memory management, C++ is one
of the worst languages to use, if this is your yardstick.

-dms

[nice defence/commentary deleted]

You should consider where most people get their 'information' about
C++ and put this into perspective.  If you were to walk into a popular
bookstore and look at the material on C++, you would think that
C++ was either:

   1.  invented by Microsoft to do Windows programming, or
   2.  an academic diversion for research scientists at Bell Labs

In fact, I found that from the criticisms of C++ on the net and elsewhere,
most are out of ignorance.
And, when these C++ programer want-to-be's look turn to net news
for answers, they see discussion on subtle nuances of advanced
C++ design issues.  They get flamed for asking simple questions, although
in some cases deserving it.
If C++ were not successful, people would not use it, there would not
be hundreds of postings weekly on net news about it, and prominent
compiler vendors wouldn't work so hard to pump out implementations
of new language extensions.

    -- Peter
       peter.lohmann@sandiegoca.attgis.com
//
//   I speak only for myself.
//

In article <1994Dec12.165153@di.epfl.ch> Robb.Nebbe@di.epfl.ch (Robb Nebbe) writes:
>In article <787227087snz@wslint.demon.co.uk>, kevlin@wslint.demon.co.uk (Kevlin Henney) writes:
>|> In this case there is no doubt that C compatibility is important; C++'s
>|> high availability is also more than a little persuasive. For our purposes
>|> Ada, Eiffel, Smalltalk and co are not even on the starting blocks.
>
>I don't know about Eiffel and Smalltalk but Ada 83 works fairly well
>for this kind of a project and the new revision of Ada works even
>better.

  Where can I get an Ada compiler & debugger for Windows 3.1 or Windows NT 3.5
  for say ... $300 range ?

--
>>> Opinions presented above are solely of my own, not those of my employer <<<
Martin Brunecky           martin@xvt.com    (303)443-5130 ext 229 or 443-4223

In article <3cj96p$mp4@panix.com>, dsiegel@panix.com says...
>
>>Bjarne tried to design a language which provided an
>>upgrade path which would ensure it's popularity and which
>>would introduce programmers to modern concepts.
>
>It's clear that was the attempt.  The argument (at least, the sensible
>part of it), is about whether the compromises overshadow the benefits.
>

Obviously they do. That's why nobody uses it.
 -- Pete

Martin Brunecky (martin@xvt.com) wrote:
:   Where can I get an Ada compiler & debugger for Windows 3.1 or Windows NT 3.5
:   for say ... $300 range ?

Let's see... $5,000 for the pentium, $300 for the OS, $40 to 50K/year for the
programmer.... so broke can only afford a $99 compiler :-)

Seriously, I can relate to the issue of affordability of Ada compilers
which is why I use GNAT (which is free).  Comes without a debugger but
Ada programmers generally don't need debuggers <grin>.

I read that Alsys has a Windows Ada system (win bindings and all)
called ActivAda (sp?) for a list price of $999 and $295 for students.
I don't have the article in front of me, but check out the Dec. 12 issue
of PC Week.  Appears targeted to the serious Windows developer on a
budget who also wants an upgrade path to Ada 95.

--
-- Carlos Perez                               "My other car is Ada"
-- perez@oldcolo.com
-- team Ada (Ada95:  object-oriented, multi-threaded, totally-cool)

[Martin Brunecky]

|   Where can I get an Ada compiler & debugger for Windows 3.1 or Windows
|   NT 3.5 for say ... $300 range?

would you be willing _not_ to have to pay for it?  check out

 cs.nyu.edu:/pub/gnat

and look for gnat-2.00-dos-bin-disk1.zip, gnat-2.00-dos-bin-disk2.zip, and
gnat-2.00-i586-ibm-winnt3.5-bin.tar.gz.

if you really want to pay for it, I'm sure they won't be unhappy with that.

#<Erik>
--
The check is in the mail.  This won't hurt.  You'll find it on the Web.

David Siegel (dsiegel@panix.com) wrote:

: I've personally built real-time systems in Smalltalk, portable across
: most major Unix platforms.

That can hardly be true since UNIX as such is not a real-time operating
system. Are you confussing fast with real-time ?

--- peter

If you can't think of a least one area where a language is better
than your prefered language then you probably aren't competent
to comment on it.

Robb Nebbe

Bjarne Stroustrup <9758-26353> 0112760 (bs@research.att.com) wrote:

: This message is a response to a lot of outrageous inaccuracies, innuendo,
: rudeness, and flat-out false statements about C++ and its user community.
: The most dignified response would be a solid technical paper documenting
: the beauty and power of C++. However, people who believe even part of
: the rubbish posted about C++ will be unlikely to invest the time to get
: hold of such a paper and read it. In fact, the stated purpose of some
: of the worst postings has been to warn people against gaining an under-
: standing of C++. Also, there is no shortage of material describing C++
: and its uses. Consequently, I chose to respond directly.

[ ... ]

Let me put my 0.02$.

I admit that from time to time, I *disregard* some technologies ( e.g.
language or OS ). I know that this is not open-minded and regressive,
but what can I say, I guess it's human. BTW, I don't think something
being human means it is excusable.

This said, it seems that when people don't like a technology, they try to
rationalize their feeling. Some succeed, providing good argument, and
many don't and resort to fallacies like the ones the C++ language is
faced with in your message.

Now, if there are so many people that *disregard* C++, and if most of
their arguments are simply dumb, this is not sufficient to make them
*friends* of the C++'er class. We may postulate ( sorry for this 20$
word ) that there must be some deeper reasons that one don't want to
admit.

Popularity, of course, is part of the problem as you mention it.
A language becoming popular means for practitioners of some other
language, that they will get less job, find less reusable components
and poorer tools, etc. This is relative of course, of what they had
expected of the future before. This is a very bad news for them.

Also, for people that want to stay up-front of new software
breakthrough, there is a big chance that the *real stuff* will be
pioneered in the more popular language. Another bad news.

But why then do these people simply don't change their mind and adopt
the new language ?

Well, it is occurring right now. But this is painful. It requires efforts.
So we are screeming.

The fact is that here many people think C++ ask too much for what they
will be rewarded with. The language is simply too complex to use for
their needs. They don't want to bother with very low-level implementation
details, or very high level concepts for efficiency purpose which can
be pass-by in their favorite language. They are
amateur user and don't want to look all the time in their reference manual
to find the good syntax and semantic of a particular construct.

BTW, this is not a critique. It is just the statement that C++ is not
primarily targetted at occasional users. IMHO, C++ must go forward
and not change it's mind for that matter.

Moreover, as Bjarne said, it is not impossible to think of set of
libraries together with a framework and a good book to use a sort of
Easy C++. Not quite to remember, simpler semantic, etc.

I apology if I offended someone with those words.

********************************************************

BTW, I never had the chance to tell you ( Bjarne ) all my respect,
for your work, for your insight, and for the advancement in language
design you made. Thanks.

Frederic Guerin

Bjarne Stroustrup <9758-26353> 0112760 (bs@research.att.com) wrote:

: This message is a response to a lot of outrageous inaccuracies, innuendo,
: rudeness, and flat-out false statements about C++ and its user community.
: The most dignified response would be a solid technical paper documenting
: the beauty and power of C++. However, people who believe even part of
: the rubbish posted about C++ will be unlikely to invest the time to get
: hold of such a paper and read it. In fact, the stated purpose of some
: of the worst postings has been to warn people against gaining an under-
: standing of C++. Also, there is no shortage of material describing C++
: and its uses. Consequently, I chose to respond directly.

[ ... ]

Let me put my 0.02$.

I admit that from time to time, I *disregard* some technologies ( e.g.
language or OS ). I know that this is not open-minded and regressive,
but what can I say, I guess it's human. BTW, I don't think something
being human means it is excusable.

This said, it seems that when people don't like a technology, they try to
rationalize their feeling. Some succeed, providing good argument, and
many don't and resort to fallacies like the ones the C++ language is
faced with in your message.

Now, if there are so many people that *disregard* C++, and if most of
their arguments are simply dumb, this is not sufficient to make them
*friends* of the C++'er class. We may postulate ( sorry for this 20$
word ) that there must be some deeper reasons that one don't want to
admit.

Popularity, of course, is part of the problem as you mention it.
A language becoming popular means for practitioners of some other
language, that they will get less job, find less reusable components
and poorer tools, etc. This is relative of course, of what they had
expected of the future before. This is a very bad news for them.

Also, for people that want to stay up-front of new software
breakthrough, there is a big chance that the *real stuff* will be
pioneered in the more popular language. Another bad news.

But why then do these people simply don't change their mind and adopt
the new language ?

Well, it is occurring right now. But this is painful. It requires efforts.
So we are screeming.

The fact is that here many people think C++ ask too much for what they
we will be rewarded with. The language is simply too complex to use for
their needs. They don't want to bother with very low-level implementation
details, or very high level concepts for efficiency purpose which can
be pass-by in their favorite language. They are
amateur user and don't want to look all the time in their reference manual
to find the good syntax and semantic of a particular construct.

BTW, this is not a critique. It is just the statement that C++ is not
primarily targetted at occasional users. IMHO, C++ must go forward
and not change it's mind for that matter.

Moreover, as Bjarne said, it is not impossible to think of set of
libraries together with a framework and a good book to use a sort of
Easy C++. Not quite to remember, simpler semantic, etc.

I apology if I offended someone with those words.

********************************************************

BTW, I never had the chance to tell you ( Bjarne ) all my respect,
for your work, for your insight, and for the advancement in language
design you made. Thanks.

Frederic Guerin

In <D0IysF.1Jz@research.att.com> bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>The most dignified response would be a solid technical paper documenting
>the beauty and power of C++. However, people who believe even part of
>the rubbish posted about C++ will be unlikely to invest the time to get
>hold of such a paper and read it.

Well, I believe most of the "rubbish" posted about C++, but I'd like to
hear the other side of the story.  I'd be surprised to find it convincing,
though, since some of the frequently cited C++ "advantages" are unconvincing,
at best (compatibility with C and ancient linkers come immediately to
mind).

Nonetheless, I _will_ read such a paper, in the hopes of finding some
"beauty" I somehow missed.

>Personally, I have found many stimulating ideas in Ada, Algol68,
>CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
>written in those languages.

We agree on this.

>but I have never found learning a new language
>unrewarding.

I have (there are some _nasty_ 4GLs out there -- don't think I learned
anything from RPG, either), but it's usually interesting, especially
as you head away from the mainstream toward active research.

>Below, I present abbreviated versions of common unfair attacks on C++
>in quotes and then comment on them. Naturally, I try to make my comments
>helpful to people suffering from the root causes of those of the attacks
>that have a basis in reality rather than being just manifestations of
>commercial or intellectual rivalry.

> The much touted problems with readability are again vastly overstated.

My biggest complaint on this topic:  automatic type conversion.  I _really_,
_really_ hate compilers doing obscure things behind my back.  The new
"explicit" keyword helps, but, of course, the default's wrong.

Why not make "explicit" the default, and require conforming compilers to
support a "default is implicit" switch?  That should prevent breaking
the existing codebase.

> Proponents of languages that still have relatively minute - and
> therefore relatively close-knit and well-informed user communities
> - are making the mistake I made: seeing the evident success and
> enthusiasm of their fellow ``cult members'' as a direct consequence
> of qualities of their favorite language. They are wrong; if - against
> all odds - their language should escape into the mainstream the
> vastly enlarged user community will get its share of the problems
> and failures.

Valid point, but I think you're underplaying the problems stemming from
the interactions of novices and needlessly complicated languages.

-dms

In article <3cdnj2$quf@panix.com> dsiegel@panix.com (David Siegel) writes:
>In <D0IysF.1Jz@research.att.com> bs@research.att.com (Bjarne Stroustrup <9758-26353> 0112760) writes:
>
>Well, I believe most of the "rubbish" posted about C++, but I'd like to
>hear the other side of the story.  I'd be surprised to find it convincing,
>though, since some of the frequently cited C++ "advantages" are unconvincing,
>at best (compatibility with C and ancient linkers come immediately to
>mind).

 In that case you completely miss the point of C++.
Its _principle_ advantage is that it gains leverage off C.
That is why it is popular -- it preserves the large C code
base, programmer base, and it it permitted a portable
implementation to be written (CFront).

 The issue here is not whether C++ is the best
language which one could design, but to design one that
was worth the effort working on -- that is, one which
would have widespread use.

>Valid point, but I think you're underplaying the problems stemming from
>the interactions of novices and needlessly complicated languages.

 And you are ignoring the commercial realities of the
world. Bjarne tried to design a language which provided an
upgrade path which would ensure it's popularity and which
would introduce programmers to modern concepts.

 And succeeded. Of course there is a compromise
in a language which supports both machine level programming
and OO!

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

Bjarne Stroustrup <9758-26353> 0112760 (bs@research.att.com)
wrote:

}This message is a response to a lot of outrageous inaccuracies,
}innuendo, rudeness, and flat-out false statements about C++
}and its user community.

I just want to add a voice that says "Dr. Stroustrup:
perservere!"  I am very C++-partisan today, but would give it up
in a flash for a good OO language that was C-based and *didn't*
have a preprocessor!  :-)  I *think* (having also used Smalltalk
& Ada, studied Eiffel) that C++ lends itself well to most OO
design and implementation, yet wish for compilation, debugging
and analysis tools that other languages (e.g., Ada and Eiffel)
seem to lend themselves to much better (they don't have
a preprocessor!)  My call to action would be to ignore the
nay-sayers and move ahead with the future of the language.  Make
it easier to use, or at least easier for language vendors to
provide better tools, as I mentioned above.  (In all sincerity,
please find some route to follow at the end of which we have a
C++-like language without a preprocessor.  :-)  I look forward to
hearing Dr. Stroustrup speak in February.

Curt Nichols
Parsons Technology, Inc. /standard disclaimer/

--
Curt Nichols                 /  Circle, square, triangle.
Product Research Group      /   Think about it.
Parsons Technology, Inc.   /       - O sensei
74010.450@compuserve.com  [opinions expressed are mine alone]

In article <3cdnj2$quf@panix.com> dsiegel@panix.com "David Siegel" writes:

>Well, I believe most of the "rubbish" posted about C++, but I'd like to
>hear the other side of the story.  I'd be surprised to find it convincing,
>though, since some of the frequently cited C++ "advantages" are unconvincing,
>at best (compatibility with C and ancient linkers come immediately to
>mind).

We are developing a realtime system that must be portable across a number of
platforms conforming to the standard POSIX spec (the standard binding is in
C), the realtime POSIX spec/draft (the standard binding for which is in C),
accessing BSD sockets (the standard API defined in C), allow low level
access and run on systems that use standard UNIX linkers.

In this case there is no doubt that C compatibility is important; C++'s
high availability is also more than a little persuasive. For our purposes
Ada, Eiffel, Smalltalk and co are not even on the starting blocks.

+---------------------------+-------------------------------------------+
| Kevlin A P Henney         | Human vs Machine Intelligence:            |
| kevlin@wslint.demon.co.uk | Humans can wreck a nice beach more easily |
| Westinghouse Systems Ltd  |                                           |
+---------------------------+-------------------------------------------+

In article <D0MrGr.1p6@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> And succeeded. Of course there is a compromise
>in a language which supports both machine level programming
>and OO!

  Right. Just call it properly "Object Oriented Assembly".

  After all, "C" success was mainly to to the fact that it was
  (and still is) mainly a "Portable Assembly".

--
>>> Opinions presented above are solely of my own, not those of my employer <<<
Martin Brunecky           martin@xvt.com    (303)443-5130 ext 229 or 443-4223

In article <787227087snz@wslint.demon.co.uk>, kevlin@wslint.demon.co.uk (Kevlin Henney) writes:

|>
|> We are developing a realtime system that must be portable across a number of
|> platforms conforming to the standard POSIX spec (the standard binding is in
|> C), the realtime POSIX spec/draft (the standard binding for which is in C),
|> accessing BSD sockets (the standard API defined in C), allow low level
|> access and run on systems that use standard UNIX linkers.
|>

The students in our software engineering course are doing a project that
is something like this. The have the Ada POSIX interface, all the realtime
facilities of Ada, an interface to BDS sockets that is much cleaner
than the C interface (written by two students after a semester of Ada)
and low-level access.

Now unless they are really ambitious they won't need the realtime
facilities or the low-level access to finish the project but they are
there to fall back on. The project will be distributed acrossed two
different types of machines and I wouldn't expect any difficulty migrating
to another architecture.

|> In this case there is no doubt that C compatibility is important; C++'s
|> high availability is also more than a little persuasive. For our purposes
|> Ada, Eiffel, Smalltalk and co are not even on the starting blocks.

I don't know about Eiffel and Smalltalk but Ada 83 works fairly well
for this kind of a project and the new revision of Ada works even
better.

Maybe I should change the thread to "Widespread Ada Competency Gap" :-)

Robb Nebbe

This message is a response to a lot of outrageous inaccuracies, innuendo,
rudeness, and flat-out false statements about C++ and its user community.
The most dignified response would be a solid technical paper documenting
the beauty and power of C++. However, people who believe even part of
the rubbish posted about C++ will be unlikely to invest the time to get
hold of such a paper and read it. In fact, the stated purpose of some
of the worst postings has been to warn people against gaining an under-
standing of C++. Also, there is no shortage of material describing C++
and its uses. Consequently, I chose to respond directly.

I consider a large portion of the bashing of C++ and the C++ users
unwarranted, ill-informed, self-serving, and intellectually dishonest.
Sadly, one must expected some mud to be thrown at anything successful,
but I think some posters have gone too far in their attacks on C++.

Please note, that I am NOT claiming C++ is perfect, that I am NOT
saying that every critic of C++ is dishonest or ill-informed, that
I'm not suggesting people should stop discussing C++'s strengths and
weaknesses (where relevant), and that I am NOT telling you to stop
using your favorite programming language and use C++ instead.

I am asking people to clean up their act, to be honest and up-front
with their aims and motives, to refrain from unsupported derogatory
statements, to avoid ``have you stopped beating your wife'' style of
demagogy, and to get a minimum of acquaintance with C++ before
starting to give advice (positive or negative) about it.

If you - like most people - have not been engaging in disreputable
debating practices, please don't take offense from my words; they
are not aimed at you.

And do, please do, learn not only C++, but also other languages,
systems, and techniques that might be helpful to your work and
intellectual growth. A closed mind is a recipe for bigotry.



Personally, I have found many stimulating ideas in Ada, Algol68,
CLOS, Eiffel, ML, Modula-*, Smalltalk, Simula, etc. and in code
written in those languages. For most of the kind of work I do,
I prefer C++, but I have never found learning a new language
unrewarding. The thing to remember, though, is that a programming
language - any programming language - is a means to an end (the
building of systems), rather than an end in itself. Considering
how to build better systems and how various languages can serve
that end is a much better use of time than fighting language wars.

Please remember that a system can be ``better'' according to many
different criteria. The particular purpose of a system together
with the particular context of its development often have decisive
effects on the judgement of a system by its builders and - more
importantly - of its users.

Below, I present abbreviated versions of common unfair attacks on C++
in quotes and then comment on them. Naturally, I try to make my comments
helpful to people suffering from the root causes of those of the attacks
that have a basis in reality rather than being just manifestations of
commercial or intellectual rivalry.

``C++ sucks''

 If you think so, go use what you consider better. It may indeed
 be better than C++ for your purposes.

 C++ is a very useful language that is used successfully by MANY
 people in MANY application areas. I guess that is a large part of
 what bothers some. By being successful, C++ offends many who
 have strong notions of what else ought to be successful.

 The major cause of complaints is C++ undoubted success. As someone
 remarked:

  There are only two kinds of programming languages:
  those people always bitch about and those nobody uses.

 C++ isn't perfect. That is well known and acknowledged from the
 start. It is, however, a reasonably carefully thought-out language
 where the design is based part on acknowledged principles and part
 on solid experience and feedback from actual use. See my book
 ``The Design and Evolution of C++'' for an exposition of the aims
 of C++, the design process that led to the current language, the
 reasons for particular design decisions, etc.

 I wish I had an electronic equivalent to a little duck-horn,
 so that a rude BEEP was triggered by every unsupported derogative
 statement about C++. The noise would be deafening, though.
 An increasing number of people seem to relish displaying their
 ignorance and poor manners by snide remarks and gratuitous
 inaccuracies.

 At a recent conference, a speaker asked for a show of hands and
 found that twice as many people claimed to hate C++ as had ever
 written even a single small C++ program. The only word for such
 behavior is bigotry. In dealing with the current wave of C++ bashing,
 we should remember that bigotry is bred by ignorance and fear.

 It should also be remembered that if bigotry is not opposed but
 allowed to fester and sow distrust real harm results.

``C++ is too complex''

 C++ is much more complicated than, say, C and Pascal. However,
 MANY have succeeded in learning and applying C++. It has been
 demonstrated again and again that you don't need to be a genius
 to learn C++ in a reasonable time or to use C++ well. Further,
 it has been demonstrated that there are several distinct ways
 of reaching that level of competence.

 So, what about C++ is hard to learn, and why? Someone knowing C
 well can learn Pascal in a week - and vice versa. Becoming expert
 - that is, learning to avoid the more common pitfalls and using
 common idioms of the new language - is harder. It could even take
 a couple of months. The reason for the easy transition is that
 the languages are fundamentally similar. All that needs to be
 learned is a bit of syntax and a few simple ways of using the
 new syntax. Often, this can be learned from looking at the briefest
 description of the language and some code. The time and effort
 needed is a small fraction of was originally invested in becoming
 an effective programmer.

 This is where C++ is different. The key concepts of data abstraction
 and object-oriented programming are new to most people. Yes, these
 days most people have heard about OOP, but most have no practical
 experience with it and can no more do a object-oriented design than
 swim or bicycle based only on having read an article on the subject.

 You can use C++ effectively as a more strongly type checked C with
 a bit of simple data abstraction and library use thrown in after
 a week. However, becoming comfortable with OOP/OOD takes most people
 much longer. Estimates of six to eighteen month for becoming really
 proficient are often quoted, are in line with my personal experience
 with new C++ projects, and are in line with experience with other
 languages supporting OO.

 That demonstrates that the problems with notation and other language-
 technical details are minor. They are typically overcome within weeks.
 The real problems - as with any language - are conceptual: How to make
 a good design; not (just) how to express it.

 The much touted problems with readability are again vastly overstated.

 You can write obscure code in any language, and significant programs
 in a language you have only superficial knowledge about are always
 unreadable - especially if prejudice prevent you from actually
 trying to overcome notational barriers. A major part of readability
 is simply familiarity and experience.

 The idea that a manager or a complete novice in a language can come
 even close to comprehending a significant program because some inherent
 virtue of a particular language is nothing more than marketing hype
 and self-delusion. When people make such claims I wonder what else
 they might believe or be willing to claim.

 So why do reasonably clever and experienced people sometimes fail
 to learn C++ or fail to use it effectively after they have supposedly
 learned it? Usually because they have the wrong expectations. This
 actually has to be the case because I haven't found any strong
 correlation between what we could call smarts and becoming good
 C++ programmers. Some really clever programmers fail, and some
 supposedly mediocre ones succeed spectacularly.

 The ones that fail are usually the ones who believe they know
 everything already. Coming to C++ with a ``C is THE language''
 or ``OO means Smalltalk'' attitude is a recipe for failure.
 You can write in an (almost) pure C or (almost) pure Smalltalk
 style in C++, but that usually is not a good use of C++. Doing
 that involves a constant battle with the fundamental concepts
 of C++ and with the C++ type system. Against the fundamental
 structure of a language - any language - you can win Pyrrhic
 victories only.

 Another mistake is made by people who firmly believe that THEY
 don't need tutorial material. ``Real programmers read only code
 and reference manuals.'' That attitude is a recipe for disaster
 with C++. Undoubtedly, someone can learn OOP from reading code
 - after all Alan Kay (partly) learned OO by deciphering an 80
 page Simula program thinking it was Algol. However, most people
 are not in the same league as Alan.

 Experience shows that trying to learn OOP or C++ from the ARM
 (``The Annotated C++ Reference Manual'') is usually a BIG mistake.
 It is a nice book, I can recommend t (:-), but not as a tutorial.
 After all, most people wouldn't try learning a natural language
 exclusively from a grammar plus a dictionary. Few would succeed.

 Naturally, I recommend my ``The C++ Programming Language (2nd
 edition)'' for learning C++, but there are many other good books
 out there, and my book is not the best tutorial for everyone.
 Take advice from others who have succeeded in becoming good C++
 programmers (rather than from self-proclaimed C++ haters or people
 without ractical C++ experience). It is a curious phenomenon to find
 self-proclaimed C++ haters trying to cash in on C++'s popularity
 by teaching C++, writing articles on C++, and even by writing
 C++ textbooks as their first C++ project.

 Whatever you do, focus on concepts and design issues rather than
 language-technical details. The details will come in time provided
 the basic concepts are there. Try to avoid relying exclusively on
 ``how-to manuals'' and ``handy-hints books.'' I have even noticed
 people on the net who clearly were trying to learn C++ without any
 textbook or reference manual; such an effort must be most frustrating
 and have a low probability of succeeding. It is also a sad waste
 of time even if it - against all odds - should succeed.

 Another thing to keep in mind is that C++ is not Windows, Unix,
 X, MacApp, Etc. These systems have their own logic and complexities
 distinct from those of C++. Simultaneously trying to learn event-driven
 user interfaces, distributed computing, OOD, and C++ is definitely
 hard. However, C++ is often the least complicated entity in such a
 collection of concepts/tools/systems/libraries. Blaming C++ for the
 complexity of a system used through it is not quite fair - even if
 C++ and its various program development environments are the most
 visible and tangible part of such a system.

 The bottom line is that the world is VERY complex, and to some
 extent the tools we use reflects that. Among the tools we use,
 C++ is nowhere near the most complex.

 Whatever the reason, and contrary to the popular doomsday scenarios,
 most programmers who genuinely try succeed in becoming productive C++
 programmers in a reasonable time.

``C++ programmers are idiots''

 When C++ was new, one of the things that pleased me most was
 that discussions about C++ were so much better informed than
 discussions about most other languages, that the understanding
 of key concepts were so much better in C++ groups than in, say,
 C and Pascal groups, and that groups such as comp.lang.c++ were
 so much more polite and supportive than that of other groups.

 Clearly, I thought naively, C++ attracts a much better class of
 programmers, learning C++ helps people to absorb the key concepts
 of good programming/design, and the resulting success makes people
 more tolerant and helpful.

 I was wrong. The phenomenon was real, but it had little to do with
 C++. In a small dedicated community, life is relatively easy. people
 do their homework, people have access to reasonable sources of
 information, gross errors and misconceptions are corrected before
 they can cause significant harm, compilers and teaching materials
 are up-to-date, etc.

 This is not and cannot be the case in a multi-hundred-thousand
 member community: Some will be taught out of outdated or unsuitable
 books, some will use antiquated compilers and tools, some will
 be taught by charlatans, some will be remote from current and
 reliable news-sources, some will have unsuitable rules and
 regulations imposed on their work, etc. Also, in a rapidly growing
 community, most users will be novices.

 Does this make C++ programmers idiots? or ``on average idiots?''
 Not at all, but the average C++ programmer is not part of a
 relatively closely knit elite with access to the latest
 information and tools. Neither is the average C++ programmer
 someone with a lot of spare time for study and stimulating
 intellectual debate. When the number of any group goes up,
 the average - in every way - MUST converge towards the industry
 average.

 Proponents of languages that still have relatively minute - and
 therefore relatively close-knit and well-informed user communities
 - are making the mistake I made: seeing the evident success and
 enthusiasm of their fellow ``cult members'' as a direct consequence
 of qualities of their favorite language. They are wrong; if - against
 all odds - their language should escape into the mainstream the
 vastly enlarged user community will get its share of the problems
 and failures.

 Many of C++'s problems are best ascribed to problems with the scale
 of the user community and the scale of the problems attacked - as
 opposed to problems with the C++ language design.

 Many of the most experienced individuals and organizations in the
 industry (and academia) use C++. Ascribing their choice of C++ over
 alternatives to stupidity, ignorance, or inexperience is arrogant
 and insulting - and in many cases simply wishful thinking based on
 a limited field of knowledge.

 I still think the average C++ programmer is pretty smart, but rarely
 a fanatic, and usually too busy getting the work done to bother with
 language laws or the latest academic advances in OO type theory.
 Fortunately, one doesn't need to be a genius to write good C++.

``C++ is just C, but worse''

 C++ can be used just like C, but it doesn't have to be and in general
 it isn't. Many (most?) people start with C++ as a more strongly type
 checked versions of C, use libraries, add a bit of data abstraction,
 and then progress to a more complete and effective use of the C++
 specific features. That is in my experience a good way to progress,
 especially if you are not in an environment where genuine experience
 with OO in C++ is available and supported by management.

 One effect of this gradual approach is that as long as the number of
 C++ programmers and C++ projects is growing rapidly, much (most?)
 C++ code will be written by people at the beginning of their personal
 or organizational learning curve. Their code will reflect it.
 However, this situation does not last - however much as detractors
 would like it to. All the personal and indirect experience I have
 indicates that people are moving right along as expected.

 Talking about C/C++ as if it were one thing and ascribing every
 weakness of C and negative past experience with C to C++ is just
 plain wrong. personally, I take most uses of the compound ``C/C++''
 as an indication of ignorance.

 Considering C a smaller, faster, and better specified alternative
 to C++ is another popular fallacy. The C-like subset of C++ is as
 fast, as well specified, and easier to deal with than C itself.
 One source of popularity of this fallacy is an unwillingness
 by some C/Pascal-level programmers not to learn something really
 new. Another is wishful thinking by some proponents of more
 advanced languages: after all, if C++ is simply a more complicated
 C it cannot be a serious competitor to a more advanced language.

``C++ is useless/unreliable/dangerous because it lacks feature/property X''

 Also heard as  ``you can't write real/reliable/maintainable/elegant/
 re-usable/object-oriented/modern software without feature X - and C++
 doesn't have X.''

 Bosh!

 Once you - as many - have seen a few dozen large industrial C++
 projects completed on time, as budgeted and going through maintenance
 as hoped for, clever arguments based on the necessity of individual
 language features - invariably features absent in C++ - lose
 their credibility. Such arguments remain interesting sources for
 ideas for improvements of C++, but their central sales/propaganda
 message is fundamentally discredited.

 Over the years C++ has been deemed useless because it lacked
 (among other things) type checking, metaclasses, multiple
 inheritance, garbage collection, generics, concurrency support,
 exceptions, co- and contra-variance, dynamic linking, typecase
 switches. Simultaneously, if was - often by the same people -
 deemed useless because it was too complicated and had too many
 features. At the same time, a steady and increasing stream of
 projects were successfully completed in C++.

 My firm conclusion is that no single feature is truly necessary.
 Much more successful software has been written in languages proclaimed
 BAD, than has been written in languages acclaimed as saviors of
 suffering programmers; much more.

 Also, each time C++ has acquired another feature - according to my
 original view of how the language should evolve - the absolutely
 essential feature people used as proof of C++'s fatal weakness
 changed.

 The real driving logic seems to be:

  If feature X is in <<favorite language>> and not in C++,
  it MUST be fundamental to <<favorite buzzword>>.

 That is backwards and illogical, but it makes commercial and
 psychological sense. After all, if <<favorite language>> didn't
 have such a killer feature arguing against C++ in a simple-minded
 manner could be unpleasantly hard. One of the oldest and most
 disreputable tricks in the book is to define OO so that <<favorite
 language>> and no other language really supports OO. Since every
 neat feature can be illustrated by a neat example that can't be
 done without some ugliness in a language that doesn't have the
 feature, the redefine-OO trick always takes in a few suckers.

 Fortunately, these ``neat features'' rarely prove as essential in
 practice as their proponents claim they are in theory.

 If no feature is essential, then why use any features? You can in
 theory write anything in machine code, and apparently get anything
 to work in the real world using C. However, why should you where
 there is a better alternative available? Many people strongly
 prefer C++ over procedural languages such as C and Pascal and
 deem the feature set provided by C++ close to essential for
 their applications. A feature need not be essential to be helpful.
 The set of features provided by C++ is such that aspects of
 most major features get used in most major programs - directly
 or indirectly.

 I do not consider the set of features in C++ excessive; where a
 genuinely needed feature is missing from a programming language,
 the result isn't that the programmer has to understand less to
 work on a system; the result is that the complexities gets represented
 in the code itself rather than in a common form in a programming
 language. A major benefit of supporting a feature directly in a
 language or in a standard library is that much of the effort needed
 to understand one system will pay off when looking at another
 system where similar language and library features have been used.
 Such benefits are far harder to achieve when mechanisms are provided
 through code in a simpler language.

 Remember that many C++ features are there primarily to allow library
 building. Not every feature needs to be used directly by every user,
 nor does every feature have to be examined in detail by every tutorial.

``C++ is not Object-oriented''

 C++ supports object-oriented programming (as defined by most
 people). C++ supports it pretty well for real-world applications.
 Its type system and general model of the world are coherent and
 relevant to real applications.

 The proof of the pudding is in the eating, so I consider the fact
 that many large projects have been completed using C++ much more
 significant than the fact that C++ doesn't conform to the latest
 fashion of OO theology.

 Have a look at the ``Design Patterns'' book by Gamma et.al. for
 examples of elegant designs clearly expressed in relatively
 straightforward C++.

 I observe that there are a lot of myths about what features C++ has
 and doesn't have, and also about the essential soundness of the
 features that people (mostly) agree that it does have. Many posters
 and even many writers of academic papers really ought to update
 their knowledge of C++. It would be unfair to seriously complain
 just because someone didn't know about a feature added to the
 upcoming C++ standard sometime during the last year or a feature
 for which an implementation wasn`t generally available. However,
 I see claims based on the 1985 edition of ``The C++ Programming
 Language.'' That - especially when comparisons are made with
 experimental languages - is totally misleading. Doing so in 1994
 is intellectual sloppiness bordering on dishonesty.

 If comparing C++ to a widely distributed language, at least try
 to compare to C++ as distributed over the last few of years (say,
 as described in the 1991 2nd edition of ``The C++ Programming
 Language.'' If comparing with an experimental language. Try to
 get up-to-date information - say ``The Design and Evolution
 of C++'' or the C++ standards committees working paper. ``The C++
 Report'' and other magazines tries to keep their readers informed
 and tend to be only a meeting or two behind the committee. Simply
 relying on hostile hearsay from the net is not respectable.

``C++ compilers/tools are too buggy''

 Yes, but they are getting better.
 Yes, but compilers/tools are never quite good enough.
 Yes, but they have - often just barely - been good enough for real work.
 Yes, but they are still better than the alternatives on many platforms.

 Most importantly, C++ and its various implementations have a solid
 core where different compilers tend to agree and where the code
 generated is reliably good. There are several ways of looking at
 a language. If your job is to write a test suite or your aim is
 to ``push the envelope'' of what can be done, you hit a lot of
 annoying bugs and variation between implementations. If your job
 is to build systems, you try hard to avoid the grey areas - and
 often succeed.

 By and large, C++ compilers have been ``ok but not great'' according
 to the standards of their community. Some have been better. Now that
 the rate of language changes has decreased, I expect to see significant
 improvements in quality; in fact, I think I'm already seeing signs
 of that.

 C++ tools are improving in general: For example, I had expected it
 to be years before I saw a C++ debugger that allowed you to stop
 a program at a breakpoint, rewrite a function, and then restart
 the program using the new function. Sun now sells a C++ system
 handles does that. Another example of the improved state of affairs
 is the wide availability of memory-leak detectors, simple browsers,
 and other useful program development tools.

``The C++ standards committee is out of control''

 (whatever that means)

 First of all, you can't believe everything you hear on comp.lang.c++,
 comp.std.c++, etc. In general, such forums are noisy and dominated by
 a relatively low number of people with strong opinions and relatively
 few restraints on expressing those opinions. If you consider the net
 in any way representative, you can get a spectacularly warped view
 of the world.

 Facts:
  Most proposals for language extensions are rejected.
  Most proposals for changes are rejected.
  Most accepted changes and extensions are minor.
  The committee is working on a rather tight and definite
   schedule (Committee draft and US public review
   early in 1995, final vote as soon after as ISO
   rules allows for).
  The committee is working of a schedule as tight as
   that of other language standards (e.g. C and Ada).
  Most members of the committee are honest, competent,
   and hardworking individuals.
  Most members of the committee would rather see
   a finished standard and get on with something else.
  The committee is responsive to events and opinions in
   the C++ community at large - partly through the
   organizations the members represent and partly
   through a general willingness to listen and explain.
  Many members help popularize the deliberations and
   decisions of the committee (but it is hard to
   reach a large and diffused user community - see
   messages on the net, magazine articles, conference
   talks, etc.).

 If you can, come to a meeting and see for yourself. There is no fee
 for attending a single meeting and you don't have to represent anyone
 to visit. Reasonably enough, you can't vote at your first meeting,
 though. Some members may show impatience if you try to take precious
 committee time without having done your homework, but you can listen
 and there are lots of time to discuss things outside formal sessions
 of the committee as a whole.

 Currently, work is focused on clarification and on libraries.
 Just one language extension has been approved during last 8 months
 (adoption of the keyword ``explicit'' to suppress use of a constructor
 for implicit conversion) - and that's a restriction.

 Much work has been done on details of name lookup, overload
 resolution, the type system, the memory and object models, etc.
 The major event in the library area was the adoption of the STL
 library in response to demands for containers, etc.

 It might be worth mentioning that two things are happening at once:
 Compilers are being developed and distributed at the same time
 the language development is continuing.  Whichever order those two
 things happen in, *someone* will complain.  Moreover, if language
 development stopped, people would complain too. Already, some
 people are complaining because the rate of language change has
 slowed to a crawl.

 I find it blatantly unfair when posters use strong words against
 ``the committee'' because it is a nebulous concept like ``the
 bureaucrats.'' The committee consists of hardworking individuals
 most of whom just happen to be unable to respond to comments in
 various forums. Suggestion: Don't post anything about the committee
 that you would be ashamed saying to me face-to-face in public.

 Also, please remember that the committee members are all volunteers.

``I have heard of lots of C++ disasters''

 - and senator McCarthy had heard of 200 communists in the US state
 department; he even claimed to have a list in his pocket.

 There were a month-long thread in comp.lang.c++ and elsewhere
 headed ``C++ disasters.'' In fact, no genuine C++ disasters were
 documented. There were lots of statements on the form ``X failed
 and they might have used C++'' and ``X was in trouble and they
 used C++'' but I didn't see any message making a causal link
 between C++ use and failure plausible. C++ was being blamed for
 everything from the collapse of the US phone system (it didn't
 collapse and the breakdown people keep referring to occurred in
 a system not written in C++) to the Denver airport baggage
 handling system (there were/are a bit of C++ in that system but
 not anywhere near as much C++ as C and assembler). By the quality
 of the ``logic'' applied it is a marvel that C++ wasn't also
 blamed for the (possible) crumbling of the runway surface.

 Genuine C++ failures must occur. After all, when a lot of people
 try some non-trivial new tool - any new gadget - some will ``fail.'
 I think it would be fair to guess that 10% to 20% will miss the
 point, find the tool not to their taste, fail to use it correctly,
 apply the tool in an area that it is unsuited for, etc. By that
 logic and the sheer weight of numbers we must conclude that more
 programmers have had some failure learning or using C++ than have
 tried any other OO language. This would explain the emotional heat
 of some criticisms of C++.

 Many more have succeeded with C++, though, and most failures must
 have occurred on a small scale or we would have heard much about
 them - people tend not to be shy about publishing other people's
 failures (even in an ideal world that would be bad taste). I see
 no evidence that projects using C++ have a greater failure rate
 than projects in general. In my limited experience, the opposite
 seems to be the case, despite that C++ appears to be used on a
 disproportionate number of ``ambitious'' projects. I take this
 as a testimony to people's good sense, to C++'s flexibility, and
 to the fact that  strong core of genuine C++ experts have always
 recommended caution in the adoption of C++ and new techniques.

 On the other hand, the C++ community is somewhat to blame for not
 doing more to publicize their successes. As usual, the C++ community
 is anarchic and possesses no central focus - such as a single users
 group or a central coordinating organization. Usually, that is an
 advantage because it helps foster initiative, but when it comes to
 collecting and dispensing information the C++ community is at a
 disadvantage compared to communities focused of a single central
 company or organization. It would be a major benefit if someone
 would collect - and make easily available - brief descriptions of
 a couple of hundred C++ projects of significant size.

``I just don't like C++''

 Fine. There are lots of things I don't like. Sometimes, I object
 to aesthetic aspects; sometimes something just doesn't serve my
 needs. If asked, I may even express my negative opinion, but rarely
 rudely, and never as an unprovoked attack or a snide remark about
 other people's work. If I am perceived to do so by lack of
 consideration or I slip up (nobody is perfect), I apologize.

 I don't apologize for C++, though. I find C++ the best choice for
 a wide range of applications. If you can find the time, I encourage
 you to try to find out why that is. Many have found the effort
 worthwhile.

 I wish more people would distinguish between an expression of
 personal opinion/taste (such as ``I just don't like C++'') and what
 is claimed to to be an expression of objective fact (such as ``C++
 sucks''). It seems to me that a significant number of posters have
 difficulties distinguishing their personal opinions from objective
 facts.

 Live and let live is a good policy. Spending a lot of emotional
 energy attacking other people's work is unhealthy.

Final comment:

 In this note, I didn't try to present technical arguments
 for (or against :-) C++. You can find many of my technical
 arguments and opinions in my books and papers. Other good
 sources of information about C++ and its use are the proceedings
 of the USENIX C++ conferences, ``The C++ Report,'' Andy Koenig's
 column in JOOP, and (to a lesser extent) the OOPSLA proceedings.

 I encourage the C++ community to make a greater effort to document
 work done in C++ and make such information more generally available
 (that is, not just preaching to the choir).

 In general, I encourage people to popularize their favorite
 programming system through solid examples, rather than by
 merely scoring points off imagined opponents by clever programming
 tricks or demagogy.

 In general, try to be a bit more tolerant and refrain from
 hyperbole. We need an intellectual honest discussion and a
 greater degree of professionalism in the discussion of
 programming and programming languages.

  - Bjarne Stroustrup

Bjarne Stroustrup <9758-26353> 0112760 (bs@research.att.com) wrote:

: This message is a response to a lot of outrageous inaccuracies, innuendo,
: rudeness, and flat-out false statements about C++ and its user community.
: The most dignified response would be a solid technical paper documenting


(long text message deleted)


I agree.  However after reading a few of these message I just delete them
as noise.  I have been teaching C++ for about three years now and have
also encountered some hostility toward the language.  I find it comes
from people (I'm dealing with professionals here) who are scared when
they find that they can't quickly grasp the concepts necessary to design
and build classes.  Since they can't understand the concepts quickly,
they need to blame something other than themselves so the language is the
obvious target.  Upon working with these students I find they can't
really handle C either but they don't realize it because in C you can
avoid features such as structures and pointers and believe you are
programming in C.

I eventually attempt to demonstrate the value of C++ to these programmers
by giving them a typical software maintenance task.  I have a simple
banking problem written both in C and C++.  I ask them to add a few
features and they find they can upgrade the C++ version easily and the C
version is much more difficult.  I explain that class design is very
sophisticated and not for everyone.  However, once classes are designed
properly, the remainder of the programming chore is significantly easier.


On the other hand, many of my professional friends who did not like C and
would even choose Ada over C have embraced C++ and refuse to use anything
else.

I, too, get comments confusing C++ and Microsoft Windows.  From the
programmers point of view the two may be one in the same.

Anyway, I'm not sure why people who do not like C++ take the time to read
these newsgroups and make such comments.

Regards,


John C.