For people who are interesting in threads and other concurrency issues in
the context of C++,

        G.V.Wilson and P.Lu (editors):
        Parallel Programming Using C++.
        The MIT Press
        ISBN 0-262-73118-5

offers descriptions of a variety of approaches and systems.

        - Bjarne

: This has been covered ad nauseum, but here is my short list, without
: justifications cause I don't have the time to do that yet again. Each of
: these represents a major rant on my part (long done, many times over in
: the Java forums.)

Ok, in that case I'll refrain from commenting since you don't wish to
go over that again.  I will say that I have different complaints about
Java, but I'll leave it at that.

[Snip -- list of grievances against Java]

: > Ahhhh but unlike other language abusers, the C++ haters I've seen have
: > provided great reasons to demonstrate why C++ stinks, reasons that
: > the advocates never manage to counter.  With non-C language haters,
: > the "arguments" are more like complaints, with little or no reason
: > provided.
: >

: I won't even bother to answer that because its pure opinion, which I
: could only counter with opinion of my own.

Ok fair enough.

[Snip -- info on Ada's "pointers"]

: Those are relatively interesting, but not nearly useful enough to get
: off the mainstream and use Ada for any work of my own. I would not argue
: if C++ adopted some of those things, nor would I if it adopted some
: other things from the Modula/Ada family. If I could create my own
: language, it would be nice but even less people would use it than Ada
: unfortunately.

Well when I wrote that passage I never expected you to drop your C++
compiler and embrace Ada :).  Ada does have some very nice features,
and in fact many languages (not just C++) would do well to adopt
some of them.  Of course I've since moved on to the functional
world so I don't use Ada, but I still have a deep respect for it.

[Snip]

: > So C++'s lack of useful functionality is supposed to be a benefit?
: > I think not.
: >

: Absolutely it is. People never understand this. C++ does not force any
: view on you. Therefore, people can create class libraries for you to buy
: that represent many ways of doing things. This increases the chances
: that there is one that suits your particular needs. This is the
: antithesis of the 'built in' scheme, and it is what really makes C++
: appealing to so many people.

The problem is that you continue to assume that providing functionality
means locking the user into a closed world -- that is not so.  Scheme
is also a bad example in this case, because one of the things it is
known for is its small size.  A better comparison would be C++
with Common Lisp.  Common Lisp provides you with tons of goodies,
but at the same time you are not locked into anything -- you can
alter everything from adding your own control structures to
changing the syntax of the language!  This is vastly more control
and "malleability" than what C++ provides, and Common Lisp does
this WHILE providing you with numerous _USEFUL_ features.

: > Sure, you are free to spend ages programming in preparation for your
: > real program.  I do not like re-writing things that should be
: > available.  When I program I want to concentrate as much as possible
: > on the problem domain and not spend my time trying to find ways
: > around ridiculous limitations in the implementation language.
: >

: As I've said. You BUY THE CLASS LIBARIES YOU WANT! No one starts a major
: C++ project with just a raw compiler. They start with a class library
: that they buy (or that comes with their compiler) that provides far more
: out of the box functionality than any 'built in' language ever will, and
: allows you pick from a list that best suits your needs.

Why should I buy class libraries for basic things that should be part
of the "core" implementation?  I mean according to your argument not
only am I stuck with missing functionality, but I have to spend money
to get the functionality that I should have had?  If I'm going to
buy third party packages, they will be packages that I cannot reasonably
expect to find in an implementation.

[Snip]

: > You are making a classic mistake of thinking that security means
: > limitations.  Again I point you to Ada.  Ada is secure, Ada gives
: > you the power of C++ (if not more).  There is nothing that says
: > that a language should let you hang yourself just to buy you power,
: > this myth has been propagated by C++ advocates who are desperately
: > looking for a reason to justify the inherent flaws in the language.
: >

: There was nothing in the preceededing paragraph about that. The security
: point was talking about using the securty system of the host OS.

Then I misunderstood.  Yet even with your definition you fail to make
any point for C++.

: > That's very nice, but you forget one thing -- programmers are people
: > and people make mistakes.  Not providing safety measures is great
: > if you are dealing with a species of super-intelligent, perfect
: > programmers, but you aren't.  You are dealing with people and with
: > that in mind these lack of safety measures are nothing short of
: > stupid.
: >

: If you compile your progam and don't read the errors and warning that
: compiler generates, then you should probably move more towards the
: basket weaving genre of employment opportunities. Any decent C++
: compiler will warn you about pretty much any questionable thing you do.

Stop right there.  Now we're getting into the gray area of "what vendors
_SHOULD_ do".  This is a Bad Place(tm).  Leaving critical details
to vendors who have their own agendas is not the wisest of moves.
Furthermore, while I do agree that good programmers should heed
warnings, the fact remains that there is no enforcement for the
not-so-good programmers in your project, or the ones who goof and
miss a warning for some reason or other.  Again too much trust
is placed in the programmer.  The whole problem with projects is
that you don't have absolute control over what others do.

: And if that's not enough you can buy something like Bounds Checker than
: will load your program and run it and check for a humongous number of
: other things at runtime. The fact that people don't use the tools
: available is not my fault, nor is it the fault of C++ or any other
: language.

The fact that people have to spend extra money to get such a thing
rather than have an intelligently defined runtime that should do
these BASIC tasks is C++'s problem.  

: > So you are saying that the lack of a FUNDAMENTAL data type is an
: > advantage?  You are joking aren't you?
: >

: No I'm not. I explained this above a couple of times.

And you did so inadequately each time.  Your explanations are predicated
upon the faulty assumption that power and flexibility are mutually
exclusive features.  They are not.

: > : It doesn't do much good to mention them because you already have
: > : convinced yourself that they are stupid but... multiple inheritance,
: > : templates, namespaces, inlining, mutable members, typesafe collections
: > : via templates, polymorphism, RTTI, strong const usage, and operator
: > : overloading come to mind.
: >
: > Other languages have had these before C++.  Again your point?
: >

: You didn't say that other languages had them before C++, you said that
: C++ didn't have them.

That is a blatant lie.  I did not even mention many of the features
you stated above, much less deny that C++ had them.  I strongly
suggest you be less creative in your interpretations of what I write.

What I did mention was a lack of safety and a lack of basic functionality
(using strings as an example).  Nowhere did I mention inlining,
mutable members, RTTI, etc...  I did mention being able to typecast
your way into hell so MAYBE you might get away with pinning a "strong
const usage" on me -- but that term is so generic and meaningless
("usage" says nothing about "enforcement") that doing so is
irrelevant.

: -------------------------
: Dean Roddey
: The CIDLib Class Libraries
: 'CIDCorp
: drod...@ng.netgate.net
: http://ng.netgate.net/~droddey/

: "Software engineers are, in many ways, similar to normal people"

--
Cya,
Ahmed

Matt Kennel (Remove 'nospam' to reply) (ken...@nospam.lyapunov.ucsd.edu) wrote:
: On Sun, 11 May 1997 19:14:35 -0700, Dean Roddey <drod...@ng.netgate.net> wrote:
: :
: :It doesn't do much good to mention them because you already have
: :convinced yourself that they are stupid but... multiple inheritance,
: :templates, namespaces, inlining, mutable members, typesafe collections
: :via templates, polymorphism, RTTI, strong const usage, and operator
: :overloading come to mind.

: If that's why you like C++, you really must try Eiffel.

Not to mention the fact that Eiffel has other excellent features
like "programming by contract".  

: :Dean Roddey
: :The CIDLib Class Libraries

: --
: Matthew B. Kennel/Institute for Nonlinear Science, UCSD/
: Don't blame me, I voted for Emperor Mollari.

--
Cya,
Ahmed

: The fact that another language does it means that C++ does not?

C++'s lack of features is only one aspect of our discussions.  However,
even pointing out poorly implemented features, and ones implemented
late at that are very relevant as they show poor design.  That is
my ultimate point.

: Once
: again, it makes no difference whether Lisp does it or not, becuase Lisp
: is so far out of the mainstream that it is irrelevant. Get Lisp into the
: mainstream and, if its really better than C++, I'll be on it like white
: on rice. I'm more than ready to take something better, but its got to
: also be commercially and professionally viable.

A language's quality has nothing to do with how frequently it is used.
That is a function of marketing and marketing alone. C++ made it
because it was a superset of C, so it automatically had a huge
advantage right there.  C made it because it was almost mandatory
to know it to program in Unix.  Notice how quality had nothing
to do with the rise of these languages.

: I'm not sure though that I WANT to create a new language. C++ does not
: allow you to create different fundamental language syntax or define new
: operators. I think that is the correct cut off point. Building worlds
: upon a common substrate is a powerful concept because the user's
: language skills apply to any new system. Only the higher level world
: implemented is different.

You are avoiding the point -- and that is that Common Lisp is more
powerful than C++ and more flexible to boot, so your entire argument
that C++ is the way it is because you can't provide power without
sacrificing flexibility is nonsense.

: > And languages that give you nothing will always be a burden on the
: > programmer who is forever cursed with having to re-invent the
: > wheel.
: >

: No, they BUY a wheel out of a nice selection of wheels that roll they
: way they like instead of having to take the wheel that comes on the car.

So you are saying that C++ is like a car without wheels -- which
is informative because a car without wheels cannot be driven which
makes it useless.  The analogy fits perfectly.

: > So instead of providing power that the user could use, we say "hey
: > it could be out of date, let's not give the user diddly"?
: >

: Already answered.

Inadequately as usual.

: > Power can be provided with both the ability to re-implement as needed,
: > and to take advantage of a flexible framework.  You are thinking
: > in a simplistic, flawed manner -- the C++ way.
: >

: You'll have to expand on that argument cause I get nothing out of it.

: How can your language X, which implements a particular view of a file
: system take advantage of a different file system, with different
: capabilities without effectively changing its file system API?

By providing a flexible API that can accomodate many different file
systems that's how.  Then the implementation underneath does whatever
it needs to do, the programmer need not be aware of it.

: If it
: changes its file system API for every platform its on, how is that all
: that different from C++ having class libraries on each platform, except
: that the C++ libraries on that platform probably take better advantage
: of the platform capabilities?

You are confusing interface with implementation.  I find it delightfully
ironic that this mistake would be made by a C++ advocate.  It just
adds more credence to what I'm saying.

: How can it take advantage of a fundamental
: system like NT's security system in which elaborate permissions can be
: set on every single object in the system without fundamentally changing
: its entire library API?

I just answered that above.

: It would be nice to have a single API that fits all, but it will never
: happen. I've done a lot of work in this area and I know its not possible
: to make everyone happy. Java's AWT will soon discover this ugly fact, if
: they have not already.

It depends on the scenario now doesn't it?  In the case of tradeoffs
it is possible to reach a good compromise -- which is what your
argument for C++ is, that it is a good compromise, or are you
retroactively rescinding your argument now?

: ------------------------
: Dean Roddey
: The CIDLib Class Libraries
: 'CIDCorp
: drod...@ng.netgate.net
: http://ng.netgate.net/~droddey/

: "Software engineers are, in many ways, similar to normal people"

--
Cya,
Ahmed

C++ for all of its numerous flaws does allow you to use a lot less
memory than dynamic competitors like SmallTalk, Lisp, and even Java,
and this boosts performance for real apps.

-- Harley

--
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
drod...@ng.netgate.net
http://ng.netgate.net/~droddey/

--
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
drod...@ng.netgate.net
http://ng.netgate.net/~droddey/

------------------------
Dean Roddey
The CIDLib Class Libraries
'CIDCorp
drod...@ng.netgate.net
http://ng.netgate.net/~droddey/

no way.

At least if the code is supposed to work as expected, I rather let
compiler do the checking than manually fix the bugs by testing over
and over again... Testing can only show the existance of bugs, not
that you have no bugs.

For my current understanding of the C++ STL, I am indebted to
the 28 April 1995 draft of the C++ standard.  Now, that draft
is riddled with errors, and it's two years old by now, so my
information is clearly out of date.  If there is a current
draft that I can get a copy of, I will be only too pleased to
update my information.

My understanding is that Alex Stepanov wanted to provide a practically
efficient, highly generic, data structures and algorithms library, and
that he chose C++ as the vehicle for this after experimenting with
other languages.

I want to use a single example to argue that the C++ version of the STL,
as specified in chapter 23 of the 28 April 1995 draft of the C++ standard,
is not efficient, in the same sense in which Stepanov argues that versions
in other languages were not efficient.  That is, I am going to offer an
example of a natural operation that I think sequences "ought" to support
efficiently, and we'll find that the version of the STL described in the
reference I am using does not support it efficiently.

Let us imagine a sequence type which supports the following operations:

    size(S) -> N                             charge C[j] = 1
    fetch(S, I[j]) -> E                              charge C[j] = 1
    store(S, I[j], E) -> ()                  charge C[j] = 1
    insert(S, I[j], T[j]) -> ()                      charge C[j] = 1 + size(T[j])  
    delete(S, I[j], N[j])                       charge C[j] = 1

S is the type of sequences, I is the type of indices (I write in terms of
natural number indices, but that doesn't actually matter), N is the naturals,
and E is the type of elements

I shall say that this sequence type supports

        LINEAR (ascending) TRAVERSAL UPDATES

if and only if the cost of a series of M operations
where the indices I[j] are monotone non-decreasing is
        O(N + sum j = 1 to M of C[j])
where N is the initial size of the sequence.

I shall say that this sequence type supports

        linear descending traversal updates

if and only if the cost of a series of M operations
where the indices I[j] are monotone non-increasing is
        O(N + sum j = 1 to N of C[j])
where N is the initial size of the sequence.

I shall say that this sequence type supports

        linear bidirectional traversal updates

if and only if it supports both ascending and descending
linear traversal updates.

Note:  I have assumed in the formulas above that a subsequent index may
not land inside the elements inserted by insert().  If that _is_ allowed,
replace C[j] for insert() by 1 + 2*size(T[j]).  Note also that I am talking
about processing the _whole_ sequence; I am assuming the same kind of
dynamic allocation strategy that the C++ STL uses for vectors; the charges
are _not_ costs for the individual operations.

It should be fairly obvious that
- there are array-based implementations of sequences
  that can easily support linear bidirectional traversal updates.
- there are tree-based implementations of sequences
  that can easily support linear bidirectional traversal updates
- there are doubly-linked list-based implementations of sequences
  that can easily support linear bidirectional traversal updates
- there are singly-linked and fractionally-linked list-based
  implementations of sequences
  that can easily support linear ascending traversal updates
- there are sequential-access file-based implementations of sequences
  that can easily support linear ascending traversal updates.

The operation costs imposed by chapter 23 of the 28 April 1995 draft of
the C++ standard not only fail to guarantee linear ascending traversal
updates, they guaranteee QUADRATIC cost for this common combination of
operations.

Is this a straw man argument?  Have I come up with something which isn't
done fast, but which no-one in his right mind would _want_ to do fast?
Well, ascending traversal updates are simply an application to sequences
of traditional sequential file processing.  fetch() is read(), store() is
rewrite(), insert() at the end is write(), and delete() is delete().
PL/I and COBOL have these operations built into there syntax.

Note:  if we restrict insert() to act only at the appropriate and of
the sequence, the quadratic cost mandated by the 1995 draft C++ standard
_still_ follows.

I mentioned fractionally linked lists above.  In order to provide the
operations called for by the algorithms section (chapter 25 of the said
draft), the STL list<T> class forces you to pay the storage and time
overheads of doubly-linked lists, *even when* singly- or fractionally-
linked lists are sufficiently powerful for the operations you actually
want.  I don't call that efficient either.

Note:  in 20 years of doing things with lists, the number of applications
where I found doubly-linked lists worth using can be counted on the fingers
of one hand.  For example, to support linear ascending traversal update,
a singly-linked list needs only one extra pointer and one extra counter over
the obvious implementation.  (Twice that if you can go back into an
insertion.)

In article <EA6F85....@research.att.com>, b...@research.att.com (Bjarne

I presume that you knew about the classic effect of organizational
psychology that was discovered in the 1920's.  GE wanted to sell more
electric lights to factories, but their potential customers kept saying
'show me the productivity'.  So GE set about to document productivity
gains from better lighting.  They outfitted a factory with lights capable
of a wide range of brightness.  Then they started increasing the light in
small increments and measured factory output.  As expected, the output
increased with the increase in brightness.

But these were real scientists, so they then started _reducing_ the light
output.  _Productivity increased_!  They kept on reducing the light and
productivity kept increasing, until the factory was so dark that they started
bumping into one another!  It turns out that productivity was far more dependent
upon management's attitude towards the workers than on any amount of light.  The
mere fact that management cared enough about what they were doing to pay
attention to them, made them work harder!

(Oh by the way, 6-12 months after the tests were done and the scientists
went away, productivity went back to essentially what it was before, regardless
of whether the new lights were left there or not.)

So unless you had some real professionals performing these tests, they
probably aren't worth the bits they are stored on.  (It is entirely possible
that C++ had reduced these people to wandering aimlessly around 'in the dark'.)

I hope that you also accounted for the increase in understanding of the
_previous_ language that they were working in.  Sometimes, merely being
exposed to a new language makes you think about the _old_ one in a new
light, and your productivity in the _old_ language may improve by as much,
or more, than your productivity in the _new_ language.  So you have to remeasure
their productivity again in the old language.

Finally, I would really like to know what fraction of the new language they
were using.  If they were taught a few minor things in C++, I could imagine
their productivity going up, because C++ finally fixed some real irritants
that C never got around to fixing.  But if they were programming in the
true 'OO' style, then I can predict a loss of between 6-9 months of work, while
they contemplated templates, objectified objects, and iterated loops.  (Hey,
we now know a _methodology_, man!)

There is this persistent myth in Computer Science that adding or subtracting
things from a language 'doesn't change it very much'.  But of course, CS
people haven't studied any linguistics, so they enter this battle of wits
completely unarmed.  Adding or subtracting relatively 'minor' features from
a language can _completely change the optimum programming style_ in a very
discontinuous way.  So there are at least 2 phases in learning a new language--
learning the bits and bytes, which normally doesn't take very long, and then
comes a much, much longer period, wherein a _style_ of programming is
developed that takes advantage of the changed situation and any new features,
and allows the programmer to finally achieve the best that the language has to
offer.

On 13 May 1997 20:59:21 GMT, Daniel J. Salomon <salo...@nickel.cs.umanitoba.ca> wrote:
:In article <slrn5neqgn.5ih.ken...@lyapunov.ucsd.edu>,
:Matt Kennel (Remove 'nospam' to reply) <ken...@nospam.lyapunov.ucsd.edu> wrote:
:|>
:|> There are lots of good languages with free compilers whose implementation
:|> quality exceeds the early C++ compilers.  And yet, what happened?
:
:Modula-3 falls into this category.  I had high hopes for it at one
:time.  It is safer to use than C++ and has a nicer syntax.  I found
:that when I used it, I spent my effort on debugging my algorithms, and
:not just my code, as compared to C++.  Nevertheless, I don't use it
:anymore.  I found that it fell short in features and efficiency.  For
:instance, Modula-3 does not have function and operator overloading, and
:because of fundamental design decisions, this feature cannot be added
:to the language.  In addition, Modula-3 has lately turned into a
:lifestyle choice:  if you choose Modula-3, you have to use their whole
:developement environment.

I use a language with a free compiler which

   * does have function and operator overloading
   * a very nice typesystem, with working genericity, and full separate
     MI of both implementation and subtype.
   * generates high performance numerical code competitive with
     hand-rolled C, and significantly faster than nearly all C++ matrix
     classes
   * interfaces quite well with C (e.g. you can have a FILE * as an
     object attribute or variable)
   * even works with Fortran arrays.
   * runs just fine with Emacs (with color-highlighting) and make.

and has had nearly all of this for five years.  And I didn't even mention
all the cool langauge things it does.

:The answer to your question is that developers "voted with their feet"
:and chose C++.  Your opionion of "better quality" seems not to be
:shared by the majority of developers.

I don't think most ever chose C++ over Modula-3, Sather or Ada95; they
chose C++ over C and Fortran and didn't consider anything else.

:Daniel J. Salomon -- salo...@cs.UManitoba.CA
:       Dept. of Computer Science / University of Manitoba
:       Winnipeg, Manitoba, Canada  R3T 2N2 / (204) 474-8687

Well, I must disagree here, as I see computer language as by far
the most historically successful means of transmitting style, paradigm
and philosophy---in other words the product of computer science research
into economically significant practice.

Add to that the fact that a lot of the work that was done on C code
optimisation also can apply to C++.

That just doesn't compare with what was ever spent on lisp compilers.

Although I do note that the Franz compiler appears to produce code
which is often faster than C/C++.

:Now that after 20 years we finally have that straight, can we move on
:to 'recurseration', 'recurserators', etc.

:)

My question 'why do we want an 'iterator' rather than iterating' was
meant to really pose the question:  

     Aren't there better ways of abstracting the generalized notion of
     iteration than the way these galumphingly unnatural "iterators" do?

{I know the answer must be 'yes'}  Analogy: it feels as if we have to
construct some normalized form of a finite state automation, set its
transition matrix, and let it rip, when all we really wanted to write
was various combinations of "if then else".

If we continue to nounify the question--as in construct a new 'thing' which
explicitly exists at run-time, we may lose sight of being able to do
something truly marvellous.

By the way, who is Barbara?

Helmut Zeisel

C++ took what was happening in the C world anyway,
and formalized it.  Along with a few other changes.
I think this may be one of the reasons for
the success of C++.  Instead of asking people
to covert to its own world view, it just took
what people were doing anyway, and made it easier.

The other major factor in C++'s popularity
may have been the advent of Windows.  With
Windows, the complexity level was getting to
be too much for straight C programming, and
people found a tool which helped them manage
the complexity without asking them to dump
their C expertise or to accept other peoples'
notions of what a good language should be.

Of course there were other tools doing
essentially the same thing, such as Objective-C.
C++ may have had the upper hand here because
people tended to trust something from AT&T.
Not because AT&T was doing major marketing of it.
(It is not even clear they knew how, shold they
have wanted to, at the time.  And strangely,
it would seem the influential C groups in AT&T saw
C++ as competition and hence did not give it their
support anyway!)

(define (last l) (first (reverse l)))

or:

(define (last l)
 (if (null? (rest l))
     (first l)
     (last (rest l))))

The former is less efficient than the latter. But the latter is more difficult
to write, debug, and prove correct (whether formally or informally). More
importantly, while the latter can be written in either Lisp or C, in a
practical sense, because of garbage collection, the former can only be written
in Lisp.

The former uses a library module, namely REVERSE. The later is written totally
with primitives. While one can write REVERSE in C, one cannot compose
REVERSE with FIRST as easy as one can do in Lisp. Because of the need to
negotiate storage management. And this breaks modularity.

Functional composition allows a much greater level of code modularity and
reuse. Typical Lisp programs build higher and higher levels of abstractions
around black boxes. Typical C programs have a high percentage of primitive
operators throughout all levels of the hierarchy that pierce through the
abstraction boundaries. (That is one reason why C programmers prefer infix and
Lisp programmers don't care. If C programs could use functional composition to
eliminate the primitive operators from the higher levels of abstraction, those
higher levels would not have any infix operators at all. They would look like
Lisp code, with just as many parentheses, just in different places.)

It is not the languages that differ in efficiency. Rather it is the
programming styles that they enable and encourage that differ in efficiency.
Functional composition allows Lisp to support an inherently higher-level
programming style. (Note that I didn't say functional programming. This has
nothing to do with recursion, higher-order functions, or side-effect free
programming. One can still avail onseself of functional composition even
without recursion or higher-order functions and even when there are side
effects.)

Now this has nothing to do with Lisp vs. C. Functional composition is such a
seductive programming style, because it is so much higher-level, that I
predict that if you add garbage collection to C (a.k.a Java) it is only a
matter of time before the entire world starts writing things like:

int last(struct list {int f; struct list *r} *l){return (reverse(l))->f;}

instead of:

int last(struct list {int f; struct list *r} *l)
{ for (; l->r==NULL; l = l->r);
  return l->f;}

The problem is that even when you add a garbage collector to C, the former is
much less efficient than the latter. And to automatically generate the latter
from the former, in the general case, requires partial evaluation and program
transformations like unfold-fold, something which, in the general case, is way
beyond the state of the art. So the functional-composition style is going to
remain less efficient than the atomic-primitive style for a long time to come.
Independent of the programming language and runtime model. But I predict that,
even so, the entire world will get so addicted to the functional-composition
style that they won't care. It is such a compelling force that Resistance is
Futile (TM).

In the end, not only will Lisp survive, it will be the only survivor. Not its
syntax, not its semantics, not its implementations, but its programming style.
Those of us who are still around will say `I told you so' and `What took you
so long'.

        class string {
        public:
                template <int i> string(const char (&array_ref) [i]);
                ...
        };

However, the C++ compilers I have available to me don't support template
member functions yet...

* Harley Davis
| In my experience, the real killer with Lisp is not so much raw speed, but
| rather excess memory use.

in my experience, Lisp systems start out with a couple megabytes of memory
to hold the entire run-time system, then grow very gradually and maintain a
low system profile as far as memory goes.  C programs that do any useful
amount of work grow rapidly and remain large after the allocated memory
have outlived their usefulness.  they even leak memory when run over long
periods of time.

the real difference between Lisp systems and C programs under Unix is that
the Lisp systems usually do their work in one long-lived process, whereas
the Unix way is lots of short-lived processes.  C's memory allocation is
well suited to this mode of operation, since the operating system does the
garbage collection when the process terminates.  however, the C++ way with
Windows is once again large, long-lived processes.  not surprisingly, C++
does _much_ worse in this department than Lisp systems generally do.

furthermore, if memory usage was a "killer", Microsoft would never have
been able to hoist its disgusting inferiority on the world.  even simple
tools like e-mail clients for Windows use more memory than computers _had_
only a few years ago.  Lisp systems _were_ relatively large, but since they
haven't grown very much, they are now _small_ compared to the cancerous
growth of software written by inferior programmers in inferior languages.

In article <xohsozp1g1l....@ai.emba.uvm.edu>, Jeffrey Mark Siskind

--Ham

* Bjarne Stroustrup
| Given the time that Lisp has been around (and CLOS), and given the number
| of organizations that has been involved in Lisp-related research, I do
| not think that it is obvious that more money has been spent on C++
| compilers.  I suspect that it is not the case.

hm.  how long do you think CLOS has been around?  IIRC, you started on C++
before 1980.  the first widely available CLOS "user guide" was published in
1989, and a specification in 1990, although a lot of experiments with other
object-oriented languages had been going on in the Lisp community.

the Lisp family has one easily identifiable problem that other language
families have avoided: Fortran has had version numbers or years added to
it all along its developmental route, and Ada83 is not Ada95.  however,
"Common Lisp" is the name of two languages, possibly three (Common Lisp the
Language, 1st (CLtL1, 1984) and 2nd (CLtL2, 1990) edition, and the final
ANSI standard (ANSI-CL 1994)).  "Lisp" is moreover the rightful name of
_lots_ of languages.  C and ANSI/ISO C are close enough that "C" is now
largely synonymous with "ANSI C", but C++ is as different from C as ANSI
Common Lisp is from Common Lisp the Language, 1st edition.  however, people
who were dissatisfied with Lisp in 1965 can still proclaim to be talking
about "Lisp" as if nothing had happened since then, albeit with limited
credibility.

so, how much money has been spent on Common Lisp and CLOS compared to C++?
note that you have to subtract all the money on C from C++ and all the
money on Lisp from Common Lisp and CLOS.  do you still think you have a
case?  I don't.

last time I heard, Borland and Microsoft spent more than a billion dollars
each on their C++ environments, and that nearly killed Borland.  a similar
stunt to produce a C++ environment _did_ kill Lucid, Inc, a very successful
Lisp vendor.  (it's Lisp product survived, the C++ efforts didn't.)

| One problem with C++ is exactly that the PC compiler suppliers spends FAR
| more on windows-related GUI flash than on their compilers (i.e. on the
| part of the software development environment that is devoted to getting
| the source text correctly translated into efficient object code).

isn't this true for _all_ products in the PC world?  PC programmers don't
seem to care about compiler or language conformance at all.  it needs to
"look cool" and "run fast" and if it works correctly most of the time, too,
hey, that's great, but no real requirement.  such programmers seem content
to test their code against the compiler and see if the machine does what
they expect it to do.  they write code that behaves as they want in testing
instead of code that follows the specification of the language.  in fact,
they write code for the specific machine, operating system and compiler
_instance_, not _any_ specification, and nobody in their right mind would
want to port PC software to a _real computer_, so who cares if all the
programmers there really program in assembly, anyway?  (although it looks
like a high-level language to the untrained observer.)  whatever comes
after Bill Gates' multi-billion-dollar fraud operation is exposed sure
isn't going to be written by people who have this mindset, however many
millions they number today.

if there is any justice in this world at all, the mechanisms that caused
people to shy away from Lisp because of perceived problems in the past
related to hype and delivered products will hit C++ with even more force.
I derive some peace of mind from this.

In article <EA7AF1....@research.att.com>, b...@research.att.com (Bjarne