In article <1995Jan19.003949.1308@news.wesleyan.edu> Jason Sproul <jsproul@wesleyan.edu> writes:

   In article <3f5pkp$gb3@news.halcyon.com> Timothy Sharpe,
   gadget@halcyon.halcyon.com writes:

   >o If that language uses header files, let the
   >system find the prototypes and librarys it needs for me.

   2) Auto-loading libraries is a pre-pre-processor issue, and a pretty
   trivial one at that. But do you really *want* the compiler searching your
   entire <> directory for an undeclared or undefined function that you
   forgot to define? Doing development on the Mac, my <> directory is over a
   meg (lots of toolbox headers, plus tons of custom libs). That's a lot of
   text to parse. (Am I missing a better way to do this?)

Well, Ilog Talk uses a database as a cache for module export
information so that the system can automatically generate imports.
This avoids scanning over the module descriptions for every
compilation.  The database is updated automatically by the system when
a module's exports are modified; it can also be recreated at will if
the user finds that the system gets wedged somehow.  (You can find out
more about the Ilog Talk module system and its support for automatic
dependency tracking by checking out our ACM conference paper "Talking
About Modules and Delivery", available at our WWW server
http://www.ilog.fr/ or the Ilog Talk white paper at the same site.)

So I think there is a better way than rescanning megabytes of files
each time.

In C/C++ systems, there are often precompiled header files which might
speed this up too.  I don't know of any that find header files for
you, though.

-- Harley Davis

--

------------------------------------------------------------------------------
Harley Davis                            net: davis@ilog.fr
ILOG S.A.                               tel: +33 1 46 63 66 66
2 Avenue Galli   ni, BP 85                fax: +33 1 46 63 15 82
94253 Gentilly Cedex, France            url: http://www.ilog.fr/

           Ilog Talk information: info@ilog.com

In article <3f5pkp$gb3@news.halcyon.com> Timothy Sharpe,
gadget@halcyon.halcyon.com writes:
>My personal opinion is that the best programming TOOL would be that which
>it is easy for ME to go from "cool idea" to "robust, bug free,
>maintainable code"  I would rather spend my time solving complex
>algorithms and optomising for performance and memory then figuring out
>the minute little details of implementation.
>
>o If that language uses prefix notation, add to it an preprocessor that I
>can use infix notation in.
>o If that language uses header files, let the
>system find the prototypes and librarys it needs for me.
>o If that language allows me to stomp all over my memory it should tell
>me when I do so I can correct myself.
>o If my compiler is going to complain about the 100,000 problems caused
>by a missing '}' why can't it pause and ask me to put it in, then
>continue? or better yet, why can't it guess where it should go and try
>fixing my error?

You have a couple different issues here, but all of your points are
excellent.
1) I personally like pre/in/postfix languages, but then again I don't
have to write the compiler parser :^)

2) Auto-loading libraries is a pre-pre-processor issue, and a pretty
trivial one at that. But do you really *want* the compiler searching your
entire <> directory for an undeclared or undefined function that you
forgot to define? Doing development on the Mac, my <> directory is over a
meg (lots of toolbox headers, plus tons of custom libs). That's a lot of
text to parse. (Am I missing a better way to do this?)

3) Stomping all over memory is bad. Memory handling is one of the
thornier aspects of C/C++, but I don't really see any way 'round it.
After all, lame-o CS languages like Scheme don't have the faintest
concept of memory. This means they're useless for real world stuff like
writing device drivers. The nice thing about C/C++ is that they let you
do twisted things, but it's not the *easiest* or most *elegant* way. It
should be clear from your code when you're doing things you shouldn't.
Subtler problems (i.e. 1/5000hr bugs and slow leaks) are decidedly
non-trivial, and I don't really have a good solution. Of course, those
problems usually crop up in places where you *aren't* scrutinizing your
memory-handling, so maybe writing those segments in a functional language
first would produce clearer code. One good thing about functional
programming is that it virtually forces you to work without thinking
about memory.

4) Try a better compiler. Symantec has a configurable error limit (i.e.
stop after x number of errors). I assume CodeWarrior does too. (If you're
a DOS/Win/OS2 person, take a look at CW Platinum with the Icebreaker
Win/Win32 x86 cross-compiler and Metrowerks' plans for cross-compilation
for OS/2 on PPC and x86.) As far as AI for guessing where a '}' goes in
C/C++... you won't catch me working on it. Too nasty. A simpler language
like Scheme, maybe. But not C/C++. Bob only knows what the compiler might
produce.

>Um... Visual Basic (haven't used it myself) is seemingly taking over.
>Microsoft is really big into it.

Erm... not exactly a sterling recommendation, considering the sort of
bloatw... I mean software that Microsoft produces.

________________________________________________________________________
Jason Y. Sproul                 finger: jason@jsproul.buttb.wesleyan.edu
GCS/H/O                  http://www.con.wesleyan.edu/~jsproul/index.html
"Make it idiot proof and someone will make a better idiot." -fbmd@Mac

Jason Sproul <jsproul@wesleyan.edu> writes:

>2) Auto-loading libraries is a pre-pre-processor issue, and a pretty
>trivial one at that. But do you really *want* the compiler searching your
>entire <> directory for an undeclared or undefined function that you
>forgot to define? Doing development on the Mac, my <> directory is over a
>meg (lots of toolbox headers, plus tons of custom libs). That's a lot of
>text to parse. (Am I missing a better way to do this?)

Yup.  TCL provides autoloading of unidentified features by keeping an
index file in each system library dir.  The same could be done by
adding a utility to parse a new header file and add any prototypes
therein to the index.  If C went over to non-extern variables by
default, this parser could also add any exported variables.

>After all, lame-o CS languages like Scheme don't have the faintest
>concept of memory. This means they're useless for real world stuff like
>writing device drivers. The nice thing about C/C++ is that they let you

Actually, over at Carnegie Mellon, a group called (I think) the Fox
project has written a microkernel that benches equivalent to Mach
entirely in ML, which is a functional language.  I program in Scheme
on the Mac and on Unix, and have found it, when used with a compiler,
very suitable for applications programming.  Where it fails for systems
programming is more in that many scheme implementations don't have
good external object linkage, so you can't use all of the pre-written
system libraries.
In other words, such languages fail for system programming due to
trouble in linking them to an OS written in C and asm, not due to their
own flaws.
    Jim Wise
    wisej@acf4.nyu.edu

Jason Sproul <jsproul@wesleyan.edu> writes:

>4) Try a better compiler. Symantec has a configurable error limit (i.e.
>stop after x number of errors). I assume CodeWarrior does too. (If you're
>a DOS/Win/OS2 person, take a look at CW Platinum with the Icebreaker
>Win/Win32 x86 cross-compiler and Metrowerks' plans for cross-compilation
>for OS/2 on PPC and x86.) As far as AI for guessing where a '}' goes in
>C/C++... you won't catch me working on it. Too nasty. A simpler language
>like Scheme, maybe. But not C/C++. Bob only knows what the compiler might
>produce.

At a company that I worked for a few years ago, we developed an error
correcting parser that did a pretty good job of repairing problems
with too many (no not enough) braces.  We used the FMQ algorithm
in the back of "Crafting a Compiler" and just played with the
insertion and deletion costs until we got reasonable behavoir
for the most common programming errors.

>>....  It is imperative that software
>>languages are as easy to learn as possible....
>
>I and many others would argue that it is imperative that computer
>languages do the jobs they are designed for.

I agree
>
>>....  given the typical human
>>being hates to learn or do anything new.

Who is your audience?
Remember 20% of Americans are functionally illiterate = they can't
read and write.  Add to that the % of people who are computer illiterate.
Add to that the % of people who can/want to program.  Add to that the %
of programmers who you wouldn't want to hire.

My personal opinion is that the best programming TOOL would be that which
it is easy for ME to go from "cool idea" to "robust, bug free,
maintainable code"  I would rather spend my time solving complex
algorithms and optomising for performance and memory then figuring out
the minute little details of implementation.

o If that language uses prefix notation, add to it an preprocessor that I
can use infix notation in.
o If that language uses header files, let the
system find the prototypes and librarys it needs for me.
o If that language allows me to stomp all over my memory it should tell
me when I do so I can correct myself.
o If my compiler is going to complain about the 100,000 problems caused
by a missing '}' why can't it pause and ask me to put it in, then
continue? or better yet, why can't it guess where it should go and try
fixing my error?

>This is, of course, wrong.  If it were true, we would all still be using
>interpeted basic.  (My apologies to the basic crowd).  Many reasonable,

Um... Visual Basic (haven't used it myself) is seemingly taking over.
Microsoft is really big into it.

>>When someone says that X is too complex, then they are saying that
>>there is a better design that is less complex and of equivalent
>>functionality. Something that is more complex is harder to learn and
>>to use by programmer and thus is not as an efficient tool.

"From: steagall@WebSystems.Cleveland.OH.US (Bob Steagall)" Writes:

>Too complex for what? As efficient for what?  Any discussion of the effectiveness
>and/or efficiency of a given tool can only have meaning in the context of a task
>to which that tool is being applied.  If you cannot provide a frame of reference
>for discussion, then your comments are meaningless.  No reasonable person,
>on the comittee or otherwise, has ever maintained that C++ is the perfect
>programming language, applicable with equal facility and success to every problem
>domain.

I would say that within the same problem domains that we would use C++.
(General purpose imperitive languages)

>No argument here.  It goes without saying that you should pick the right tool for
>the job.  However, you might want to consider the possibility that simple tools
>are not always adequate for complicated tasks.

How about simpler tools that are more adequate for most every job.

>>One can find fault when they don't agree with design constaints or
<>philosophy.

>Then design your own language.  If one believes that C++ is fatally flawed
>and that another solution is superior, why bother complaining about C++?
>Why not just use the solution you believe to be superior and forget about
>C++?

You know the real world constraints that do not allow this. C++ is
now the proverbial 600 pound gorilla.  Don't get me wrong, the
statements above were "One could...".  I personally feel that C++ is
the most important achievement ever in Computer Software/Computer Science.
Not that it is so great, just that its better than the rest of the
garbage.

>As a theoretical matter, the ontological questions concerning the design
>constraints and philosophy of C++ are to a very great extent different than
>questions of the language's efficacy within its targeted problem domain(s).

Huh, are you saying that design constraints and philosophy have no bearing
on how efficient the created tool is to use?

>>They are not subjective.  Certain concepts and notations are
>>statistically easier or harder for human beings to learn given some
>>common background/education.   For example, "(5 * 4) + 1" is more
>>easily understood by people than (+ (*5 4) 1) given they have had
>>elementry school algebra.  Language features can promote or not
>>promote habits/errors if you look at programmers as a group.

>Citations?  You have made the claim, now show us the proof.  If you cannot
>provide or point the way to data from peer-reviewed journals or other similarly
>reliable sources, especially with respect to the effectiveness/efficiency of C++
>in specific problem domains as compared to other systems programming languages,
>then this is just so much hot air.

As you know there are no peer-reviewed journals with case studies
comparing different tools, otherwise there would not be these endless
arguments.  I attribute this to the pompous indifference of Computer
Science.  "CS is a Science! (Physics Envy) We must only strive for
the Grand Unified Theory of Computer Science!".  I quote Patterson
and Hennessy, "Computer Architecture":  "...From a more pessimistic
point of view if 90% of the ideas (CS arch ideas, generalizable to
all of CS) disappeared no one would notice.  One reason for this
could be called the "von Neumann syndrome",  By hoping to invent a
new model of computation that will revolutionize computing,
researchers are striving to become known as the Von Neumann of the
21st century.  Another reason of taste: researchers often select
problems that no one cares about.  Even if important problems are
selected and the solutions are demonstrated, the proposed solution
may be too expensive relative to their benefits....".  It would be
interesting if someone faked a reasonable (but not awesome) case
study of say a comparison of the software engineering efficiency
between C++, CLOS and Ada9X.   The faked study could be sent to
various journals to see the acceptance rate of the paper (the paper
of course would be pulled and a article written about acceptance
results).   I suspect that it would be very tough to get such a
paper accepted by any major CS journal.

Are you doubting that people learning computer languages will understand
standard infix  (that they were taught in school) quicker than post or
prefix?

>then this is just so much hot air.

You don't have proof either, so given your own rules you should shut
your mouth. PPhhhft... :-)=

>>....   Sure
>>there are bizarre individuals that think general relativity, quantam
>>mechanics and particle physics are intuitively obvious, but these
>>people are in the vast minority and thus are neglectible due to that
>>constructing software systems is a socialist endeavor where the
>>lowest common denominator rules.

>This pathetic and insulting statement is nothing more than poorly
>articulated rambling.  It lends no credibility whatsoever to the
>arguments you are failing to advance.

This pathetic and insulting statement is nothing more than poorly
articulated rambling.  It lends no credibility whatsoever to the
arguments you are failing to advance.

(More on this later)

>>....  It is imperative that software
>>languages are as easy to learn as possible....

>I and many others would argue that it is imperative that computer
>languages do the jobs they are designed for.

Their job is designed to allow the develop of software system as
efficiently as possible.  Ease of learning without negative
impacts on the power of the language are of course going to
be a win.  You may of course argue that it is impossible to make
a simpler/easier to learn language of roughly equal power.

>>....  given the typical human
>>being hates to learn or do anything new.

>On this matter you are only qualified to speak for yourself.

Its based on years of experience,  so I am confident it is true.
Yup, 99% of programmers are now are experts in C++ (they have had
what like 8+ years to learn it by now) I must only be seeing the %1
that are not.

>>....  The problem I see is when a
>>intuitively hard to understand notation becomes prevelant and a large
>>group of individuals become "idiot savants" in that notation with
>>almost a religious devotion to it.

>And yet, this 'problem' crops up in every engineering and scientific
>discipline.  Each has its own jargon, notation and symbolic means of
>conveying information that practioners from other disciplines find
>'non-intuitive'.  It is a fact of life.  Get over it.

Yeah, lets make our jargon/notation as stupidly as possible so we can
tell newbees, "Tough shit, I already paid my dues and you got to pay
your dues to be in our exclusive club".  It pretty sick when
individuals tie their self-worth to learning idiotically archane
knowledge.  I see many aspects of C in this category, but I see almost
no (unforced) aspects of C++ in this category.   In my view,
competent programmers should evaluate their tools.  Their opinion
of the goodness or badness of a particular language/tool should not
be connected (emotionally) in anyway to their mastery of that tool.

>>....  Thus, the only way to evaluate a
>>language is to observe how easily the newbees pick up and use the
>>language.

>This is, of course, wrong.  If it were true, we would all still be using
>interpeted basic.  (My apologies to the basic crowd).  Many reasonable,
>experienced and intelligent people believe that the way to evaluate a given
>software tool is to determine how well it performs the task for which it was
>designed, and compare the cost of using that tool to the effectiveness and
>cost of other tools designed for the same job. I will grant you that education
>in the proper use of a tool is part of its cost; however, it would be
>shortsighted to make educational costs the only consideration.

I am talking about tools with "equal" power that are simpler.
Interpeted BASIC is not of equal power.  It is practically impossible
to write good software systems in (old) BASIC, thus it is actually
harder to learn/use right than C++.  I reinterate (try to explain
better), the only fair way to evaluate a language is by tracking the
productivity of newbees from early learning to eventual mastery of
the langauge. It is not fair to take hard core LISP programmers that
do not know a lick of C++ and compare how fast they can do a project
in LISP versus how fast they could do it in C++ or visa-versa.
Also we need to look at the productivity of programmers who are less
than brilliant.

I think I will go back to this point because it is fundemental:

>>there are bizarre individuals that think general relativity, quantam
>>mechanics and particle physics are intuitively obvious, but these
>>people are in the vast minority and thus are neglectible due to that
>>constructing software systems is a socialist endeavor where the
>>lowest common denominator rules.

When a individual writes software that only he will maintain, then
the only thing we should care about is that he does so efficiently as
possible.  As soon as the program must be maintained by others the
program it becomes important that it communicates effectively how it
works and its structure.  Brilliant programmers can more quickly
understand complex less communicative programs.  Unfortunately, we
cannot yet clone brilliant programmers so we must deal with less than
brilliant programmers on large software projects.  I believe the most
efficient languages are ones that cater to the more average
programmer by steering him (controlling) to write better code,
preventing errors and eliminating programmer arguments by limiting
the number of ways of doing things.  This may be to some detriment of
the "brilliant", but unless they are lone wolf egomaniacs (who
shouldn't be programming in groups anyway) they will see the benefits of
some restriction for the greater good.  The problem I see with C++ is
that its design philosophy abhores "nannyism", assuming all
programmers are well educated and intelligent (which in my opinion is
farthest from the truth).  This will of course make it popular
because it will stroke the egos of the many humility-less
programmers.  But it will be less programming efficient to the
programming community as a whole than a more "nannyistic" language.

> insulting statement

Insulting? how about this:

I personally see the current software industry as massively
incompetent.  This is why C++ will not cause much of a productivity
boost anytime soon.  Computer Science which should be pointing the
way to proper software construction and properly educating their
students. Instead, in my opinion, they really don't care much about
teaching good software technique, discipline and knowledge.

Here are some brilliant opinions of students from top Computer Science
programs:

UC Berkeley graduate:
  I write code using low level pointer arithmetic so the COMPILER
  will run faster.

Stanford:
  Hey this compiler won't let me to do a (interprocedural) goto.

UCSB graduate:
  I don't want my compiler to have do those optimizations.
  (General optimizations,packing boolean vectors if requested,etc)


Programmers in my opinion need to be insulted, here is an error
message from my "dream compiler":

  The ZX6.11 Compiler has analyzed your code and found you to be an
incompetent programmer.  To prevent damage by your substandard
programming, your source code has been deleted and your account has
been removed from the system. I have emailed your supervisor and the
proper programming authorities of your incompetence.  Please complete
the necessary education and learn the discipline needed for
adequate programming.

Have a nice day.

login:_

--------------------
Jay

In article <D1JHJC.I0J@seas.ucla.edu> jaym@breeze.seas.ucla.edu (Jay M. Martin) writes:
>I personally see the current software industry as massively
>incompetent.

 How can such a comparison be made? With which industry
do you compare it and how? Surely it is a newer industry than say
bridge building, and is less "mature". But then, often bridges
cost more to build than planned, and sometimes fall down.

 Perhaps the situation differs between countries too.
I have worked with several teams and individuals in Australia
and have found them all to be varying between very good and excellent.
I've met quite a lot of mediocre COBOL programmers. And a few
C "hackers". But most of the C++ people I meet seem well above average
competency. (If only we got paid above average instead of below :-)

>This is why C++ will not cause much of a productivity
>boost anytime soon.

 I do not really understand this comment. As far as I
can see it _already has_.

 IMHO, the philosophy of C++ (and Bjarne) is not to be
presumptious enough to assume _we_ the designers of the language
actually know a hell of a lot more about how to design good code
than to provide convenience and functional power based on experience.

 Perhaps in 10 years the techniques which are most reliable
will be well enough known to "package" those idioms currently
required by C++ into language features.

 This is better, IMHO, than enforcing a style which
turns out not to be well suited to a particular problem domain,
or programmer.

 IMHO, the major achievment of C++ is to provide the mass
market with a programming language which for the first time
ever is not totally ham-strung or brain dead. (The closest
I came to doing commercial work in a decent language was PL/1,
and Turbo Pascal)

 There are other better languages. Funny thing is, I have
5 C++ compilers on my PC. And I think I have two versions of Basic
(which I never use). And I have half a dozen assemblers (which
I use when I absolutely have to, which is almost never these days).


--
        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 <D1LLz2.Bp@ucc.su.OZ.AU>,
maxtal@physics.su.OZ.AU (John Max Skaller) wrote:

>       There are other better languages. Funny thing is, I have
> 5 C++ compilers on my PC. And I think I have two versions of Basic
> (which I never use). And I have half a dozen assemblers (which
> I use when I absolutely have to, which is almost never these days).

Perhaps you should add some Pascal to your mix. ;-)

Vince
=====

In article <1994Dec21.183639.12947@molienergy.bc.ca> janr@molienergy.bc.ca (Jan Reimers) writes:
>
>What about
>
>template <class T> voif f(Base<T>&)
>Dervided d; //Derived is dervied from Base.
>f(d); // Not and "exact" match.
>So does c++ no longer support polymorphism when you use templates?

 This has been fixed, at least partly, but specifically
allowing Derived to Base pointer and reference conversions
to be deduced. (At San Diego).

 It is not clear to me at this time if that includes
Derived to Base conversion. I mean :

 template<class T> void g(Base<T>);
 g(d); //?

I guess this should work if, and only if, Derived --> Base rvalue
conversion is standard. Actually, the WP says it is, but only
because an extra conversion was added editorially without any
vote being taken. It is somewhat doubtful if this conversion
is standard, since I expect it to be mediated by calling
the Base copy constructor -- using the standard reference
conversion

 Derived& --> Base&

(which is written

 lvalue Derived --> lvalue Base

now, I think :-(

Such a conversion depends on the existence, accessibility,
and applicability of the copy constructor, as well as whether
a better match constructor might be found. That is:

 1) the copy construct might not exist
 2) it might be private
 3) it might take a non-const reference argument
 4) a constructor Base::Base(const Derived&)
  would be a better match

In other words, the Derived-->Base conversion ought not to be
standard.   Instead, ordinary overload resolution takes place
to select the appropriate conversion sequence.

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

>> No, this is not the point at all.  The point is this: the COMPLEXITY of a
>> given tool, in and of itself, is not sufficient reason to dismiss that tool
>> as being non-useful, impractical, and/or ineffective.  That is the only point
>> I am trying to make in the paragraph you reference.  I am attempting to refute
>> an argument of the form "X is a complex tool; therefore X is impractical,
>> ineffective and not useful."  This kind of argument is incorrect on the
>> face of it.  Yet, many of the posts bashing C++ have this logic at their core.

>When someone says that X is too complex, then they are saying that
>there is a better design that is less complex and of equivalent
>functionality. Something that is more complex is harder to learn and
>to use by programmer and thus is not as an efficient tool.

Too complex for what? As efficient for what?  Any discussion of the effectiveness
and/or efficiency of a given tool can only have meaning in the context of a task
to which that tool is being applied.  If you cannot provide a frame of reference
for discussion, then your comments are meaningless.  No reasonable person,
on the comittee or otherwise, has ever maintained that C++ is the perfect
programming language, applicable with equal facility and success to every problem
domain.


>.........     Thus it
>comes down to how much time/cost savings that can be obtained with a
>cleaner and simpler tool.

No argument here.  It goes without saying that you should pick the right tool for
the job.  However, you might want to consider the possibility that simple tools
are not always adequate for complicated tasks.


>> It is difficult for me to find fault with C++ because its desginers
>> are trying very hard to stay within their self-imposed design
>> constraints.

>One can find fault when they don't agree with design constaints or
>philosophy.

Then design your own language.  If one believes that C++ is fatally flawed
and that another solution is superior, why bother complaining about C++?
Why not just use the solution you believe to be superior and forget about
C++?

As a practical matter, the constraints and philosophy of C++ are fairly set
by now, and are unlikely to change significantly.  Protestations that C++
does not provide this or that feature, when that feature lies outside of
the language's (very) publicly stated feature set/design constraints/
philosophy, will prove to be futile, and deservedly so.

As a theoretical matter, the ontological questions concerning the design
constraints and philosophy of C++ are to a very great extent different than
questions of the language's efficacy within its targeted problem domain(s).


>> The properties of 'non-obvious-ness' or 'error-prone-ness' are entirely
>> subjective.  To speak of 'the bad habits it promotes' is unsupported rhetoric.
>> Bad habits are entirely personal.  The difficulty of reading and maintaining
>> code is a matter of opinion.  If the code is difficult to read, then more care
>> should have been taken in its composition.  The statements you have made in
>> this paragraph are so vague and tightly coupled with the subjective aspects of
>> programming as to preclude meaningful discussion.

>They are not subjective.  Certain concepts and notations are
>statistically easier or harder for human beings to learn given some
>common background/education.   For example, "(5 * 4) + 1" is more
>easily understood by people than (+ (*5 4) 1) given they have had
>elementry school algebra.  Language features can promote or not
>promote habits/errors if you look at programmers as a group.

Citations?  You have made the claim, now show us the proof.  If you cannot
provide or point the way to data from peer-reviewed journals or other similarly
reliable sources, especially with respect to the effectiveness/efficiency of C++
in specific problem domains as compared to other systems programming languages,
then this is just so much hot air.


>....   Sure
>there are bizarre individuals that think general relativity, quantam
>mechanics and particle physics are intuitively obvious, but these
>people are in the vast minority and thus are neglectible due to that
>constructing software systems is a socialist endeavor where the
>lowest common denominator rules.

This pathetic and insulting statement is nothing more than poorly
articulated rambling.  It lends no credibility whatsoever to the
arguments you are failing to advance.


>....  It is imperative that software
>languages are as easy to learn as possible....

I and many others would argue that it is imperative that computer
languages do the jobs they are designed for.


>....  given the typical human
>being hates to learn or do anything new.

On this matter you are only qualified to speak for yourself.


>....  The problem I see is when a
>intuitively hard to understand notation becomes prevelant and a large
>group of individuals become "idiot savants" in that notation with
>almost a religious devotion to it.

And yet, this 'problem' crops up in every engineering and scientific
discipline.  Each has its own jargon, notation and symbolic means of
conveying information that practioners from other disciplines find
'non-intuitive'.  It is a fact of life.  Get over it.


>....  Thus, the only way to evaluate a
>language is to observe how easily the newbees pick up and use the
>language.

This is, of course, wrong.  If it were true, we would all still be using
interpeted basic.  (My apologies to the basic crowd).  Many reasonable,
experienced and intelligent people believe that the way to evaluate a given
software tool is to determine how well it performs the task for which it was
designed, and compare the cost of using that tool to the effectiveness and
cost of other tools designed for the same job. I will grant you that education
in the proper use of a tool is part of its cost; however, it would be
shortsighted to make educational costs the only consideration.


>....  In summary, I believe that social software engineering
>questions about tools are testable by experiment and thus the
>answers can be established as facts.
>Jay

Fine.  Again, I challenge you to provide citations to peer-reviewed journals
where the 'facts' you refer to have been empirically established, especially
with respect to C++ and other languages intended for the systems programming
problem domain.

Bob

maxtal@physics.su.OZ.AU (John Max Skaller) writes:

> It is not clear to me at this time if that includes
>Derived to Base conversion. I mean :
>
> template<class T> void g(Base<T>);
> g(d); //?
>
>I guess this should work if, and only if, Derived --> Base rvalue
>conversion is standard. Actually, the WP says it is,

So in fact there isn't any doubt.

>but only
>because an extra conversion was added editorially without any
>vote being taken.

It doesn't really matter how the conversion was added, partly because
we *have* taken a vote to accept the September draft, but mostly
because the editor was right.

>It is somewhat doubtful if this conversion
>is standard, since I expect it to be mediated by calling
>the Base copy constructor

Well, John, your expectation is wrong.
The conversion is not mediated by calling the Base copy constructor.

[This post is all "IMHO".]

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

>> to understand notation becomes prevelant and a large
>> group of individuals become "idiot savants" in that notation with
>> almost a religious devotion to it.

>Ok, just for the record: Here is my justification for my rather
>aggressive comments on your article.  Being called an `idiot savant'
>(webster: ``a mentally defective person who exhibits exceptional skill
>or brilliance in some limited field'') really tops it off!  I'm really
>tempted to call certain language devotees ``mentally defective without
>any exceptional skills'' -- but I won't, since this would be rude.

Not "mentally defective without any exceptional skills", "Idiot
Savants" are individuals that are brilliant in one area, lets say
can do multiplication/addition of huge numbers instantaniously in
their heads but can't tie their shoes (like the "Rain Man").  A
"C Idiot Savant" can do puzzles in the C Puzzle book by glancing at
them.  He sees them as obvious and other who can't do them as
idiots.  The "Idiot" part comes when you give him some Ada or Scheme
and he finds it incomprehesible and has trouble learning it.  The
problem I see when programmers become wedded to the notation and
can't step back and think about how hard or easy it is for a newbee
to learn.  An example problem with C is that "=" is ":=" and "==" is
"=" in many other languages which causes learning problems.  I am
an admitted "idiot"(bigot) at LISP style languages being in the
Ada/Modula*/C++/Eiffel camp.  My justifications are as follows:

- Extreme philosphical belief in strongly typed languages for large
  projects. Have the belief that in large projects language
  excess flexiblity can sometimes be a curse.  (Program != Data),etc.
- Like Infix and statement syntax.
- Convinced that LISP/Functional family languages do not execute as
  fast as staticly typed imperitive languages (Too slow
  makes them useless for interesting apps).
- Doubt that some programming language (LISP) created in the 50's before
  the word "Software Engineering" was even coined is the "ultimate" language
  that is  so brilliant nothing will ever surpass it. The
  almost religious devotion to this syntax by certain over
  theoretic pinheads in Computer Science gives me suspicion
  to believe that they have never developed and maintained
  large systems over a long period of time using average programmers.
- See AI as worthless disgrace along with the rest of Computer Science
  which I see as theoretic mastibatorial joke.  (PHD student in
  CS talking here)  Has there been a "maintainable" program every
  written in LISP?  Or just programs so brilliant only PHD's can
  understand them. Heh, how do AI Researchers have any self-esteem at all?
  (Probably by having their own exclusive self congratulatory club)

Of course, if I got some data showing the software maintainance
superiority of LISP for run of the mill million line projects I would
probably change my toon.

>Seriously, I have my doubts about what you say in general and with
>your example in particular.  Mathematical notation from simple
>arithmetic over linear algebra to calculus is very informal by CS
>standards.  It was designed to be a means of communication between
>human beings.  The notation is full of asymmetries, ambiguities, and
>ad-hoc rules.  The only reason that `5 * 4 + 1' is `easier' for the
>average person is that precedence rules have been banged into their
>heads for years.  I also fail to see why infix notation should be so
>much easier to read and write than prefix or postfix.  Fully
>parenthesized prefix notation as found in Lisp-like languages works
>well for an arbitrary number of possible operators, the programmer
>doesn't need to remember an arbitrarily chosen hierarchy of level of
>precedence (witness C), and full parenthesization allows for operators
>with a variable number of arguments.
>It takes only very little time to get used to those conventions, and
>once you got used to them they are in fact easier to remember and more
>general.
>We should not pay attention to elementary school legacy when designing
>programming languages.  Programming is a very difficult and
>intellectually challenging task, and if somebody can't understand
>prefix notation, then he or she has no business writing programs in
>the first place.  At least this is my (not so humble) opinion.

Yup, throw away all your mathematical infix notation intuition
because some morons thinks it neat to use post or prefix.  We must
forget all previous knowledge so that we can be accepted into the
cult!   Sorry if you want to communicate with me write your equations
in infix (unless of course everyone decides to go to pre/postfix,
thank goodness they are not!)  Maybe we should teach only pre/postfix
in elementary school so that they will like LISP.

>It was designed to be a means of communication between
>human beings.

Programming languages are "designed to be a means of communication
between human beings".

>the programmer
>doesn't need to remember an arbitrarily chosen hierarchy of level of
>precedence (witness C), and full parenthesization allows for operators
>with a variable number of arguments.

Can't take one notationally flawed infix language and condemn all
infix languages.  A good design is one that mimics as best as
possible standard mathematical operator precedences.

Am about to hear, "Due to that all imperitive language programs must use
tons of global variables, functional programming languages...."?

> but these
> people are in the vast minority and thus are neglectible due to that
> constructing software systems is a socialist endeavor where the
> lowest common denominator rules.

>>All socialist endeavors in the real world have been failures.  Maybe
>>we should make sure that constructing software systems is NOT a
>>socialist endeavor!

Typical right wing response. How about Sweden? Probably against
(US) universal health care too.  Have you ever developed a large software
project (million lines)?  Large Project software development suffers
from the "problem of the commons" where if you let all the
programmers run rampant then the project collapses.  Why? because
what they are doing is exceedingly connected.  I not saying that all
creativity should sucked out of programming, just the low level
"creativity" that doesn't really matter (Duh, I got the "RIGHT" to
write artistic hard-to-read one-liners and use lots of pointer
arithmetic!)   Maybe want we need is bounty hunters like in the old
west.  If a programmer writes shit code (due to incompetence,laziness
or don't give a fuck about the next guy), then someone is hired to
track down the programmer and kill him.  Unfortunately, in my opinion
90% of programmers would probably have to die.  To me it is an insult
when I read shit code.

> It is imperative that software
> languages are as easy to learn as possible given the typical human
> being hates to learn or do anything new.

>>Ok, let's close all schools!  I think that a typical human being
>>should be eager to learn new things.  If this is not the case, then he
>>or she should be fired at once.  Let's not be merciful with people who
>>don't want to learn!

Obviously hasn't worked in the real world.  People in my opinion
learn new stuff only when a gun is put to their head.  A few months ago
people in our software/programming language research group was asked
if they knew C++, guess how many knew something?  Zero (besides me).

>>   In summary, I believe that social software engineering
>>   questions about tools are testable by experiment and thus the
>>   answers can be established as facts.

>Your beliefs are not being shared by all of us...

Huh? What are you saying? That tool efficiency is not testable?
(Probably just making a snide remark)

Jay

In article <3d4kt1$9vi@hermes.synopsys.com>, jbuck@synopsys.com (Joe Buck) wrote:

> One thing that concerns me most is the lack of perspective about
> programming in the large -- the concerns that bite when you're doing
> a project with many programmers and on the order of a million lines
> of code.  I've *repeatedly* seen messages from committee members saying
> that the recompilation cascades that hit when you need to change a header
> file aren't a problem except to those with slow machines, clearly
> indicating that such people have never done a large project.  There
> are workarounds, to be sure; many of them involve doing O-O the C way,
> with opaque structs; which are now opaque classes, as in
>
> class ImportantObject {
> private:
>       class ImportantObjectImplementation& impl;
> public:
>       // public methods here
>       ...
>       // private stuff in ImportantObjectImplementation class
> };
>
> and this certainly helps.  But a module system would have helped much
> more.  While it's too late for this now, I'd at least like to see more
> acknowledgement that this is a problem.  While some might argue that the
> problem is really with the traditional Unix preprocess-compile-link view
> of things and that implementers can do better, this suggests that we need
> to be looking into what barriers the language imposes to more complicated
> implementations.

Hear! Hear! It would be great if this problem was acknowledged.

Vince
=====

In article <DAG.94Dec17191236@bellman.control.lth.se> dag@control.lth.se (Dag Bruck) writes:
>>>>>> "TMB" == Thomas M Breuel <tmb@arolla.idiap.ch> writes:
>
>TMB> It appears pretty clear to me that the experience,
>TMB> application domains, and constraints under which committee
>TMB> members use C++ are very different from those of the majority of
>TMB> C++ users outside the committee.
>
>Could you please elaborate a little?  As a committee member I would be
>interested in knowing about such differences, in particular in areas
>where our biases would not serve the larger C++ community.
>
>     -- Dag Bruck

 Well, Dag, Kent Budge, and myself can be classified as
working C++ programmers. On the other hand many compiler vendors
are writing their compilers in C, not C++, and do not have
the experience first hand that users have.
Nor do commercial programmers have the experience an academic
programmer would have.

Compiler vendors may well have, on the other hand, extensive contact with
their more vocal client base.  Similarly, library vendors are used
to providing libraries that work with the lowest common denominator
compilers.

 And that rare breed, the conformance tester, will have
a different view again.

 I have no hesitation in both supporting the assertion
that the C++ committee does not represent the wishes of the
vast majority of programmers and saying it is a Good Thing (tm)
that this is so.

 Because, we, as C++ programmers,
need compilers, libraries, tools, and conformance testing
just as vendors of these services need clients.

--
        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 <D1524C.7KA@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <3cv6dd$qa7@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (Satish Thatte) writes:
>>From article <D0v1Iv.LtA@ucc.su.OZ.AU>, by maxtal@physics.su.OZ.AU (John Max Skaller):
> The ARM has an incomplete, and fairly incomprehensible
>notion of "trivial conversions" for things like int-->int const,
>int& --> int, and it had template rules requiring exact matches
>so that
>
> template<class T> void f(T);
> int a;
> int const b;
> int& c;
> int const & d;
> f(a); // f(int)
> f(b); // f(int const)
> f(c); // f(int&);
> f(d); // f(int const&)
>
>This is _really_ bad news. It makes template functions
>almost unusable. What happens if you write

What about

template <class T> voif f(Base<T>&)

Dervided d; //Derived is dervied from Base.

f(d); // Not and "exact" match.

So does c++ no longer support polymorphism when you use templates?


################################

        Jan N. Reimers
      Research Scientist
    Moli Energy (1990) Ltd.
     Tel:   (604)-465-7911
     FAX:   (604)-465-4398
  email: janr@molienergy.bc.ca

################################

--
janr@molienergy.bc.ca

In article <D14woL.GpG@ucc.su.OZ.AU> I wrote:
>
> Thank you. Most members of the committee and Bjarne himself
>are well aware of the difficulties, and there is a phrase coined
>by Bjarne
>
> "As close to C as possible but no closer"

 -- and Andrew Koenig tells me he accepts the blame for that one.

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

>>>>> "JB" == Joe Buck <jbuck@synopsys.com> writes:

JB> dag@control.lth.se (Dag Bruck) writes:
>> Could you please elaborate a little?  As a committee member I would
>> be interested in knowing about such differences, in particular in
>> areas where our biases would not serve the larger C++ community.

JB> Application domains: compiler implementers are far more common on
JB> the committee than off it.  Scientific users are underrepresented
JB> and their concerns are often not well understood ...

I regard myself as a representative for the engineering community, and
I think we have been well treated in the committee.  You can of course
argue that _I_ should have worked harder on behalf of the entire
community, but that is not a fault of the committee or its
organization.

If you look at actual use of C++, my impression is that the
engineering community has been provided with lots of support
(different number formats, complex type, numeric array), compared to
other potentially large user groups.  Where is the database support?

JB> ...  There are workarounds, to be sure;
JB> many of them involve doing O-O the C way, with opaque structs;
JB> which are now opaque classes.

While I agree that programming in the large is important, I don't
agree with your example.  I think opaque datatypes is a question of
encapsulation, which is orthogonal to "OO vs. non-OO."  Yes, writing
forwarding functions is a major inconvenience, and yes, abstract
classes may not be great either.

JB> ... the problem is really with the traditional Unix
JB> preprocess-compile-link view of things and that implementers can
JB> do better, this suggests that we need to be looking into what
JB> barriers the language imposes to more complicated implementations.

My impression is that the implementors are quite concerned and keep
their eyes open.

      -- Dag Bruck

I wrote:
>JB> ...  There are workarounds, to be sure;
>JB> many of them involve doing O-O the C way, with opaque structs;
>JB> which are now opaque classes.

dag@control.lth.se (Dag Bruck) writes:
>While I agree that programming in the large is important, I don't
>agree with your example.  I think opaque datatypes is a question of
>encapsulation, which is orthogonal to "OO vs. non-OO."  Yes, writing
>forwarding functions is a major inconvenience, and yes, abstract
>classes may not be great either.

I think you missed my point, Dag.

I don't want to write opaque classes in C++.  I find that I must because
otherwise, I spend so much time in development recompiling hundreds of
files for each minor change in an include file that development can't
proceed.  The exclusive reason for using incomplete class types is so that
class Foo can use class Bar without everything that references Foo.h being
dependent on Bar.h as well.  Once this is multiplied by about 500 header
files, things start getting bad, and 500 headers isn't even that large a
program.
--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

In article <3d4kt1$9vi@hermes.synopsys.com>, Joe Buck (jbuck@synopsys.com) writes:
>
>"TMB" == Thomas M Breuel <tmb@arolla.idiap.ch> writes:
>>TMB> It appears pretty clear to me that the experience,
>>TMB> application domains, and constraints under which committee
>>TMB> members use C++ are very different from those of the majority of
>>TMB> C++ users outside the committee.
>
>dag@control.lth.se (Dag Bruck) writes:
>>Could you please elaborate a little?  As a committee member I would be
>>interested in knowing about such differences, in particular in areas
>>where our biases would not serve the larger C++ community.
>
>Experience: the committee members understand the fine points of C++ far
>better than the majority of users.  They are more willing to put up with
>complexity as the use for each of the many features is more clear.

That may be true, but would you really want a standards committee
full of people who don't understand the fine points of the language
they are standardizing?

>Application domains: compiler implementers are far more common on the
>committee than off it.

Don't be misled by the corporate affiliations of committee
members.  Committee members personal viewpoints seem to be the
driving force, and many or perhaps most members have a very
user-oriented viewpoint.  Committee members who work for compiler
vendors seem to have wide contact with many users, and often
strongly argue the user point of view.

> Scientific users are underrepresented and their
>concerns are often not well understood (otherwise more effort would have
>been made to coordinate with the committee working on numerical extensions
>to C, for example, and perhaps the exponentiation operator would have
>been accepted).

Well, how much is enough?  The committee has members from important
scientific labs, and from vendors like Cray who are traditionally
considered scientifically oriented.  These members have had
important proposals accepted, including the entire Numerics library
chapter, which are of little interest to anyone except scientific
users. Sure, not all scientifically oriented proposals have been
accepted, but a number have been accepted.

>One thing that concerns me most is the lack of perspective about
>programming in the large -- the concerns that bite when you're doing
>a project with many programmers and on the order of a million lines
>of code.  I've *repeatedly* seen messages from committee members saying
>that the recompilation cascades that hit when you need to change a header
>file aren't a problem except to those with slow machines, clearly
>indicating that such people have never done a large project.

Hum, I must have missed those messages.  And while some members are
concerned with small programs, others represent the largest
organizations in the world and are very concerned with very large
projects.  The last few meetings, for example, both working group
and full committee time has been expended on template compilation
issues because of just the concerns you are talking about.

>There
>are workarounds, to be sure; many of them involve doing O-O the C way,
>with opaque structs; which are now opaque classes, as in
>
>class ImportantObject {
>private:
>       class ImportantObjectImplementation& impl;
>public:
>       // public methods here
>       ...
>       // private stuff in ImportantObjectImplementation class
>};
>
>and this certainly helps.  But a module system would have helped much
>more.  While it's too late for this now, I'd at least like to see more
>acknowledgement that this is a problem.  While some might argue that the
>problem is really with the traditional Unix preprocess-compile-link view
>of things and that implementers can do better, this suggests that we need
>to be looking into what barriers the language imposes to more complicated
>implementations.

Particularly during the last year there has been extensive committee
discussion (mostly on the email reflectors the committee uses for
informal discussions) of how wonderful a module system would be. But
there seemed to be as many different ideas as to what a module
system was as there were people sending messages. And no formal
proposals were put forward with wide support.  So a module system
will have to wait until the next revision in the standard, assuming
someone comes forward with such a system in the meantime.

-- Beman    (beman@dawes.win.net)

In article <BLUME.94Dec19101805@dynamic.cs.princeton.edu>,
Matthias Blume <blume@dynamic.cs.princeton.edu> wrote:
>In article <3d2ujh$ni9@oahu.cs.ucla.edu> jmartin@oahu.cs.ucla.edu (Jay Martin) writes:
>
>   In summary, I believe that social software engineering
>   questions about tools are testable by experiment and thus the
>   answers can be established as facts.
>
>Your beliefs are not being shared by all of us...

I happen to agree with Mr. Martin.

As soon as one programmer starts to work on another programmer's code,
the act of programming becomes a `social' endeavor.  (I would not have
used the word `socialist', but that's just a minor quibble.)

To assert (as it seems Mr. Blume is doing) that the scientific method
cannot be applied to obtain concrete empirical evidence regarding the
efficacy (or other attributes) of such social interactions would be
tantamount to postulating the existance of a sort of `Heisenberg
uncertainty principal' (which shrouds all aspects of the study of
human psychology in an impenetrable blanket of eternal mystery)
without providing any basis for such a claim.

The empirical study of the value (or lack thereof) of various features
of programming languages... especially in the context of multi-person
projects... is something that _can_ be done, even if language designers
have (to date) chosen to rely more on their own (falable) instincts in
preference to empirical results.

I seriously expect that C++ will be the last widely used language to be
designed in this manner.  The costs of mistakes, as evidenced by the
recent Pemtium incident, is just becomming too high for the software
and/or hardware industries to continue to place such a heavy reliance
on ad-hoc methods and personal intuition.

--

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

In article <3d2ujh$ni9@oahu.cs.ucla.edu> jmartin@oahu.cs.ucla.edu (Jay Martin) writes:

   Certain concepts and notations are
   statistically easier or harder for human beings to learn given some
   common background/education.   For example, "(5 * 4) + 1" is more
   easily understood by people than (+ (*5 4) 1) given they have had
   elementry school algebra.

Indeed, it seems to be very hard:  It must be (+ (* 5 4) 1), of course! :)

Seriously, I have my doubts about what you say in general and with
your example in particular.  Mathematical notation from simple
arithmetic over linear algebra to calculus is very informal by CS
standards.  It was designed to be a means of communication between
human beings.  The notation is full of asymmetries, ambiguities, and
ad-hoc rules.  The only reason that `5 * 4 + 1' is `easier' for the
average person is that precedence rules have been banged into their
heads for years.  I also fail to see why infix notation should be so
much easier to read and write than prefix or postfix.  Fully
parenthesized prefix notation as found in Lisp-like languages works
well for an arbitrary number of possible operators, the programmer
doesn't need to remember an arbitrarily chosen hierarchy of level of
precedence (witness C), and full parenthesization allows for operators
with a variable number of arguments.
It takes only very little time to get used to those conventions, and
once you got used to them they are in fact easier to remember and more
general.
We should not pay attention to elementary school legacy when designing
programming languages.  Programming is a very difficult and
intellectually challenging task, and if somebody can't understand
prefix notation, then he or she has no business writing programs in
the first place.  At least this is my (not so humble) opinion.

   Sure
   there are bizarre individuals that think general relativity, quantam
   mechanics and particle physics are intuitively obvious,

This is the most pathetic and misleading comparison I have seen in a
long time!  Prefix notation is at the same level of intellectual
complexity as quantum mechanics!?!  Ha!  Let's be serious, please.

   but these
   people are in the vast minority and thus are neglectible due to that
   constructing software systems is a socialist endeavor where the
   lowest common denominator rules.

All socialist endeavors in the real world have been failures.  Maybe
we should make sure that constructing software systems is NOT a
socialist endeavor!

   It is imperative that software
   languages are as easy to learn as possible given the typical human
   being hates to learn or do anything new.

Ok, let's close all schools!  I think that a typical human being
should be eager to learn new things.  If this is not the case, then he
or she should be fired at once.  Let's not be merciful with people who
don't want to learn!

   The problem I see is when a intuitively hard

Are you referring to prefix notation once again?  Don't make me laugh!

   to understand notation becomes prevelant and a large
   group of individuals become "idiot savants" in that notation with
   almost a religious devotion to it.

Ok, just for the record: Here is my justification for my rather
aggressive comments on your article.  Being called an `idiot savant'
(webster: ``a mentally defective person who exhibits exceptional skill
or brilliance in some limited field'') really tops it off!  I'm really
tempted to call certain language devotees ``mentally defective without
any exceptional skills'' -- but I won't, since this would be rude.

   In summary, I believe that social software engineering
   questions about tools are testable by experiment and thus the
   answers can be established as facts.

Your beliefs are not being shared by all of us...

--
-Matthias

"TMB" == Thomas M Breuel <tmb@arolla.idiap.ch> writes:
>TMB> It appears pretty clear to me that the experience,
>TMB> application domains, and constraints under which committee
>TMB> members use C++ are very different from those of the majority of
>TMB> C++ users outside the committee.

dag@control.lth.se (Dag Bruck) writes:
>Could you please elaborate a little?  As a committee member I would be
>interested in knowing about such differences, in particular in areas
>where our biases would not serve the larger C++ community.

Experience: the committee members understand the fine points of C++ far
better than the majority of users.  They are more willing to put up with
complexity as the use for each of the many features is more clear.

Application domains: compiler implementers are far more common on the
committee than off it.  Scientific users are underrepresented and their
concerns are often not well understood (otherwise more effort would have
been made to coordinate with the committee working on numerical extensions
to C, for example, and perhaps the exponentiation operator would have
been accepted).

One thing that concerns me most is the lack of perspective about
programming in the large -- the concerns that bite when you're doing
a project with many programmers and on the order of a million lines
of code.  I've *repeatedly* seen messages from committee members saying
that the recompilation cascades that hit when you need to change a header
file aren't a problem except to those with slow machines, clearly
indicating that such people have never done a large project.  There
are workarounds, to be sure; many of them involve doing O-O the C way,
with opaque structs; which are now opaque classes, as in

class ImportantObject {
private:
 class ImportantObjectImplementation& impl;
public:
 // public methods here
 ...
 // private stuff in ImportantObjectImplementation class
};

and this certainly helps.  But a module system would have helped much
more.  While it's too late for this now, I'd at least like to see more
acknowledgement that this is a problem.  While some might argue that the
problem is really with the traditional Unix preprocess-compile-link view
of things and that implementers can do better, this suggests that we need
to be looking into what barriers the language imposes to more complicated
implementations.


--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Phone: +1 415 694 1729

In article <3cv6dd$qa7@library.erc.clarkson.edu> satish@sun.mcs.clarkson.edu (Satish Thatte) writes:
>From article <D0v1Iv.LtA@ucc.su.OZ.AU>, by maxtal@physics.su.OZ.AU (John Max Skaller):
>>
>> Introducing references is necessary for overloaded operators,
>> and they foul up they type system because they are not
>> really "types". (This is one of the most serious problems,
>> because it couples very strongly to templates)
>
>Could you explain this a little further please?

 Sure.

>What is the connection with templates?

 Templates are parameterised by types.

 In the ARM, the types int&, int const and int exist,
and one can overload on them:

 f(int);
 f(int const);
 int x;
 int const x2;
 f(x); // calls f(int)
 f(x2); // calls f(int const)

This is not allowed in ISO C, and it seems clear it is a silly
idea -- the "const" in the "int const" parameter has nothing
to do with the interface of the function, but is part of the
implementation details of the function -- the local parameter
is not modified by the function.

 The ARM has an incomplete, and fairly incomprehensible
notion of "trivial conversions" for things like int-->int const,
int& --> int, and it had template rules requiring exact matches
so that

 template<class T> void f(T);
 int a;
 int const b;
 int& c;
 int const & d;
 f(a); // f(int)
 f(b); // f(int const)
 f(c); // f(int&);
 f(d); // f(int const&)

This is _really_ bad news. It makes template functions
almost unusable. What happens if you write

 template<class T> void g(const T&);
 g(a); // error
 g(b); // error
 g(c); // error
 g(d); // works

This is, well, crap. (no offense). All the calls should work.
Now, the committee has taken some steps to fix these problems:

 a) f(int) and f(const int) declare the same function
 b) there are no expressions of reference type
 c) the exact match requirement is weakened
 d) the trivial conversions have been eliminated
 e) uncallable instances are excluded from overload resolution
 f) const CI, where typedef const int CI; is permitted
 g) member functions can be called on rvalues which
    have qualified types, ordinary parameters may not
 h) constructors are non-const

Unfortunately, these resolutions were taken ad hoc and not
in conformance with a coherent type model. And so while the
ARM at least had an almost coherent type model which was barely
usable, what we have now is incoherent, and while many cases
appear to work better, there are many which are even more
inconsistent than before. For example

 template<class T> void f(T a) { T b; }
 int x;
 int const y;
 f(x); // ????????
 f(y); // ????????


What happens here? If "const int" is really a type,
then there are TWO template instances:

 void f(int a) { int b; }
 void f(int const a) { int const b; }

and because these two declarations declare the same function,
but there are two definitions, then we have an unavoidable breach
of program coherence (I.e the ODR).

Even if type deduction does not permit "const" types to be deduced
like this, there is always the new explicit form:

 f<int>(x);
 f<int const>(x);

I personally believe there is no such thing as a const type.
Note in this case that

 f<int &>(..) // error!

because the expansion leads to

 void f(int& a) { int &b; } // error: reference needs initialiser

but that is an accident. There are cases where instead the
code compiles and completely different semantics are silently
provided. Of course there are examples of complete rubbish:

 template<class T> void h() { T const a=0; }
 h<int const>(); // --> int const const a?? (allowed)
 h<int const&>(); // --> int const & const a?? (not allowed)

This is just one example of how the idea that "int const" is a type
leads to problems. ISO C, by the way, has no such rvalue type:
it correctly says that constness is an attribute of lvalues only,
that is, of the "address" of an object, but not its value.

These kind of problems are magified in templates and when
various dependent facilities are used together. In order to
get orthogonality the basic notions need to be exactly right
or we will need huge wads of special cases -- which will
turn out to be more or less equivalent to getting the type
system right in the first place.

--
        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 <steagall.4.000E0D76@WebSystems.Cleveland.OH.US> steagall@WebSystems.Cleveland.OH.US (Bob Steagall) writes:
>
>That may or may not be true.  I cannot speak to what is a 'better' way of
>expressing the relationships you mention.  However, the designers of C++
>set out to create a language with a great deal of backward compatibility with
>C.  This was a design goal/constraint (depending on your point of view :-).
>The reasons for doing so are well documented.  It is difficult for me to find
>fault with C++ because its desginers are trying very hard to stay within their
>self-imposed design constraints.

 Thank you. Most members of the committee and Bjarne himself
are well aware of the difficulties, and there is a phrase coined
by Bjarne

 "As close to C as possible but no closer"

which expresses the C++ philosophy -- although it is not
always clear exactly what is "as close as possible" but still
workable. By default, restrictions imposed by C are accepted
unless there is a very strong argument to change it -- for example
nested classes really nest, which they do not in C.

>The properties of 'non-obvious-ness' or 'error-prone-ness' are entirely
>subjective.  To speak of 'the bad habits it promotes' is unsupported rhetoric.
>Bad habits are entirely personal.  The difficulty of reading and maintaining
>code is a matter of opinion.

 I don't really agree with that. This kind of thing is
very hard to quantify and discuss but I do not believe it is
"entirely" a matter of opinion: there could be both statistical
evidence and sound reasons based on psychology why certain
things are "good" or "bad" in a programming language.
One can, for example, compute various metrics and compare them
with bug rates or project failures. It may be hard to be sure
what this means, but that does not mean such data is entirely
meaningless.

--
        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 <D15w9M.IK3@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
> In article <D14woL.GpG@ucc.su.OZ.AU> I wrote:

> > Thank you. Most members of the committee and Bjarne himself
> >are well aware of the difficulties, and there is a phrase coined
> >by Bjarne

> > "As close to C as possible but no closer"

>  -- and Andrew Koenig tells me he accepts the blame for that one.

Yeah, but I got it from Albert Einstein.  If you're going to
steal ideas, be sure it's from someone worth stealing from :-)
--
    --Andrew Koenig
      ark@research.att.com

>>>>> "TMB" == Thomas M Breuel <tmb@arolla.idiap.ch> writes:

TMB> It appears pretty clear to me that the experience,
TMB> application domains, and constraints under which committee
TMB> members use C++ are very different from those of the majority of
TMB> C++ users outside the committee.

Could you please elaborate a little?  As a committee member I would be
interested in knowing about such differences, in particular in areas
where our biases would not serve the larger C++ community.

     -- Dag Bruck

In article <steagall.3.000E322F@WebSystems.Cleveland.OH.US> steagall@WebSystems.Cleveland.OH.US (Bob Steagall) writes:
|The language designers seem to be taking great pains to learn from the
|practical experience of the committee members.  This is a logical approach.
|Many of the language features people have wished for have received
|due consideration by the language designers and have been discarded.
|None of these proposals have been denied arbitrarily.

That depends.  It appears pretty clear to me that the experience,
application domains, and constraints under which committee members use
C++ are very different from those of the majority of C++ users outside
the committee.  Therefore, what you seem to view as an advantage,
namely that C++ is based on the experience of the committee members, I
would view as a disadvantage and problem of the standardization
process (in fact, this seems to be a common problem with language
standardization committees in general).

    Thomas.

> No, this is not the point at all.  The point is this: the COMPLEXITY of a
> given tool, in and of itself, is not sufficient reason to dismiss that tool
> as being non-useful, impractical, and/or ineffective.  That is the only point
> I am trying to make in the paragraph you reference.  I am attempting to refute
> an argument of the form "X is a complex tool; therefore X is impractical,
> ineffective and not useful."  This kind of argument is incorrect on the
> face of it.  Yet, many of the posts bashing C++ have this logic at their core.

When someone says that X is too complex, then they are saying that
there is a better design that is less complex and of equivalent
functionality.  Something that is more complex is harder to learn and
to use by programmer and thus is not as an efficient tool.   Thus it
comes down to how much time/cost savings that can be obtained with a
cleaner and simpler tool.

> It is difficult for me to find fault with C++ because its desginers
> are trying very hard to stay within their self-imposed design
> constraints.

One can find fault when they don't agree with design constaints or
philosophy.

> The properties of 'non-obvious-ness' or 'error-prone-ness' are entirely
> subjective.  To speak of 'the bad habits it promotes' is unsupported rhetoric.
> Bad habits are entirely personal.  The difficulty of reading and maintaining
> code is a matter of opinion.  If the code is difficult to read, then more care
> should have been taken in its composition.  The statements you have made in
> this paragraph are so vague and tightly coupled with the subjective aspects of
> programming as to preclude meaningful discussion.

They are not subjective.  Certain concepts and notations are
statistically easier or harder for human beings to learn given some
common background/education.   For example, "(5 * 4) + 1" is more
easily understood by people than (+ (*5 4) 1) given they have had
elementry school algebra.  Language features can promote or not
promote habits/errors if you look at programmers as a group.  Sure
there are bizarre individuals that think general relativity, quantam
mechanics and particle physics are intuitively obvious, but these
people are in the vast minority and thus are neglectible due to that
constructing software systems is a socialist endeavor where the
lowest common denominator rules.  It is imperative that software
languages are as easy to learn as possible given the typical human
being hates to learn or do anything new.  The problem I see is when a
intuitively hard to understand notation becomes prevelant and a large
group of individuals become "idiot savants" in that notation with
almost a religious devotion to it.   Thus, the only way to evaluate a
language is to observe how easily the newbees pick up and use the
language. In summary, I believe that social software engineering
questions about tools are testable by experiment and thus the
answers can be established as facts.
Jay

In article <1994Dec14.231316.15695@cae.ca> dak@cae.ca (Pierre Baillargeon) writes:
>From: dak@cae.ca (Pierre Baillargeon)
>Subject: Re: Bjarne's Defence of C++
>Date: Wed, 14 Dec 1994 23:13:16 GMT

>Bob Steagall (steagall@WebSystems.Cleveland.OH.US) wrote:
>: In article <3ck71v$5ij@explorer.clark.net> thutt@clark.net (Taylor Hutt) writes:

>: >Meaningless text bite.  Citations?  How does driving a car compare to
>: >programming in C++?  Let's compare languages to langauges and cost of
>: >delivering software -- then you can deterimine with tangible evidence
>: >what is good and bad.

>: Fine.  Please provide us with some documented anecdotal evidence or
>: data cited from journals.  In the absence of such information in this thread
>: of discussion, the introduction of a metaphor to illustrate this point is
>: perfectly valid.

>: To generalize the metaphor: many reasonably clever and experienced people
>: fail to learn all kinds things.  This does not imply that these things are
>: somehow 'defective' or 'too complex'.  As graduate student in physics, I did
>: very well in quantum mechanics, classical mechanincs and electrodynamics.
>: But I just could not get the hang of statistical mechanics.  About half of my
>: classmates felt the same as I.  Does this mean that stat mech is 'too complex'
>: and should thus be discarded as a tool for the practicing physicist?  Of
>: course not.

>I am not sure this metaphor is better.  Your point seems to be that in order
>for a language to be useful, practical and effective it must be complex.

No, this is not the point at all.  The point is this: the COMPLEXITY of a
given tool, in and of itself, is not sufficient reason to dismiss that tool
as being non-useful, impractical, and/or ineffective.  That is the only point
I am trying to make in the paragraph you reference.  I am attempting to refute
an argument of the form "X is a complex tool; therefore X is impractical,
ineffective and not useful."  This kind of argument is incorrect on the
face of it.  Yet, many of the posts bashing C++ have this logic at their core.

>... The
>C++ complexities does not lie solely on the concepts but more generally on
>the chosen syntax and behaviors.  A more straight-forward relationship
>between virtuality, inheritance, encapsulation and polymorphism might
>have been better expressed than by always using the same keywords and
>keeping the C tradition of using ponctuation for everything.

That may or may not be true.  I cannot speak to what is a 'better' way of
expressing the relationships you mention.  However, the designers of C++
set out to create a language with a great deal of backward compatibility with
C.  This was a design goal/constraint (depending on your point of view :-).
The reasons for doing so are well documented.  It is difficult for me to find
fault with C++ because its desginers are trying very hard to stay within their
self-imposed design constraints.

>The fact that people argue that it is non-obvious and error-prone (not to
>talk about the bad habits it promotes) is what is criticized here I believe.
>If it's hard to read and maintain, then its a pain to use.  If you after years
>you still can get mixed up and not being sure of behavior, there's a real
>problem.

The properties of 'non-obvious-ness' or 'error-prone-ness' are entirely
subjective.  To speak of 'the bad habits it promotes' is unsupported rhetoric.
Bad habits are entirely personal.  The difficulty of reading and maintaining
code is a matter of opinion.  If the code is difficult to read, then more care
should have been taken in its composition.  The statements you have made in
this paragraph are so vague and tightly coupled with the subjective aspects of
programming as to preclude meaningful discussion.

Bob

In article <3ck71v$5ij@explorer.clark.net> thutt@clark.net (Taylor Hutt) writes:

[deletion]

>>I agree with you: if you pick a problem and then hunt around for the
>>language you think solves it best, that language will probably not be
>>C++ -- expecially if you've decided you don't like C++ and pick your
>>problems on that basis.  The strength of C++ is not that it is the best
>>language for any particular thing, but rather that it is more than
>>adequate for a very wide range of applications.

>Is this supposed to comfort people who are using C++?  Unfortunately,
>being second best seems to be a widespread attitude in the US: it may not
>be the best, but it works nearly as well as the leading brand.

Perhaps you could provide some citations to support the baseless assertions
made in this paragraph.  This combination red herring/ad hominum does not
advance the discussion.

[deletion]

>>It takes about as long to learn C++ as it does to learn to drive a car.
>>Some people never learn to drive well; others get into all kinds of trouble
>>in the process.  Does this mean that cars are a bad idea?

>Meaningless text bite.  Citations?  How does driving a car compare to
>programming in C++?  Let's compare languages to langauges and cost of
>delivering software -- then you can deterimine with tangible evidence
>what is good and bad.

Fine.  Please provide us with some documented anecdotal evidence or
data cited from journals.  In the absence of such information in this thread
of discussion, the introduction of a metaphor to illustrate this point is
perfectly valid.

To generalize the metaphor: many reasonably clever and experienced people
fail to learn all kinds things.  This does not imply that these things are
somehow 'defective' or 'too complex'.  As graduate student in physics, I did
very well in quantum mechanics, classical mechanincs and electrodynamics.
But I just could not get the hang of statistical mechanics.  About half of my
classmates felt the same as I.  Does this mean that stat mech is 'too complex'
and should thus be discarded as a tool for the practicing physicist?  Of
course not.

The argument against C++ from the standpoint of excessive complexity and a
steep learning curve always seems to take on populist overtones: i.e., if the
language is not simple enough for any aspiring programmer to master and use
'effectively' in a very short time, then the language is defective.  These
arguments conveniently ignore the obvious fact that development of generally
accepted curricula always lags behind the pioneering work in any field of sudy.

>..............     All other comparisons are emotionally loaded.

As are a number of your statements.

[deletion]

>>Luke> [Bjarne's long explanation that you need teaching material to learn C++
>>Luke>  and that it's easy to pick the wrong teaching material, deleted]
>>
>>Luke> I agree - this is the situation. Now, if C++ is a very complex
language,
>>Luke> that would explain how this situation came about.  In my opinion,
>>Luke> _this_ is the correct explanation.
>>
>>Yes, but popularity alone is enough to explain it -- a popular language
>>attracts people who want to make money from teaching it and half those
>>teachers will be worse than average.

>Another meaningless text bite.  Consider, for example, the SAT company
>recently decided to lower the score for a 50th percentile ranking on next
>year's SAT tests.  Does this mean when more people score above 50% that
>they are smarter than last year?

>50% worse than average is a worthless statement unless you can show that
>the average teacher indeed is worthwhile.  If 100% of the people are
>teaching that no destructors should ever be virtual, then what does that
>say about your average teacher?

This, in turn, is meaningless unless you can provide a concise and meaningful
definition for 'worthwhile'.  Perhaps mastery of the language has not yet
spread very far beyond the language designers, early advocates and devotees.
Does this necessarily mean that C++ is defective?

>>
>>Luke> For me, that section explained _why_ C++ is too complex.
>>
>>No it doesn't, actually, because `too complex' is an opinion in the guise of fact.
>>Too complex for what?  Complexity is something that can be traded off against

>Too complex for the 'average' (your words) teacher to teach effectively.
>If the language cannot be passed on in a manner which causes the majority
>of the students to use it effectively and to its full potential, then
>perhaps it could be considered too complex.

This is so vague as to be meaningless.  Moreover, since the language is
still evolving and has not yet stabilized, it is somewhat dishonest to claim
that C++ is 'too complex' because there is a lack of qualified teachers.  In
any subject that is rapidly changing or newly developed, there is a time lag
between the pioneering work and the development of standardised curricula for
students.

How many people understood and could teach special relativity in 1925?  One.
But today, every college of engineering requires a freshman or sophomore
physics class that teaches the precepts and equations of relativity that were
so revolutionary in the 1920's.  There is an order of presentation of concepts
that is nearly identical in every such textbook and course.

Granted, this may be a somewhat extreme example, but the point is that the
development of a standardised and 'effective' curriculum covering a given
subject requires that the subject achieve a certain amount of stability, and
that experimentation with different teaching approaches occur.  Even in the
age of the Internet, it is unrealistic to expect that dissemination, mastery,
and development of curricula covering an evolving subject can occur
instantly. I humbly submit that the stabilization of the C++ 'paradigm' has
not yet occurred.

[deletion]

>>I don't think C++ compilers are any more buggy than any other widely
>>distributed commercial software.  For instance, I've used a VERY popular
>>WYSIWYG word processor in which the position of the cursor on the screen
>>sometimes deviates by up to several characters from the place on the
>>screen where characters appear when I type them.  It is hard for me
>>to understand how such a bug could ever be allowed to happen -- but
>>there it is.

>Pointless justification.  It is illogical to deem the bugs in C++
>compilers acceptable simply because other software is buggy.  The compiler
>needs to be compared to the langauge document not to a WYSIWYG editor.

Agreed.  And so with this in mind, where are your comparisons to the working
standard?

>(And, as a silly side remark: maybe the software doesn't work because the
>compiler didn't work?)

Yet another text bite.

[deletion]

>The Design and Evolution of C++ is quite good in that it shows some of
>what was kept and some of what was rejected -- and why.
>Taylor Hutt

Yes.  However, I have observed (purely personal opinion here) that most
bashing of C++ is done without regard to the stated goals of the language
designers and the constraints under which they have placed themselves.
Criticism of any language for not providing features that lie outside the
stipulated 'solution space' of that language is meaningless.

Any useful discussion of the language must be performed in the context
of the language goals and constraints.  Since it is very unlikely that these
will change for C++, perhaps the kinds of questions we should be asking are
the following: How well have the language designers met their goals?  Could a
given language feature have been better implemented in a different way?
Could the addition/modification of a language feature help the designers
better meet their goals and still remain within their self-imposed design
guidelines?

The language designers seem to be taking great pains to learn from the
practical experience of the committee members.  This is a logical approach.
Many of the language features people have wished for have received
due consideration by the language designers and have been discarded.
None of these proposals have been denied arbitrarily.  As you point out,
'The Design and Evolution of C++' enumerates some of these proposals and
explains why they were left out of the language.

I think you would agree that C++ is a complex and subtle programming
language, and that there is clearly a shortage of qualified teachers and
established curricula.  However, at this point in the development of C++ and
its programming idioms, this is simply not sufficient reason to dismiss C++
out of hand as being 'too complex'.  Perhaps a little patience is in order.

Bob Steagall

Bob Steagall (steagall@WebSystems.Cleveland.OH.US) wrote:
: In article <3ck71v$5ij@explorer.clark.net> thutt@clark.net (Taylor Hutt) writes:

: >Meaningless text bite.  Citations?  How does driving a car compare to
: >programming in C++?  Let's compare languages to langauges and cost of
: >delivering software -- then you can deterimine with tangible evidence
: >what is good and bad.

: Fine.  Please provide us with some documented anecdotal evidence or
: data cited from journals.  In the absence of such information in this thread
: of discussion, the introduction of a metaphor to illustrate this point is
: perfectly valid.

: To generalize the metaphor: many reasonably clever and experienced people
: fail to learn all kinds things.  This does not imply that these things are
: somehow 'defective' or 'too complex'.  As graduate student in physics, I did
: very well in quantum mechanics, classical mechanincs and electrodynamics.
: But I just could not get the hang of statistical mechanics.  About half of my
: classmates felt the same as I.  Does this mean that stat mech is 'too complex'
: and should thus be discarded as a tool for the practicing physicist?  Of
: course not.

I am not sure this metaphor is better.  Your point seems to be that in order
for a language to be useful, practical and effective it must be complex.  The
C++ complexities does not lie solely on the concepts but more generally on
the chosen syntax and behaviors.  A more straight-forward relationship
between virtuality, inheritance, encapsulation and polymorphism might
have been better expressed than by always using the same keywords and
keeping the C tradition of using ponctuation for everything.

The fact that people argue that it is non-obvious and error-prone (not to
talk about the bad habits it promotes) is what is criticized here I believe.
If it's hard to read and maintain, then its a pain to use.  If you after years
you still can get mixed up and not being sure of behavior, there's a real
problem.

In article <1994Dec14.231316.15695@cae.ca> dak@cae.ca (Pierre Baillargeon) writes:
>
>: To generalize the metaphor: many reasonably clever and experienced people
>: fail to learn all kinds things.  This does not imply that these things are
>: somehow 'defective' or 'too complex'.  As graduate student in physics, I did
>: very well in quantum mechanics, classical mechanincs and electrodynamics.
>: But I just could not get the hang of statistical mechanics.

 Hm. I learned stat mech in _first year_ and understood it.
Had a superb teacher -- it was exciting.  (Only time I ever
got 11/10 for an essay :-)

On the other hand, I could never figure out classical mechanics :-)

>the chosen syntax and behaviors.  A more straight-forward relationship
>between virtuality, inheritance, encapsulation and polymorphism might
>have been better expressed than by always using the same keywords and
>keeping the C tradition of using ponctuation for everything.

 Thats just sugar. You get over that.
>
>The fact that people argue that it is non-obvious and error-prone (not to
>talk about the bad habits it promotes) is what is criticized here I believe.
>If it's hard to read and maintain, then its a pain to use.  If you after years
>you still can get mixed up and not being sure of behavior, there's a real
>problem.
>
 Sigh. The _real_ problems in C++ are in the
_fundamental_ conflicts generated by extending a language like C
in several directions, when C is carefully balanced and places
limits just where they're needed to make it hang together.

 The results of this are contradictions generated by
the desire to retain notions which you are also trying to
replace -- at the same time, and without following through
properly.

 For example, the ISO C notion of lvalue/rvalue
just collapses in C++ because it has user defined types
which can only be operated on as objects. The notion
of one definition of a function collapses when inlining
is introduced without a module system.

The coherence and generality of static
variable initialisation collapses when you permit
arbitrary dynamic initialisers -- which is necessary
to permit static variables of user defined types with constructors
-- without providing a way to state dynamic dependencies.

Introducing references is necessary for overloaded operators,
and they foul up they type system because they are not
really "types". (This is one of the most serious problems,
because it couples very strongly to templates)

Overloading and inheritance mean ambiguities
exist where there were none before and some expressions like

 f

no longer have a definite type.  Despite these problem,
there exists a decent subset of C++ which is well defined
and usable.


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