Re: What is wrong with OO ?

Re: What is wrong with OO ?

[Ell]

Jon S Anthony (jsa@alexandria) wrote:
: ell@access5.digex.net (Ell) writes:
: 
: > Ian Joyner (i.joyner@acm.org) wrote:
: > : Ell wrote:
: > : > 
: > : > Ian Joyner (i.joyner@acm.org) wrote:
: > : > 
: >: > : What made me think of this was that Bill Gates stated in his book that
: >: > : Boeng designed the entire 777 aircraft using one gigantic electronic
: >: > : document! Physical engineering disciplines have made good use of
: >: > : computing technology, it's about time software engineers followed
: >: > : the same path... better and more productive languages and environments,
: >: > : and stop defending archaic 25 year old languages from another era.
  
: > : > I find some 25 year languages like C++ very useful even today.  A lot of
: > : > following a good OO paradigm is in how tools are used and approached.
  
: > : And people can still drive model T Fords, and fly WWI planes. 
 
: > I find the key aspects of C++ to be within the parameters of the
: > _progressive_ OO paradigm and practice.  In many ways C++ has led and
: > still leads in the expression and implementation of many significantly
: > useful OO concepts.
 
: With respect to this "led/leads" claim: Such as?????  I can't think of
: _any_ where this is true.  Though I can think of at least one
: important _implementation_ aspect where this seems to be true.

Led (first or second) wrt the OO paradigm: Private data members, static
resolution of overloaded functions, protected members, and multiple
inheritance. Correct me if I'm wrong.  Remember this is wrt the early
'80's.

Elliott

Re: What is wrong with OO ?

[Jon S Anthony]

In article <5acjtn$5uj@news3.digex.net> ell@access1.digex.net (Ell) writes:

> Jon S Anthony (jsa@alexandria) wrote:
> : With respect to this "led/leads" claim: Such as?????  I can't think of
> : _any_ where this is true.  Though I can think of at least one
> : important _implementation_ aspect where this seems to be true.
> 
> Led (first or second) wrt the OO paradigm: Private data members, static
> resolution of overloaded functions, protected members, and multiple
> inheritance. Correct me if I'm wrong.  Remember this is wrt the early
> '80's.


Recheck your facts.  Led/lead means "first" to me and certainly
carries that connotation around with it even if you want to pull a
Humpty Dumpty.  Private data member stuff was in various languages
before "C with classes" was even conceived (e.g., CLU, Ada83).  It
certainly existed in Eiffel before C++ was christened.  Protected
capability was certainly in Eiffel-1 which predates C++.  Same with
overload resolution (e.g., Algol68 had this as did Ada 83 compilers
that were in the field before CWC or C++).  MI was in Eiffel from the
start and that predates its appearance in C++ for sure.

Next I suppose you will be trying to tell me it was the first to have
generics (templates) or namespaces or assignment attempt or RTTI or...

C++ was and is a _follower_.  That is not necessarily a bad thing, but
it is anything _but_ innovative.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Robert C. Martin]

In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:

> 
> C++ was and is a _follower_.  That is not necessarily a bad thing, but
> it is anything _but_ innovative.
> 

WRT technology I agree with you.  But C++ *does* show innovation in a
completely different vein.  C++ is one of the first of the industrial OO
languages that was created for the engineer instead of for the paradigm.  
C++ was not created to be "pure" or "right" or "correct".  It was created
to be *used*.  And in that regard it represents an innovation wrt industrial
OO languages.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Eirik Mangseth]

Robert C. Martin wrote:
> 
> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> >
> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
> > it is anything _but_ innovative.
> >
> 
> WRT technology I agree with you.  But C++ *does* show innovation in a
> completely different vein.  C++ is one of the first of the industrial OO
> languages that was created for the engineer instead of for the paradigm.
> C++ was not created to be "pure" or "right" or "correct".  It was created
> to be *used*.  And in that regard it represents an innovation wrt industrial
> OO languages.
> 
> --
> Robert C. Martin    | Design Consulting   | Training courses offered:
> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
> 
> "One of the great commandments of science is:
>     'Mistrust arguments from authority.'" -- Carl Sagan

Sorry, but you are wrong. This is one of the many myths that surrounds
C++. No engineer I know would use any tool pertaining to his or her
profession that was as badly designed and implemented as C++. "Pure"
pragmatism is not an option with respect to language design, something
even Mr. Stroustrup himself acknowledges.

If any language was designed for engineers (software engineers that is),
it must be Eiffel.

/Eirik Mangseth/emangset@online.no/United Consultants, Oslo Office,
Norway/

-All opinions expressed are my own and does not necessarily reflect the
views of my employer.

Re: What is wrong with OO O X g

[Greg Comeau]

In article <32CCE4ED.6A21@online.no> emangset@online.no writes:
>Robert C. Martin wrote:
>> 
>> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
>> 
>> >
>> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
>> > it is anything _but_ innovative.
>> >
>> 
>> WRT technology I agree with you.  But C++ *does* show innovation in a
>> completely different vein.  C++ is one of the first of the industrial OO
>> languages that was created for the engineer instead of for the paradigm.
>> C++ was not created to be "pure" or "right" or "correct".  It was created
>> to be *used*.  And in that regard it represents an innovation wrt industrial
>> OO languages.
>> 
>> --
>> Robert C. Martin    | Design Consulting   | Training courses offered:
>> Object Mentor       | rmartin@oma.com     |   Object Oriented Design
>> 14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
>> Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com
>> 
>> "One of the great commandments of science is:
>>     'Mistrust arguments from authority.'" -- Carl Sagan
>
>Sorry, but you are wrong. This is one of the many myths that surrounds
>C++. No engineer I know would use any tool pertaining to his or her
>profession that was as badly designed and implemented as C++. "Pure"
>pragmatism is not an option with respect to language design, something
>even Mr. Stroustrup himself acknowledges.

I have not a clue what you are talking about.  Indeed, the beauty
of C++ is that it is a hybrid and that it does not lock you into one
particular thing.  Robert is indeed correct about its flexibility
and avoidance of so-called political correctness.  Since when are
pragmatics not important in design, decisions, engineering?

You mention myths but only defend it by claiming something closing
into the notion of outrageous that you know of no engineer who
programs in C++.  You say he is wrong -- then counter his 1/2 dozen or
so claims.  Re Stroustrup, I'm not clear what you claim he acknowledges,
so it would also be nice to provide the source for any such information.

- Greg
-- 
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
               Producers of Comeau C++ 4.0 front-end pre-release
****WEB: http://www.comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
 Here:comeau@comeaucomputing.com / BIX:comeau or comeau@bix.com / CIS:72331,3421

Re: What is wrong with OO ?

[Jon S Anthony]

In article <rmartin-0201971129150001@pool11-018.wwa.com> rmartin@oma.com (Robert C. Martin) writes:

> In article <JSA.97Jan1181506@alexandria>, jsa@alexandria (Jon S Anthony) wrote:
> 
> > 
> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
> > it is anything _but_ innovative.
> > 
> 
> WRT technology I agree with you.  But C++ *does* show innovation in a
> completely different vein.  C++ is one of the first of the industrial OO
> languages that was created for the engineer instead of for the paradigm.  
> C++ was not created to be "pure" or "right" or "correct".  It was created
> to be *used*.  And in that regard it represents an innovation wrt industrial
> OO languages.

Oh, I don't know.  I think C++ was created simply because BS was
saddled with C (at ATT) and wanted _something_ that had a least _some_
abstraction capabilities in it.  Voila.  C++.  Whether it is any more
"usable" than several other options is highly open to question.  And
in fact, in general I would say the answer is "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Matt Austern]

jsa@alexandria (Jon S Anthony) writes:

> Oh, I don't know.  I think C++ was created simply because BS was
> saddled with C (at ATT) and wanted _something_ that had a least _some_
> abstraction capabilities in it.  Voila.  C++.  Whether it is any more
> "usable" than several other options is highly open to question.  And
> in fact, in general I would say the answer is "no".

It's not necessary to speculate on why Bjarne Stroustrup made the
design decisions that he did: he discusses them, in a fair amount
of detail, in _The Design and Evolution of C++_.

I probably shouldn't try to summarize an entire book in a single
sentence.  One thing he makes very clear in his book, though, is that
he was trying to create a language that, like C, made it possible to
write low-level programs, but that also, like Simula, included
high-level abstraction facilities.  

This combination is, if not unique to C++, at least rare.  It's also
quite clear that it was a design goal from the very beginning.

Re: OO, C++, and something much better!

[Pieter Schoenmakers]

In article <32ce7009.280817694@news.zip.com.au> skaller@maxtal.com.au (John (Max) Skaller) writes:

   Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
   language to provide ...

Shouldn't that be `first MAINSTREAM'?  --Tiggr

Re: What is wrong with OO ?

[Valerie Torres]

Jon S Anthony (jsa@alexandria) writes:

 > In article <5acjtn$5uj@news3.digex.net> ell@access1.digex.net (Ell) writes:
 > 
 > > Jon S Anthony (jsa@alexandria) wrote:
 > > : With respect to this "led/leads" claim: Such as?????  I can't think of
 > > : _any_ where this is true.  Though I can think of at least one
 > > : important _implementation_ aspect where this seems to be true.
 > > 
 > > Led (first or second) wrt the OO paradigm: Private data members, static
 > > resolution of overloaded functions, protected members, and multiple
 > > inheritance. Correct me if I'm wrong.  Remember this is wrt the early
 > > '80's.
 > 
 > Recheck your facts.  Led/lead means "first" to me and certainly
 > carries that connotation around with it even if you want to pull a
 > Humpty Dumpty.

It is very important getting the fact straight on a topic like this where
many seem keen on confusing the question "is C++ innovative and if so
compared to what and in which ways?" with "is C++ my favorite programming
language?"  or or even "is C++ perfect?" (my opinion: it is in some ways,
it is for many things, it is not).

The origins of C++ and the reasoning behind the various design decisions
are well documented:

	Bjarne Stroustrup: A History of C++: 1979-1991.
	Proc ACM History of Programming Languages conference (HOPL-2).
	ACM Sigplan Notices. Vol 28 No 3, pp 271-298. March 1993.
	Also in History of Programming languages
	(editors T.J.Begin and R.G.Gibson)
	Addison-Wesley, ISBN 1-201-89502-1. 1996.

	Bjarne Stroustrup: The Design and Evolution of C++.
	Addison-Wesley. 1994. ISBN 0-201-54330-3.

Note that the paper went through HOPL2's strict peer review process so
that the likelyhood that what is claimed to be a fact really is a fact
is much higher than in a net posting, in an unrefereed paper, or in a
paper from a commercial journal.

To the best of my abilities, the D&E book agrees with the HOPL paper on
issues covered in both but provides much more information and context.

It would have been nice if comparable information existed on the origins
of most major languages. That would have made it easier to understand
the different languages in context and see how ideas moved through the
programming communities. The HOPL papers is a good start, but they differ
too much in what kind of information they supply and tend not to be
sufficiently detailed for my taste. Also, HOPL covers only a few languages.


 > Private data member stuff was in various languages
 > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
 > certainly existed in Eiffel before C++ was christened.  Protected
 > capability was certainly in Eiffel-1 which predates C++.  Same with
 > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
 > that were in the field before CWC or C++).  MI was in Eiffel from the
 > start and that predates its appearance in C++ for sure.

First of all, we must be careful about dates. C with classes had "private"
in 1979 and protected around 1981. Data abstraction language (such as Ada83)
tends to have private only (you need inheritance for the private/protected
distinction to be meaningful) whereas OO language (such as Smalltalk) tends
to have protected only (whatever it may be called).

I don't know if any language having both before C++ and I don't know of
any earlier language expressing the dinction between implementation
inheritance (private base) and interface inheritance (public base,
subtyping). This pre-dates Liskov's formulation of her substitution
principle by about 8 years. It is of course possible that some language
had equivalent facilities at the time I designed those features for
CwithClasses/C++ or that someone somewhere wrote a paper discussing
the issues, but I didn't know of one so the protection facilities
of C++ are independently developed. In addition to private, protected,
and public, C++ offers the mechanism for selectively including names
from a base in the interface of a derived class. That too may have been
an innovation, but I don't really know.

C++ introduced constructors with the possibility of having several as
well as destructors (around 1980). All languages that support information
hiding provides some form of initialization (and certainly Simula did),
but I think the C++ mechanism provides a degree of flexibility that was
novel.

It is hard to really pin down what is innovative and what is not. For
example, I credited Algol68 with C++'s ability to have declarations
in conditions so that you can declare, initialize, and test in one
place. However, I was (later) told by one of the people involved in the
Algol68 design that although Algol68 logically ought to have had that feature,
they didn't think of that in the right way at the right time, so Algol68
doesn't allow declarations in conditions. In other words. I had deduced
that feature from the structure of Algol68 and failed to verify.

There are literally hundreds of details that one could examine to try
to determine their exact antecedence and give credit where credit is
due. I do some of that in the history paper and in D&E, but here I'd
like to point to a couple of bigger issues.

C++ was designed to allow design and programming techniques from Simula
to be used in the context of systems programming and other applications
where run-time and space were critical. On way of looking at the task
I set myself was to make data abstraction and object-oriented techniques
affordable and accepted in a community that mostly didn't know of them
and to the extent it did couldn't afford to apply those techniques
given the languages available.

To the extent that C++ succeeded at that, C++ was ahead of the wave,
``a leader'' borrowing the phrase from the original posting. It has
always been my opinion that making something comprehensible and affordable
is a worthwhile, innovative, and socially useful activity. I think producing
14 million volkswagen's or Ford Ts is at least as innovative as building
a few thousands Rolls Royces or a few hundred formula-1 cars - even though
the vast majority of the individual features first appear in the luxury
and speciality cars. I think that the majority of areas where C++ has
contributed have to do with economy and scale.

C++ was designed to be useful rather than to be innovative. Wherever
possible, I tried to follow a well-tested precedence. Thus, you can
find ideas from Algol68, ML, Ada, Clu, and even BCPL in C++. The main
ideas came from C and Simula, of course. Only where I couldn't find a
solution that fitted in C++'s general framework and met my criteria for
run-time efficiency, ease of implementation, ease of teaching, etc.
(see D&E Chapter 4), did I feel compelled to try to invent something. 

Much of C++'s success has to do with fitting into existing environments
and being compact and fast (yes, I know that these are not the aspects
of C++ that are currently emphasized in the MS Windows world). The speed
and compactness of code generated from C++ depends on a few fundamental
design decisions that I think were novel at the time:

	The ability to easily link to existing languages and have C++
	code used from other languages. (This is done through the linkage
	model and it is directly supported in the C++ grammar).

	The ability to use user-defined types and built-in types in the
	same way. In Simula - as in most data abstraction and OO language -
	every object of a user-defined type must be on the heap; this
	leads to overheads compared to stack-allocated objects. Similarly,
	C++ pointers work uniformly for both user-defined and built-in
	types.

	C++ offers objects of user-defined types with zero space overhead
	compared to C structs.

	C++ offers calls of member functions with zero time overhead
	compared to C functions.

	C++ offers inline member and non-member functions with zero
	overhead compared to macros.

	C++ offers its form of dynamic (run-time) resolution, virtual
	functions, with low and fixed overhead compared to ordinary
	function calls (20% to 100% dependent of implementation).

	C++ can be used without a significant run-time-support system
	and without significant libraries.

These features were introduced in the 1979 to 1983 timeframe (virtual
functions last!) and described in journals and at conferences from
about 1981.

This combination of feature was - and to some extent still is - unique
and important to many. This efficiency is a large part of the reason
why C++ was able to blaze a trail into areas where data abstraction
and object-oriented languages had made essentially no headway.

By demonstrating applicability and efficiency in new application areas
and in new communities C++ opened opportunities to other languages
with a different balance of tradeoffs. Both where C++ was successfully
used and where problems were found, it opened a door to alternatives.

People who didn't try to use OO and abstraction languages in the early
days (say 1967 to 1989) typically seriously underestimate the obstacles
to getting these languages and programming techniques into non-research
use. Most would also be shocked at the state of their favorite language
- as compared to its current state - in its early years. When comparing
languages in a historical context we must consider not only if a language
has a feature, but also when it had it, when it was published, when it
was implemented, and whether those implementations were good enough for
production use.


 > Next I suppose you will be trying to tell me it was the first to have
 > generics (templates) or namespaces or assignment attempt or RTTI or...

Please refrain from making conjectures about what someone in a debate
might claim. It adds no facts and can fuel flamewars.


 > C++ was and is a _follower_.  That is not necessarily a bad thing, but
 > it is anything _but_ innovative.
 > 
 > /Jon
 > -- 
 > Jon Anthony
 > Organon Motives, Inc.
 > Belmont, MA 02178
 > 617.484.3383
 > jsa@organon.com

Over the years, C++ has evolved within a framework that was reasonably
well understood early on. During this evolution, C++ has borrowed from
several languages (always with acknowledgements), but it has never been
in the position of slavishly following fashion or systematically borrowing
from a perceived competitor. C++ evolved within its own framework to
meet the needs of its users. I don't think that can be fairly labelled
"being a follower."

As far as I know, Simula was the first language with structured RTTI
(INSPECT and QUA). Some studies I made of Simula programs convinced me
that the less RTTI was used the better the structure of an average program
(INSPECT was commonly used in ways that precluded modularity). The C++
RTTI (primarily dynamic_cast) was introduced to handle the few cases
where it is necessary and in a form that hopefully minimizes problems.

Multiple inheritance is sometimes mentioned as innovative in C++.
It existed in different - more powerful, but slower - forms in
several Lisp dialects. I considered it for C++ from about 1981 and
introduced it into C++ in a more static and type-safe form in 1987
after a couple of years of experimentation (a brief mention of C++ MI
can be found in my "What is Object-oriented programming?" paper from
1985). The form of multiple inheritance in C++ may be innovative, the
fundamental idea is quite old. I now consider MI essential for a
language relying on static type checking. You can do without it of
course (just like you can do without single inheritance and without
classes), but the resulting code is contorted.

In the area of exceptions, C++ may have added something important:
C++ exceptions can be of arbitrary type and inheritance is taken
into account when catching an exception. This provides important
possibilities for grouping exceptions that I don't know precedence
for (though the need for grouping has been known for decades).

Templates are an interesting case. Naturally, many languages have provided
macros, generics, type inference, etc. for decades. However, templates
grew out of the needs of C++ programmers and seem to have a combination
of features that provide a surprising expressive power. The (relatively
new) C++ standard library of containers and algorithms seems to me to
provide a unique combination of generality and efficiency. Naturally,
the algorithms are not new (most can be found in Knuth), most languages
provide containers which roughly correspond to what the STL offers,
and many of the programming techniques used are borrowed (with thanks
and acknowledgement) from the functional programming community.

Should something like this be considered innovative? Would it be fair
to say that it leads hundreds of thousands of programmers into areas
of programming where they haven't been and would have been unlikely
to reach for many more years? I think so.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

OO, C++, and something much better!

[John (Max) Skaller]

On 3 Jan 1997 14:56:25 -0500, comeau@panix.com (Greg Comeau) wrote:

>In article <32CCE4ED.6A21@online.no> emangset@online.no writes:
>>Robert C. Martin wrote:
>>> > C++ was and is a _follower_.  That is not necessarily a bad thing, but
>> > it is anything _but_ innovative.
>>> 
>>> WRT technology I agree with you.  But C++ *does* show innovation in a
>>> completely different vein.  C++ is one of the first of the industrial OO
>>> languages that was created for the engineer instead of for the paradigm.
>>> C++ was not created to be "pure" or "right" or "correct".  It was created
>>> to be *used*.  And in that regard it represents an innovation wrt industrial
>>> OO languages.

>>> Robert C. Martin    
>>
>>Sorry, but you are wrong. This is one of the many myths that surrounds
>>C++. No engineer I know would use any tool pertaining to his or her
>>profession that was as badly designed and implemented as C++. "Pure"
>>pragmatism is not an option with respect to language design, something
>>even Mr. Stroustrup himself acknowledges.
>
>I have not a clue what you are talking about.  Indeed, the beauty
>of C++ is that it is a hybrid and that it does not lock you into one
>particular thing.  Robert is indeed correct about its flexibility
>and avoidance of so-called political correctness.  Since when are
>pragmatics not important in design, decisions, engineering?

Here' my opinion. Stroustrup is to be applauded for making a powerful
"non-religious" language available to everyone. C++ is not a clean
language. It's quite messy and hard to use. But it is available.
No one knows how to design a quality system -- and _also_ make
is widely available. Bjarne decided "having better than what we have"
was better than some intangible thing no one had.

Is C++ innovative? Too right it is. 
It has the most powerful support for genericity available
in any widely used commercial language. (Sorry, Ada doesn't count,
Eiffel is borderline, current Java is a backward step. If there
is any competition it is from Smalltalk [which uses 
dynamism instead]).

Is it "pure OO"? No. Thank goodness. It has something
much better -- a vague and not very good appoximation
to a new methodology which provides vastly superior
reusability, categorical progamming. The evidence
is in Standard (Template) Library which is one of the 
most reusable commercial libraries available for any system.

There is hardly any inheritance at all in the C++ Standard Library.
It is not an "Object Oriented" library. 80 or so members of the C++
committee, however, thought it was the best choice for C++.

Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
language to provide class based object orientation and go on 
to something much better before standardisation has been completed.

Modern C++ has made TWO paradigm shifts. Most people
haven't made the first (to OO) yet it is already being
replaced.

Re: OO, C++, and something much better!

[vlad]

skaller@maxtal.com.au (John (Max) Skaller) wrote:
>Here' my opinion. Stroustrup is to be applauded for making a powerful
>"non-religious" language available to everyone. C++ is not a clean
>language. It's quite messy and hard to use. But it is available.
>No one knows how to design a quality system -- and _also_ make
>is widely available. Bjarne decided "having better than what we have"
>was better than some intangible thing no one had.

>Is C++ innovative? Too right it is. 
>It has the most powerful support for genericity available
>in any widely used commercial language. (Sorry, Ada doesn't count,
>Eiffel is borderline, current Java is a backward step. If there
>is any competition it is from Smalltalk [which uses 
>dynamism instead]).

>Is it "pure OO"? No. Thank goodness. It has something
>much better -- a vague and not very good appoximation
>to a new methodology which provides vastly superior
>reusability, categorical progamming. The evidence
>is in Standard (Template) Library which is one of the 
>most reusable commercial libraries available for any system.

>There is hardly any inheritance at all in the C++ Standard Library.
>It is not an "Object Oriented" library. 80 or so members of the C++
>committee, however, thought it was the best choice for C++.

>Is C++ innovative? Of course it is. It was one of the FIRST mainsteam
>language to provide class based object orientation and go on 
>to something much better before standardisation has been completed.

>Modern C++ has made TWO paradigm shifts. Most people
>haven't made the first (to OO) yet it is already being
>replaced.

Funny, I wanted to write almost the same think. I want to express my support to
your ideas, so you will be not alone when religious OO fanatics will be spitting
on you.

   

 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: OO, C++, and something much better!

[Mike Anderson]

I have some questions/comments about this (my words are preceeded by
"MA":)

John (Max) Skaller wrote:
> Stroustrup is to be applauded for making a powerful
> "non-religious" language available to everyone.

MA: What's "non-religious"?

> C++ is not a clean language. It's quite messy and hard to use. But it is available.

MA: So what?  There are plenty of available languages like that.

> No one knows how to design a quality system -- and _also_ make
> is widely available. Bjarne decided "having better than what we have"
> was better than some intangible thing no one had.

MA:  I don't understand that and won't comment on it.

> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
> Eiffel is borderline, current Java is a backward step. If there
> is any competition it is from Smalltalk [which uses
> dynamism instead]).

MA:  Why doesn't Ada count; why is Eiffel borderline, and why is current
Java a backword step?

> Is it "pure OO"? No. Thank goodness. It has something
> much better -- a vague and not very good appoximation
> to a new methodology which provides vastly superior
> reusability, categorical progamming. The evidence
> is in Standard (Template) Library which is one of the
> most reusable commercial libraries available for any system.

MA:  The above is utter nonsense (well, someone's got to say it).  I
don't usually rant but the sentences
	'Is it "pure OO"? No. Thank goodness.'
pisses me off because I firmly believe I in pure OO.  (Hey, I've got
some religion, but don't tell anybody.)  As far as "a vague and not very
good appoximation to a new methodology which provides vastly superior
reusability" ...are you being sarcastic or what?

....Mike

Re: OO, C++, and something much better!

[Stanley Allen]

John (Max) Skaller wrote:

> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

You loaded the question, and therefore your dismissal of
Ada is the act of knocking down a strawman.

Let me engage in some debuking here, and point out that Ada
*is* widely used, just not in the PC/GUI world.  Ada is also
very much a "commercial" language; in fact, many of the
companies using Ada today for commercial projects consider
it to be a success factor in their software efforts.

To hear that C++'s template mechanism is "innovative" and
"powerful" comes as a surprise.  Parts of the C++ template
mechanism look like a borrowing of Ada's "generic" facility
(Stroustrup attributes this to Alex Stepanov, who had done
a great deal of work with Ada generics before designing the
C++ Standard Template Library).  Unfortunately, the type
system in C++ is too weak to support anything as powerful
as Ada's generic facility.  The C++ "template argument"
(which corresponds to Ada's "generic formal parameter") for
a type can only be of the form "class T".  In Ada terms,
this would be like having all generic formals be
"type T is private".

In C++, there is no way to 1) specify the kinds of types that
may be used to make an instance of the template (for example,
to specify that the template may only be instantiated with
integer types), or 2) to assume a particular set of operations
will be available within the template for the type argument
(for example, to assume that integer operations will be
availible for a variable of type T).

These two issues are the heart and soul of Ada generics
(derived as they are from Ada's type system), and provide
a powerful tool for specifying complete "contracts" between
the generic developer and user.  The C++ mechanism boils
down in practice to a "macro-expansion" tool.

--
Stanley Allen
mailto:sallen@hso.link.com

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <32D0CA27.44C2@ghgcorp.com> Stanley Allen <sallen@ghgcorp.com> writes:


   John (Max) Skaller wrote:

   > Is C++ innovative? Too right it is.
   > It has the most powerful support for genericity available
   > in any widely used commercial language. (Sorry, Ada doesn't count,
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

   You loaded the question, and therefore your dismissal of
   Ada is the act of knocking down a strawman.

   Let me engage in some debuking here, and point out that Ada
   *is* widely used, just not in the PC/GUI world.  Ada is also
   very much a "commercial" language; in fact, many of the
   companies using Ada today for commercial projects consider
   it to be a success factor in their software efforts.

   To hear that C++'s template mechanism is "innovative" and
   "powerful" comes as a surprise.  Parts of the C++ template
   mechanism look like a borrowing of Ada's "generic" facility
   (Stroustrup attributes this to Alex Stepanov, who had done
   a great deal of work with Ada generics before designing the
   C++ Standard Template Library).  Unfortunately, the type
   system in C++ is too weak to support anything as powerful
   as Ada's generic facility.  The C++ "template argument"
   (which corresponds to Ada's "generic formal parameter") for
   a type can only be of the form "class T".  In Ada terms,
   this would be like having all generic formals be
   "type T is private".

<stuff deleted>


   --
   Stanley Allen
   mailto:sallen@hso.link.com


I would tend to agree. Another point is that C++ templates tend to be
implemented differently in every compiler, so a program which uses
templates heavily is often less portable.

However, if I remember correctly, Alex Stepanov had earlier tried to
implement a library like the C++ STL in Ada, but was incapable of
doing it. This would indicate that the C++ template mechanism is more
flexible than the Ada generics.
Any comments?

Re: What is wrong with OO ?

[Bart Samwel]

Bjarne Stroustrup wrote:

> Only where I couldn't find a solution that fitted in C++'s general
> framework and met my criteria for run-time efficiency, ease of
> implementation, ease of teaching, etc. (see D&E Chapter 4), did I
> feel compelled to try to invent something.

When I read this, a lot of questions pop up in my head. I'll ask only
one: You've only included features that didn't compromise ease of
teaching (at least, that's my interpretation of what you wrote). Why is
it then, that C++ contains so many hidden 'features' (or rather,
non-explicit rules) that confuse people, at least at my university?

As far as I'm concerned, C++ is not a language for teaching. It has too
many of these implicit rules to be logical, and the fact that it
doesn't have garbage collection and does have pointers really makes it
error-prone; especially for beginning programmers, this is not a good
thing. They should be writing WHAT should be done, and ALL that should
be done; they shouldn't be bothered with the 'how' part of programming,
like (with alternatives): memory management (garbage collection),
pointers (references), virtual functions (can be detected by the
compiler). They should not be bothered with implicit rules (like the
multiple inheritance rules, for instance) that they have to know of,
before using multiple inheritance.

C++ is an excellent language as an extension to C, but C is altogether
obsolete and much too low-level, except for systems programming, and
other languages are now available for writing high-level software.
Many people make the (IMO huge) mistake of using C++ for high-level
software projects, leading to buggy results and, often, lots of core
dumps. Programmers are not perfect, and C++ expects them to be so by
providing too many ways of making mistakes.

Languages like Eiffel (my personal favorite) are much more suitable for
high-level projects; Eiffel, for instance, does not burden the
programmer more than needed, and has a clean, clear syntax that can
even be immediately understood by people that don't know the language.

> Much of C++'s success has to do with fitting into existing
> environments and being compact and fast (yes, I know that these are
> not the aspects of C++ that are currently emphasized in the
> MS Windows world). The speed and compactness of code generated from
> C++ depends on a few fundamental design decisions that I think were
> novel at the time:

Speed and compactness is certainly a goal that C++ has achieved. But it
did not achieve one major goal: ease of use.

>         C++ offers inline member and non-member functions with zero
>         overhead compared to macros.

You shouldn't bother programmers with inlining. Inlining can be done
automatically by the compiler.

>         C++ offers its form of dynamic (run-time) resolution, virtual
>         functions, with low and fixed overhead compared to ordinary
>         function calls (20% to 100% dependent of implementation).

Virtual functions must be explicitly specified. This can be done by the
compiler. And, virtual functions must be specified in the ancestor
class; this means that when a class designer forgot to put that in
(and this happens often), I can't redefine the function correctly.

> Over the years, C++ has evolved within a framework that was reasonably
> well understood early on.

Well understood, yes. But the framework is now obsolete, and it has
some serious design flaws that also bother C++ users.


   Bart Samwel  (bsamwel@wi.leidenuniv.nl)

Re: OO, C++, and something much better!

[Chris Brand]

John (Max) Skaller wrote:
> 
[cut]
> 
> Is C++ innovative? Too right it is.
> It has the most powerful support for genericity available
> in any widely used commercial language. (Sorry, Ada doesn't count,
> Eiffel is borderline, current Java is a backward step. If there
> is any competition it is from Smalltalk [which uses
> dynamism instead]).
> 
[cut]

Great argument.

To paraphrase:
"Is C++ innovative? Yes. Its got something other languages had first but
it's more widely used."

Perhaps I've got the wrong definition of innovative...

-- 
Chris
Stating my own opinions, not those of my company.

Re: OO, C++, and something much better!

[Michael F Brenner]

Yes, there is some added flexibility in C++ templates over Ada generics,
and vice versa too. The added flexibility in C++ templates comes from the
ability to expand them at compile time without losing optimizations, unlike
Ada generics whose paradigm is to expand at run-time and remove staticness
from expressions. The added flexibility in Ada templates comes from the
added flexibility in Ada packages, which can have BOTH types and functions.
An ideal generic would have all of the Ada features plus the following:
(a) anything that was static in the package while you were testing it, that
is, before you made it generic, remains static after you genericized the
package; (b) there is a standard pragma that tells the compiler to 
expand the generic at compile time, (c) there is a formal generic
parameter type that works on EITHER modular or twos complement types,
and (d) generates the kind of code for each instantiation that keeps
track of the line numbers in generic source code, so unhandled exceptions
would generate a useful traceback of source code lines through generic
packages.

Re: OO, C++, and something much better!

[Tucker Taft]

Michael F Brenner (mfb@mbunix.mitre.org) wrote:

: Yes, there is some added flexibility in C++ templates over Ada generics,
: and vice versa too. The added flexibility in C++ templates comes from the
: ability to expand them at compile time without losing optimizations, unlike
: Ada generics whose paradigm is to expand at run-time and remove staticness
: from expressions. 

It is true that Ada considers some expressions inside a generic as
non-static, but that has no necessary effect on optimization.
Many non-static expressions are computed at compile-time.  There
are certain places where the language requires static expressions,
such as an expression in a case alternative, but compilers can and do
still evaluate expressions that are not "officially" static at
compile-time.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: What is wrong with OO ?

[Jon S Anthony]

In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:

> jsa@alexandria (Jon S Anthony) writes:
> 
> > Oh, I don't know.  I think C++ was created simply because BS was
> > saddled with C (at ATT) and wanted _something_ that had a least _some_
> > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
> > "usable" than several other options is highly open to question.  And
> > in fact, in general I would say the answer is "no".
> 
> It's not necessary to speculate on why Bjarne Stroustrup made the
> design decisions that he did: he discusses them, in a fair amount
> of detail, in _The Design and Evolution of C++_.

He also gave various descriptions of this process while it was
happening cira 87-89 and I happened to attend some of these.


> he was trying to create a language that, like C, made it possible to
> write low-level programs, but that also, like Simula, included
> high-level abstraction facilities.  

Exactly.  This came from his direct experience of having to recode a
Simula program for his thesis into BCPL.  The resulting nightmare was
not something he wished to have to go through again.  When getting to
ATT and seeing that it was C or nothing, he decided to "fix it" before
suffering the same experience.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Jon S Anthony]

In article <E3I8GL.AuH@research.att.com> bs@research.att.com (Valerie Torres) writes:

> Jon S Anthony (jsa@alexandria) writes:
>  > Private data member stuff was in various languages
>  > before "C with classes" was even conceived (e.g., CLU, Ada83).  It
>  > certainly existed in Eiffel before C++ was christened.  Protected
>  > capability was certainly in Eiffel-1 which predates C++.  Same with
>  > overload resolution (e.g., Algol68 had this as did Ada 83 compilers
>  > that were in the field before CWC or C++).  MI was in Eiffel from the
>  > start and that predates its appearance in C++ for sure.

> First of all, we must be careful about dates. C with classes had "private"
> in 1979 and protected around 1981. Data abstraction language (such as Ada83)
> tends to have private only (you need inheritance for the private/protected
> distinction to be meaningful) whereas OO language (such as Smalltalk) tends
> to have protected only (whatever it may be called).

Fair enough and I certainly can basically agree with this.  It is also
no big deal IMO if the features are _not_ "innovative" or new.  If
they are good and correct and well integrated - who cares (well some
do, but from many points of view, it just doesn't matter).  For
example, private stuff is basically captured in M2 by opaque types,
which according to Wirth was around '77-'78.  As you point out,
Smalltalk had the equivalent of protected and that was early '70s.
Shrug...


> I don't know if any language having both before C++ and I don't know of
> any earlier language expressing the dinction between implementation
> inheritance (private base) and interface inheritance (public base,
> subtyping).

You talking C++ or "C with Classes"?


> This pre-dates Liskov's formulation of her substitution
> principle by about 8 years. It is of course possible that some language
> had equivalent facilities at the time I designed those features for
> CwithClasses/C++ or that someone somewhere wrote a paper discussing

Well, what time frame are you really refering to here?  The
79-early-8x stuff of CwithClasses or the latter 80's C++?


[Various other stuff snipped on co/independent discovery etc.]

Well, sure, all this sounds perfectly sensible and believable.


> There are literally hundreds of details that one could examine to try
> to determine their exact antecedence and give credit where credit is
> due.

Absolutely.


> C++ was designed to allow design and programming techniques from Simula
> to be used in the context of systems programming and other applications
> where run-time and space were critical. On way of looking at the task
> I set myself was to make data abstraction and object-oriented techniques
> affordable and accepted in a community that mostly didn't know of them
> and to the extent it did couldn't afford to apply those techniques
> given the languages available.
> 
> To the extent that C++ succeeded at that, C++ was ahead of the wave,

Ah, this is the "_implementation_ innovation" aspect that I originally
refered to as something that I would acknowledge C++ "leading" in the
"OO world"...


> of C++ that are currently emphasized in the MS Windows world). The speed
> and compactness of code generated from C++ depends on a few fundamental
> design decisions that I think were novel at the time:

Some of these are novel (in a very narrow context - existing C) but
most are not.


> 	The ability to use user-defined types and built-in types in the
> 	same way. In Simula - as in most data abstraction and OO language -
> 	every object of a user-defined type must be on the heap; this
> 	leads to overheads compared to stack-allocated objects. Similarly,
> 	C++ pointers work uniformly for both user-defined and built-in
> 	types.

This certainly exists in Ada83 (sans virtual stuff).


> 	C++ offers objects of user-defined types with zero space overhead
> 	compared to C structs.

Same here.


> 	C++ offers calls of member functions with zero time overhead
> 	compared to C functions.

Same here.


> 	C++ offers inline member and non-member functions with zero
> 	overhead compared to macros.

Same here.


> 	C++ offers its form of dynamic (run-time) resolution, virtual
> 	functions, with low and fixed overhead compared to ordinary
> 	function calls (20% to 100% dependent of implementation).

This is a very good example - quite possibly the most important one.


> 	C++ can be used without a significant run-time-support system
            ^^^
> 	and without significant libraries.

Most statically compiled languages could and can be so used - it
"just" requires intelligent binders (not necessarily linkers...)


> This combination of feature was - and to some extent still is - unique
> and important to many.

This is not currently believable.  However, in the past, the efficient
runtime dispatch ability was at one point clearly a plus.


> This efficiency is a large part of the reason why C++ was able to
> blaze a trail into areas where data abstraction and object-oriented
> languages had made essentially no headway.

This is not particularly clear or believable.  It probably did have
something to do with it, but how much is not obvious.  The C heritage
(and its _presumed_ efficiency by association) is still the single
most likely reason for the demonstrated popularity.  Of course, in
those early days, there was no reason to believe that this would be a
real factor.  Sort of like having the insight/luck to buy into MS
before they were anything.


> By demonstrating applicability and efficiency in new application areas
> and in new communities C++ opened opportunities to other languages
> with a different balance of tradeoffs. Both where C++ was successfully
> used and where problems were found, it opened a door to alternatives.

Actually, I think a closer reading would be that people started out
thinking, "hey, we C folk can get on this <hated> OO/abstraction
bandwagon with our own C++!  It's basically just a better C which you
can sometimes use for OO stuff if you want.  Heck, you can even
compile most of your old C stuff with a C++ compiler."  What happened
next was that some of the more savvy realized that there really _was_
some good in this sort of approach after all - irrespective of any
language issue.  These folks no longer are wedded to the C++ language
and in fact many have moved on to, shall we say, more pleasent just as
capable/efficient alternatives.


> from a perceived competitor. C++ evolved within its own framework to
> meet the needs of its users. I don't think that can be fairly labelled
> "being a follower."

OK, but don't think it can be fairly labelled a "leader" either.  I
suppose we can say that it just "is"...


> language relying on static type checking. You can do without it of
> course (just like you can do without single inheritance and without
> classes), but the resulting code is contorted.

I don't want to go into this, suffice to say we can simply agree to
disagree.


> In the area of exceptions, C++ may have added something important:
> C++ exceptions can be of arbitrary type and inheritance is taken
> into account when catching an exception.

I see this as an approach or refinement to an already known and
(reasonably) understood facility.  I suppose that means I have a
somewhat more stringent notion of "innovation".


> Templates are an interesting case. Naturally, many languages have provided

Same here.  Note that in both of these cases you don't get something
for nothing.  Both exceptions and templates are IMO rather more
convoluted in C++ than the (more or less) equivalents in alternatives.

> Should something like this be considered innovative? Would it be fair

Depends on your point of view.  Some would probably say "yes" - for
example, you - I would tend to say "no".

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Stanley Allen]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

My history may be a bit rusty, but I believe that
Alex Stepanov's work in Ada was successful, just not
widely used.  He had some published material about
the Ada work, which I have not seen directly.  It
is listed in the references of his on-line paper
"Algorithm-Oriented Generic Libraries":

    http://www.cs.rpi.edu/~kennyz/www/ADS/Algor/Algor.html

Stepanov's work was done using Ada83; it would
certainly be different if it were done today with
Ada95.

--
Stanley Allen
mailto:sallen@ghgcorp.com

Re: OO, C++, and something much better!

[Robert Dewar]

Tucker said

"It is true that Ada considers some expressions inside a generic as
non-static, but that has no necessary effect on optimization.
Many non-static expressions are computed at compile-time.  There
are certain places where the language requires static expressions,
such as an expression in a case alternative, but compilers can and do
still evaluate expressions that are not "officially" static at
compile-time."


One of the mistakes made in some Ada 83 compilers was to assume that the
concepts of "evaluable at compile time" and "static expression" could be
equated, but this was not true in Ada 83 and is not true in Ada 95. The
set of static expressions is a subset of the expressions that can be
evaluated at compile time, and compilers should treat them differently.

To see how GNAT handles this, look at the unit Sem_Eval, and note that
the section on "Compile-Time Known Values" addresses this issue.

Ada Generics (was Re: OO, C++, and something much better!)

[Bob Gilbert]

In article <5arhb0$d4e@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> Yes, there is some added flexibility in C++ templates over Ada generics,
> and vice versa too. The added flexibility in C++ templates comes from the
> ability to expand them at compile time without losing optimizations, unlike
> Ada generics whose paradigm is to expand at run-time and remove staticness
> from expressions. 

Most of the Ada comilers I've used do expand the generic instantiation at
compile time.  Could somebody offer up an example of where this would not
be possible?

-Bob

Re: OO, C++, and something much better!

[Robert Dewar]

Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

Actually, when I talked to Alex, he indicated that there were critical
features in Ada 95 that were missing in C and C++ for this kind of
work. In particular, he noted that C lacks a general address comparison
operation, useful for hashing data structures, whereas Ada does have such
an operation (in System.Storage_Elements on type Integer_Address). It is
a bit ironic to identify this particular feature as crucial (since most
people mistakenly think that C has such a feature and Ada doesn't!)

He did also discuss problems in Ada 95, most notably the fact that generics
are less flexible than templates (that is to be expected, the flexibility
of templates comes of course at the expense of compile time checkability),
and also the lack of automatic instantiation in Ada.

Automatic instantiation is of course a dangerous tool, but in the hands
of those writing libraries of this type (Alex said to me that he thought
there were only about six people who should be writing such libraries and
he did not know who the other five were :-) :-) dangerous tools can be
put to good use, with the danger being insulated from the eventual client
at least in some cases.

There is a team at Rensaleer which has been working on duplicating STL
in Ada 95. The preliminary results looked very encouraging, I do not
know the status of this work.

Re: OO, C++, and something much better!

[Jay Martin]

ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

>However, if I remember correctly, Alex Stepanov had earlier tried to
>implement a library like the C++ STL in Ada, but was incapable of
>doing it. This would indicate that the C++ template mechanism is more
>flexible than the Ada generics.
>Any comments?

I think this is with Ada83 (I actually have his unimpressive book "The
Ada(83) Generic Library").  It took literally minutes to smash into
braindead limitations of Ada83 which made elegant data structure
libraries infeasable.  Since the standard was locked, it took 12 years
before any of these problems were corrected.  To me this proved the
need for timely evolution of computer languages.

Jay

Re: Ada Generics (was Re: OO, C++, and something much better!)

[Robert Dewar]

Bob Gilbert asks

"Most of the Ada comilers I've used do expand the generic instantiation at
compile time.  Could somebody offer up an example of where this would not
be possible?"

No one can give you an example, because there are none. GNAT demonstrates
that it is possible to do all generic instantiation at compile time.

Note however that in a classical library model, as opposed to the source
model of GNAT, there are cases of circular instantiations which may require
some trickery to do at compile time, so one can imagine compilers with
restrictions on what can be done at compile time (by circular instantiations
here I do not mean truly circuluar, which is of course illegal), but just
mutually recursive references, e.g. two packages, each of which instantiates
from the other.

Re: OO, C++, and something much better!

[Bertrand Meyer]

In my opinion neither Ada (83 or 95) nor C++ has the combination
of mechanisms making it possible to have the full power of
generics in an object-oriented language, as present in Eiffel:

	- Unconstrained genericity, to declare a class
	  as e.g. LIST [G], where G represents an arbitrary
	  type, so that you can then use LIST [SOME_TYPE] regardless
	  of what SOME_TYPE is.

	- Constrained genericity, as in e.g. 
	  SORTED_LIST [G -> COMPARABLE], to require that
	  some operations be applicable to all actual
	  generic parameters. The rule is that
	  SORTED_LIST [SOME_TYPE] is permitted if and only
	  if SOME_TYPE inherits, directly or indirectly from
	  COMPARABLE. The -> symbol is evocative of the symbol
	  for inheritance used in class diagrams in e.g. B.O.N.
	  Within the class SORTED_LIST, any operation (feature, method)
	  of class COMPARABLE, such as infix "<" etc., is then applicable
	  to entities of type G.

	- A completely consistent type structure, in which 
	  even basic types such as INTEGER are classes,
	  present in the general inheritance structure.
	  (In C++ or Java, for example, the basic types
	  are completely separate from the class and inheritance
	  structure.)

	- True static typing (with no cast a la C++).

So in the constrained genericity case SORTED_LIST [INTEGER]
will be permitted, since COMPARABLE is indeed an existing class,
describing order relations and part of the Eiffel Library
Kernel Standard, and INTEGER (also part of ELKS) does inherit
from COMPARABLE.

SORTED_LIST [TENNIS_PLAYER] will also be
valid, assuming the user-defined class TENNIS_PLAYER inherits
from COMPARABLE. But something like SORTED_LIST [COMPLEX]
will be rejected by the compiler, assuming COMPLEX is not
a descendant of COMPARABLE.

In the unconstrained case, a declaration such as LIST [G]
is understood as an abbreviation for LIST [G -> ANY], where
ANY is the ELKS class inherited by all classes. This makes
it possible to apply objects of type G a wide range of operations
applicable to all objects: equality comparison (redefinable
in any class as long as it satisfies the original assertions),
copying, cloning, even (in the latest version of ELKS) hash
coding.

Without going into the details, I should add that Eiffel's design
for generics avoids the grave problems that one reads about in
connection with C++ templates: the need in C++ to  generate code
separately
for each generic derivation (each new actual generic parameter), with
its
rather bad effect on compilation time ("template instantiation problem")
and, as a result, the advice regularly given in the C++ literature
to avoid using templates too much. In Eiffel, you can generate
code just once (with some specific optimizations for basic types),
without having to pay any performance overhead either at compile
time or at run time. So you can use genericity as much as you like.
The ISE Eiffel libraries, for example, are generic throughout.

 
In comparison with Eiffel, not even mentioning Java with its total lack
of genericity, the other attempts at generic mechanisms that I have seen
in an O-O context look to me rather half-hearted.

I think Eiffel's consistent and complete treatment of genericity and
inheritance is one of the reasons why some of the biggest successful
industrial O-O projects have been produced in Eiffel. When the goal is
not just to play around, but to build large, mission-critical systems,
one needs the right combination of mechanisms, not just a partial
attempt.

For details about the Eiffel mechanism see the Eiffel language tutorial
at
http://www.eiffel.com.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com (WITH FRAMES)
	or http://www.eiffel.com/noframes.html

Re: OO, C++, and something much better!

[Andrew Koenig]

In article <OHK.97Jan6132731@ultra.tfdt-o.nta.no> ohk@ultra.tfdt-o.nta.no (Ole-Hjalmar Kristensen FOU.TD/DELAB) writes:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.

What Alex told me about that effort was that he was unable to find
a single Ada compiler that implemented the standard accurately enough
to enable him to do what he wanted to do with his library.
-- 
				--Andrew Koenig
				  ark@research.att.com

Re: OO, C++, and something much better!

[Ken Garlington]

Jay Martin wrote:
> 
> Since the standard was locked, it took 12 years
> before any of these problems were corrected.

Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates. As I recall, no one wanted to do an
update
on the first cycle, in order to give implementations a chance to mature.
The
second cycle ended with Ada 95.

What rule (if any) is there for ISO standard review cycles?

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Ken Garlington]

Bertrand Meyer wrote:
> 
> In my opinion neither Ada (83 or 95) nor C++ has the combination
> of mechanisms making it possible to have the full power of
> generics in an object-oriented language, as present in Eiffel:
> 
>         - Unconstrained genericity, to declare a class
>           as e.g. LIST [G], where G represents an arbitrary
>           type, so that you can then use LIST [SOME_TYPE] regardless
>           of what SOME_TYPE is.

I've seen Mr. Meyer mention this in various articles, but I've never
understood it.
What's the distinction between an Ada generic with a limited private
type as a
parameter, and an "unconstrained" generic?

>         - Constrained genericity, as in e.g.
>           SORTED_LIST [G -> COMPARABLE], to require that
>           some operations be applicable to all actual
>           generic parameters. The rule is that
>           SORTED_LIST [SOME_TYPE] is permitted if and only
>           if SOME_TYPE inherits, directly or indirectly from
>           COMPARABLE. The -> symbol is evocative of the symbol
>           for inheritance used in class diagrams in e.g. B.O.N.
>           Within the class SORTED_LIST, any operation (feature, method)
>           of class COMPARABLE, such as infix "<" etc., is then applicable
>           to entities of type G.

Isn't this also available in Ada? In particular, can't you require the
user to
provide the needed operations in the absence of visible defaults?

>         - A completely consistent type structure, in which
>           even basic types such as INTEGER are classes,
>           present in the general inheritance structure.
>           (In C++ or Java, for example, the basic types
>           are completely separate from the class and inheritance
>           structure.)

I also thought this was true of Ada. Isn't Integer actually considered
part of
the general inheritance structure of the root_integer class? [LRM
3.5.4:14?]

>         - True static typing (with no cast a la C++).


> 
> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,
> describing order relations and part of the Eiffel Library
> Kernel Standard, and INTEGER (also part of ELKS) does inherit
> from COMPARABLE.
> 
> SORTED_LIST [TENNIS_PLAYER] will also be
> valid, assuming the user-defined class TENNIS_PLAYER inherits
> from COMPARABLE. But something like SORTED_LIST [COMPLEX]
> will be rejected by the compiler, assuming COMPLEX is not
> a descendant of COMPARABLE.
> 
> In the unconstrained case, a declaration such as LIST [G]
> is understood as an abbreviation for LIST [G -> ANY], where
> ANY is the ELKS class inherited by all classes. This makes
> it possible to apply objects of type G a wide range of operations
> applicable to all objects: equality comparison (redefinable
> in any class as long as it satisfies the original assertions),
> copying, cloning, even (in the latest version of ELKS) hash
> coding.
> 
> Without going into the details, I should add that Eiffel's design
> for generics avoids the grave problems that one reads about in
> connection with C++ templates: the need in C++ to  generate code
> separately
> for each generic derivation (each new actual generic parameter), with
> its
> rather bad effect on compilation time ("template instantiation problem")
> and, as a result, the advice regularly given in the C++ literature
> to avoid using templates too much. In Eiffel, you can generate
> code just once (with some specific optimizations for basic types),
> without having to pay any performance overhead either at compile
> time or at run time. So you can use genericity as much as you like.
> The ISE Eiffel libraries, for example, are generic throughout.
> 
> 
> In comparison with Eiffel, not even mentioning Java with its total lack
> of genericity, the other attempts at generic mechanisms that I have seen
> in an O-O context look to me rather half-hearted.
> 
> I think Eiffel's consistent and complete treatment of genericity and
> inheritance is one of the reasons why some of the biggest successful
> industrial O-O projects have been produced in Eiffel. When the goal is
> not just to play around, but to build large, mission-critical systems,
> one needs the right combination of mechanisms, not just a partial
> attempt.
> 
> For details about the Eiffel mechanism see the Eiffel language tutorial
> at
> http://www.eiffel.com.
> 
> --
> Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
> 805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
> ftp://ftp.eiffel.com
> Visit our Web page: http://www.eiffel.com (WITH FRAMES)
>         or http://www.eiffel.com/noframes.html

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[David Emery]

>> 	- A completely consistent type structure, in which 
>> 	  even basic types such as INTEGER are classes,
>> 	  present in the general inheritance structure.
>> 	  (In C++ or Java, for example, the basic types
>> 	  are completely separate from the class and inheritance
>> 	  structure.)
>
>OK, here you have me.  But, Eiffel hedges a bit here as well with its
>"expanded types".

I think that there is not a clear consensus on this as A Good Thing.
From a practical perspective, there seems to be a significant price to
pay for 'full generality' (e.g. integers are classes just like
user-defined record types.)  Java, for instance, has primitive integer
types, and my understanding that the reason for this is performance,
pure and simple.  Making 'int' a class would result in unacceptable
performance, both compile-time and runtime, for simple things like
"a[i++] := b + c;" (for int a, b, c).

Language engineering design is a series of compromises between expressiveness
and efficiency (among other compromises).  Pure 'class-hood' for all
types in the system is one area where there are serious tradeoffs between
expressiveness and efficiency.

				dave
-- 
<.sig is away on vacation>

Re: OO, C++, and something much better!

[Mark A Biggar]

In article <JSA.97Jan8123334@alexandria> jsa@alexandria (Jon S Anthony) writes:
>In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
>> So in the constrained genericity case SORTED_LIST [INTEGER]
>> will be permitted, since COMPARABLE is indeed an existing class,
>
>Good point.  Lost a Minbari Cruiser on this one...

Not really as you can always say:

generic
	type G is private;
	with function "<"(L,R: G) return Boolean is <>;
package SORTED_LIST is ...

This requires that either the Type G have a "<" defined or that you provide 
one at the time of instanitation.  Of course there is nothing that requires 
that the provided function realy be a less-than function (which is usefull
as providing a ">" instead reverses the order of the list) but Eiffel has the
same problem and there is no guarentee that a class derived from COMPARABLE
hasn't redefined "<" to do something else either.

--
Mark Biggar
mab@wdl.lmco.com

Re: What is wrong with OO ?

[Richard A. O'Keefe]

ell@access1.digex.net (Ell) writes:

>Led (first or second) wrt the OO paradigm: Private data members, static
>resolution of overloaded functions, protected members, and multiple
>inheritance.

Aren't the keywords 'private' and 'protected' copied from Simula?
(The old "Common Base Language" definition didn't have them, but
they were in Simula before they were in C++.)  As for multiple
inheritance, there was a multiple-inheritance version of Smalltalk
before C++ got it.

As for static resolution of overloaded *functions*, Algol 68 had _that_
long before C was dreamed of, let alone C++.

C++ deserves the credit for getting some of these things into the hands
of the programmer on the street.  

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Robert I. Eachus]

 
      Bertrand Meyer said:

   > In my opinion neither Ada (83 or 95) nor C++ has the combination
   > of mechanisms making it possible to have the full power of
   > generics in an object-oriented language, as present in Eiffel...

     And then listed four properties, all of which are in Ada 95!

     There are differences between Ada 95 and Eiffel, for example in
the way multiple inheritance is handled.  The biggest difference
though is that the type system is normally viewed as a forest rather
than a single tree.  These differences do affect the way in which
these things are usually implemented, but they do lead to major
differences in the way the features are normally used.  (To avoid
flames from both sides: see "normally viewed" and "usually
implemented" above.  I'm talking about how generics tend to be used,
not about limitations--in either language.)

     For example, in Ada you would not require a class to be derived
from COMPARABLE if you wanted to insure that comparisons work, you
would more likely require the comparison operations directly.  (See
below.) This is usually the "right" way to do it in Ada for technical
reasons, but the real reason is that the Ada mindset sees classes as
not strictly hierarchical but as a set of non-exclusive groupings.
i.e. Just as it is sensible to ask if type A is in class B, it is also
sensible in Ada to ask or specify if a type has discriminants or if a
subtype is definite.

    A good working definition of a class in Ada is the set of all
types that match a particular generic formal part:

           type Foo is range <>; -- integer class

           type Fubar(<>) is limited private; -- The class of all classes.

           type Bar is new Foob with private; -- Foob'CLASS (for
           -- non-Ada programmers, Foob, a tagged type, or any type
           -- derived directly or indirectly from it.)
   
           -- for completeness:
           type Barf is new Foobar; -- same as above, but Barf must
           -- be definite.
       
           type Element is private;
           with function "<" (L,R: Element) return Boolean is <>;
           -- Any ordered type with assignment and equality.

     And so on...
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO, C++, and something much better!

[Kohler Markus]

>>>>> "Bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:

    Bertrand> In my opinion neither Ada (83 or 95) nor C++ has the
    Bertrand> combination of mechanisms making it possible to have the
    Bertrand> full power of generics in an object-oriented language,
    Bertrand> as present in Eiffel:

In my opinion and not only in my opinion Eiffel has NOT the full power of generics. 

Let me cite David L. Shang :

     "Unlike Eiffel, Transframe does not require runtime type checks to eliminate
     holes (a hole is defined as a leak in the specification through which an argument
     can pass the check but the type of the argument is actually wrong) in the
     supertype's interface. Instead it requires a runtime type check merely for
     flexibility in heterogeneous programming, which is exactly the case forbidden by
     some other approaches. 

     Class parameters can be used to express type dependencies. And thanks to the
     type dependency check via type assurance, a compiled Transframe program will
     never report a runtime type error. 

     Eiffel allows fields/methods in subclasses to be redefined by subtypes, which is a
     more flexible type system than that of C++. Eiffel allows covariant changes to
     types of instance variables and, as a result, it is not statically type-safe. A
     system-level type check is required but only works with a closed-world
     assumption. It seems that Eiffel's newly proposed type checking rule is too
     conservative to include a useful usage of covariance. "

See http://www.sigs.com/publications/docs/oc/9608/oc9608.c.shang.html
for  more information. 

    Bertrand> 	- Unconstrained genericity, to declare a class as
    Bertrand> e.g. LIST [G], where G represents an arbitrary type, so
    Bertrand> that you can then use LIST [SOME_TYPE] regardless of
    Bertrand> what SOME_TYPE is.

    Bertrand> 	- Constrained genericity, as in e.g.  SORTED_LIST [G
    Bertrand> -> COMPARABLE], to require that some operations be
    Bertrand> applicable to all actual generic parameters. The rule is
    Bertrand> that SORTED_LIST [SOME_TYPE] is permitted if and only if
    Bertrand> SOME_TYPE inherits, directly or indirectly from
    Bertrand> COMPARABLE. The -> symbol is evocative of the symbol for
    Bertrand> inheritance used in class diagrams in e.g. B.O.N.
    Bertrand> Within the class SORTED_LIST, any operation (feature,
    Bertrand> method) of class COMPARABLE, such as infix "<" etc., is
    Bertrand> then applicable to entities of type G.

    Bertrand> 	- A completely consistent type structure, in which
    Bertrand> even basic types such as INTEGER are classes, present in
    Bertrand> the general inheritance structure.  (In C++ or Java, for
    Bertrand> example, the basic types are completely separate from
    Bertrand> the class and inheritance structure.)

    Bertrand> 	- True static typing (with no cast a la C++).

    Bertrand> So in the constrained genericity case SORTED_LIST
    Bertrand> [INTEGER] will be permitted, since COMPARABLE is indeed
    Bertrand> an existing class, describing order relations and part
    Bertrand> of the Eiffel Library Kernel Standard, and INTEGER (also
    Bertrand> part of ELKS) does inherit from COMPARABLE.

    Bertrand> SORTED_LIST [TENNIS_PLAYER] will also be valid, assuming
    Bertrand> the user-defined class TENNIS_PLAYER inherits from
    Bertrand> COMPARABLE. But something like SORTED_LIST [COMPLEX]
    Bertrand> will be rejected by the compiler, assuming COMPLEX is
    Bertrand> not a descendant of COMPARABLE.

    Bertrand> In the unconstrained case, a declaration such as LIST
    Bertrand> [G] is understood as an abbreviation for LIST [G ->
    Bertrand> ANY], where ANY is the ELKS class inherited by all
    Bertrand> classes. This makes it possible to apply objects of type
    Bertrand> G a wide range of operations applicable to all objects:
    Bertrand> equality comparison (redefinable in any class as long as
    Bertrand> it satisfies the original assertions), copying, cloning,
    Bertrand> even (in the latest version of ELKS) hash coding.

    Bertrand> Without going into the details, I should add that
    Bertrand> Eiffel's design for generics avoids the grave problems
    Bertrand> that one reads about in connection with C++ templates:

C++ templates are far from beeing perfect, that's true.  

    Bertrand> the need in C++ to generate code separately for each
    Bertrand> generic derivation (each new actual generic parameter),
    Bertrand> with its rather bad effect on compilation time
    Bertrand> ("template instantiation problem") and, as a result, the
    Bertrand> advice regularly given in the C++ literature to avoid
    Bertrand> using templates too much. In Eiffel, you can generate
    Bertrand> code just once (with some specific optimizations for
    Bertrand> basic types), without having to pay any performance
    Bertrand> overhead either at compile time or at run time. So you
    Bertrand> can use genericity as much as you like.  The ISE Eiffel
    Bertrand> libraries, for example, are generic throughout.

 
    Bertrand> In comparison with Eiffel, not even mentioning Java with
    Bertrand> its total lack of genericity, the other attempts at
    Bertrand> generic mechanisms that I have seen in an O-O context
    Bertrand> look to me rather half-hearted.

    Bertrand> I think Eiffel's consistent and complete treatment of
    Bertrand> genericity and inheritance is one of the reasons why
    Bertrand> some of the biggest successful industrial O-O projects
    Bertrand> have been produced in Eiffel. When the goal is not just
    Bertrand> to play around, but to build large, mission-critical
    Bertrand> systems, one needs the right combination of mechanisms,
    Bertrand> not just a partial attempt.

    Bertrand> For details about the Eiffel mechanism see the Eiffel
    Bertrand> language tutorial at http://www.eiffel.com.


    Bertrand> -- Bertrand Meyer, President, ISE Inc., Santa Barbara
    Bertrand> (California) 805-685-1006, fax 805-685-6869,
    Bertrand> <bertrand@eiffel.com> - ftp://ftp.eiffel.com Visit our
    Bertrand> Web page: http://www.eiffel.com (WITH FRAMES) or
    Bertrand> http://www.eiffel.com/noframes.html



Markus
-- 
+----------------------------------------------------------------------------+
| Markus Kohler                          Hewlett-Packard GmbH                |
| Software Engineer                      Network & System Management Division| 
|                                        IT/E Success Team                   |
+----------------------------------------------------------------------------+

Re: OO, C++, and something much better!

[Matthew Heaney]

In article <32D2E6C8.13728473@eiffel.com>, Bertrand Meyer
<bertrand@eiffel.com> wrote:

>In my opinion neither Ada (83 or 95) nor C++ has the combination
>of mechanisms making it possible to have the full power of
>generics in an object-oriented language, as present in Eiffel:
>
>        - Unconstrained genericity, to declare a class
>          as e.g. LIST [G], where G represents an arbitrary
>          type, so that you can then use LIST [SOME_TYPE] regardless
>          of what SOME_TYPE is.

Ada has had that ability since the original standard:

generic
   type List_Item is private;
package Lists is
   type List is private;
   procedure Add (Item : in List_Item; To : in out List);
...


>
>        - Constrained genericity, as in e.g. 
>          SORTED_LIST [G -> COMPARABLE], to require that
>          some operations be applicable to all actual
>          generic parameters. The rule is that
>          SORTED_LIST [SOME_TYPE] is permitted if and only
>          if SOME_TYPE inherits, directly or indirectly from
>          COMPARABLE. The -> symbol is evocative of the symbol
>          for inheritance used in class diagrams in e.g. B.O.N.
>          Within the class SORTED_LIST, any operation (feature, method)
>          of class COMPARABLE, such as infix "<" etc., is then applicable
>          to entities of type G.

There are 2 ways of doing that in Ada 95.

The first (what you could already do in Ada 83) is to require that the type
have a comparison operator:

generic
   type List_Item is private;
   with function "<" (Left, Right : List_Item) return Boolean is <>;
package Sorted_Lists is
   type List is private;
...

The second (new to Ada 95) is to require that the type inherit from another:

package P is
   type T is tagged private;
   function "<" (L, R : T) return Boolean;
...
end P;

with P;
generic
   type List_Item is new P.T;
package Sorted_Lists is
   type List is private;
...

>So in the constrained genericity case SORTED_LIST [INTEGER]
>will be permitted, since COMPARABLE is indeed an existing class,
>describing order relations and part of the Eiffel Library
>Kernel Standard, and INTEGER (also part of ELKS) does inherit
>from COMPARABLE.

I can instantiate my first sorted list package, because type Integer comes
predefined with a comparison operator.

with Sorted_Lists;
package Integer_Sorted_Lists is new Sorted_Lists (Integer);


>
>SORTED_LIST [TENNIS_PLAYER] will also be
>valid, assuming the user-defined class TENNIS_PLAYER inherits
>from COMPARABLE. But something like SORTED_LIST [COMPLEX]
>will be rejected by the compiler, assuming COMPLEX is not
>a descendant of COMPARABLE.

If tennis player has a comparison operator, then I can use sorted_list
version 1.

If tennis player derives from P.T, and I can use either sorted list version
1 or 2.

>In the unconstrained case, a declaration such as LIST [G]
>is understood as an abbreviation for LIST [G -> ANY], where
>ANY is the ELKS class inherited by all classes. This makes
>it possible to apply objects of type G a wide range of operations
>applicable to all objects: equality comparison (redefinable
>in any class as long as it satisfies the original assertions),
>copying, cloning, even (in the latest version of ELKS) hash
>coding.

Technically, I should modify the sorted list as follows:

generic
   type List_Item is private;
   with function "=" (L, R : List_Item) return Boolean is <>;
   with function "<" (L, R : List_Item) return Boolean is <>;
package Sorted_Lists is ...;

That way I can let the client pass in his "=" method that replaced the
predefined one for unlimited (private) types.


>In Eiffel, you can generate
>code just once (with some specific optimizations for basic types),
>without having to pay any performance overhead either at compile
>time or at run time. So you can use genericity as much as you like.

As you can in Ada.

>In comparison with Eiffel, not even mentioning Java with its total lack
>of genericity, the other attempts at generic mechanisms that I have seen
>in an O-O context look to me rather half-hearted.

P.J. Plauger once refered to C++ as having "ugly pragmatism."  I would say
about Ada 95 that it has "beautiful pragmatism."  We humans bandy about
terms like "purity," but there's no such thing in Nature; she only cares
about what works.  I think there's room for pragmatism, though C++ probably
pushes that argument a bit too far.  N'est-ce pas?

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: OO, C++, and something much better!

[Robert Dewar]

Michael says

"ability to expand them at compile time without losing optimizations, unlike
Ada generics whose paradigm is to expand at run-time and remove staticness
from expressions."

incomprehensible confusion. there is no "run-time" expansion of generics'
in Ada, and there is no issue of losing optimizations ...

Re: OO, C++, and something much better!

[Robert Dewar]

iKen says

""Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates."


Also it was an ANSI requirement, not a MIL-STD rqeuirement to initiate
review of the standard at a five year interval.

Re: What is wrong with OO ?

[Robert Dewar]

Bart said

"You shouldn't bother programmers with inlining. Inlining can be done
automatically by the compiler."

I don't see this is possible across modules without violating the integrity
of separation of specs and implementations.

Re: OO, C++, and something much better!

[Robert Dewar]

Ken writes

"Actually, back with Ada was a MIL-STD, there was a requirement to review
it
every _five_ years for updates. As I recall, no one wanted to do an
update
on the first cycle, in order to give implementations a chance to mature.
The
second cycle ended with Ada 95."

(Ken can you keep your lines from folding, makes it hard to read your posts)

This is rewriting history. Ada was standardized in 1983, and it is definitely
NOT the case that no one thought about a revision till 1993. On the contrary,
what happened is that people *did* start thinking about a revision in the
time period consistent with the five year rule -- this rule does not say
you need a standard every five years, just that you should start to think
about it. But the process from starting to think to standardizing Ada 95
was a very long process (6-7 years, I don't have the exact starting point).

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

Wow.  The big folk are coming out.  Add in a couple others and the
whole thing might start looking like the Vorlons and Shadows! :-)

I'll play a Ranger (representing Ada, of course, ;-)


> In my opinion neither Ada (83 or 95) nor C++ has the combination
> of mechanisms making it possible to have the full power of
> generics in an object-oriented language, as present in Eiffel:

This is not surprising, ;-)

But,

> 	- Unconstrained genericity, to declare a class
> 	  as e.g. LIST [G], where G represents an arbitrary
> 	  type, so that you can then use LIST [SOME_TYPE] regardless
> 	  of what SOME_TYPE is.

This is in Ada95:
generic
    type G is private;
package List is...


> 	- Constrained genericity, as in e.g. 
> 	  SORTED_LIST [G -> COMPARABLE], to require that
> 	  some operations be applicable to all actual
> 	  generic parameters. The rule is that
> 	  SORTED_LIST [SOME_TYPE] is permitted if and only
> 	  if SOME_TYPE inherits, directly or indirectly from
> 	  COMPARABLE.

This too is in Ada95:

generic
    type G is new Comparable with private;
package Sorted_List is ...

Same instantiation constraints as in the Eiffel case...


> 	- True static typing (with no cast a la C++).

Yes, this is in Ada95 too.  In fact it is better in Ada95 since it
does not have system validity problems.


> 	- A completely consistent type structure, in which 
> 	  even basic types such as INTEGER are classes,
> 	  present in the general inheritance structure.
> 	  (In C++ or Java, for example, the basic types
> 	  are completely separate from the class and inheritance
> 	  structure.)

OK, here you have me.  But, Eiffel hedges a bit here as well with its
"expanded types".


> So in the constrained genericity case SORTED_LIST [INTEGER]
> will be permitted, since COMPARABLE is indeed an existing class,

Good point.  Lost a Minbari Cruiser on this one...


> In the unconstrained case, a declaration such as LIST [G]
> is understood as an abbreviation for LIST [G -> ANY], where
> ANY is the ELKS class inherited by all classes. This makes

Same as in Ada.


> it possible to apply objects of type G a wide range of operations
> applicable to all objects: equality comparison (redefinable
> in any class as long as it satisfies the original assertions),
> copying, cloning, even (in the latest version of ELKS) hash
> coding.

Here is where you actually get some more flexibility with Ada as you
can parameterize your generic (either the constrained or unconstrained
type) with more than just types.  You can specify complete signatures
including operations and/or packages as well.  What's more, these can
have constraints on them as well.  Of course, it doesn't have real
assertions, so I suppose this is kind of a wash...


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Robert Dewar]

Jay, in typical fulminating mode says

 "It seems to me need for "pragma inline" and "inline" is/was social.
 It came from compiler writers continually slacking off since the 60's
 and not implementing inlining."

nonsense, all decent compilers implement inlining today, it is a more
vital optimization than ever because of icache considerations (particularly
in direct addressed caches).

The pragma inline in Ada is simply a permission to create a dependence
on the body, it has nothing to do with what you think of informally as
inlining.

In a large project it is essential not to accidentally create interunit
dependences so that a small change to one unit causes millions of lines
to need to be recompiled.

There is of course no problem in implementing automatic inlining within
a unit. As I said earlier, virtually all production compilers do this,
including of course GCC.

The problem is that you definitely do NOT want the compiler rushing off
and creating unlimited body dependencies (think interunit dependencies
if you don't want to think Ada specifically) by doing automatic interunit
inlining.

Still some interunit inlining is highly desirable especially with
heavy layering of abstractions. But you want to give the programmer
some control, to avoid the problem of inter-unit dependencies running
amok!

Re: What is wrong with OO ?

[Bjarne Stroustrup]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

 > 
 > Bjarne Stroustrup wrote:
 > 
 > > Only where I couldn't find a solution that fitted in C++'s general
 > > framework and met my criteria for run-time efficiency, ease of
 > > implementation, ease of teaching, etc. (see D&E Chapter 4), did I
 > > feel compelled to try to invent something.
 > 
 > When I read this, a lot of questions pop up in my head. I'll ask only
 > one: You've only included features that didn't compromise ease of
 > teaching (at least, that's my interpretation of what you wrote). Why is
 > it then, that C++ contains so many hidden 'features' (or rather,
 > non-explicit rules) that confuse people, at least at my university?

In addition to giving an answer to you ``only one'' question, I will
comment on some of the pretty strong statement you made afterwards -
lest silence should be taken for agreement, lack of counter arguments,
or arrogance.

I'm not sure which hidden_features/non-explicit_rules you are referring
to, but I do have some experience with the teaching, learning, and use
of C++ that might be relevant.


First, here is the way I phrased the "learning" criteria in "The Design
and Evolution of C++":

	If in doubt, pick the variant of a feature that is easiest to teach

	This is a secondary rule for choosing between alternatives.
	It is tricky to apply because it can be an argument for logical
	beauty and also for sticking to the familiar. Writing tutorials
	and reference manual descriptions to see how easy they are for
	people to understand is a practical application of this rule.
	One intent is to ease the task for educators and support personnel.
	It is important to remember that programmers are not stupid;
	simplicity mustn't be achieved at the expense of important
	functionality.

It is one of about twenty such rules of thumb I rely on.


C++ is a language primarily aimed at creating production software. Like
all such languages, it together with its associated libraries, tools, and
programming techniques is too large to learn quickly (unless you happen
to be experienced in rather similar languages and techniques - and most
students and programmers are not when they first encounter C++).
Consequently, it must be learned in stages starting with some suitable
subset (and a suitable subset of tools, libraries, programming techniques).

Many are too ambitious and try to learn too much too fast. In particular,
many programmers focus on learning every obscure language detail rather
than overall principles because mastery of programming language details
is what has traditionally been valued in many programming communities.
That way, people get lost in details.

That, together with the common mistake of chosing "all of C" as the
initial subset of C++ to learn have led many into trouble. These problems
are avoidable. In particular, only a relatively small part of the common
C and C++ subset needs to be understood before one can approach the
abstraction mechanisms that are the essential part of C++.

Traditionally, C++ has been blessed with a mass of useful libraries, and
cursed by the absence of a good standard library. The lack of a standard
library supplying basic types (such as string, list, and map) reinforced
the bias of some teachers and some teaching materials towards low-level
features and techniques that don't rely on standard library facilities.

C++ now has a nice standard library and most implementation now are shipped
with a reasonable approximation to it. However, the effects of its initial
absence (primarily my fault) still lingers in teaching methods and teaching
materials.

C++ caught on very fast. This led to people "joining the bandwagon"
without actually understanding what the important ideas were. Many times,
I have cringed seeing what riduculous statements were made about C++
and its proper use. For example, an early textbook proudly gave an
airplane derived from an engine as its first example of object-oriented
programming. Naturally, that author had never written a real C++ program
in his life or a real program in any other programming language supporting
object-oriented programming. Fortunately, he later jumped on another
bandwagon and is now pushing some other OO language.

I have no idea if any of this apply at your university, but I have seen
all of those phenomena repeatedly. Usually, people manage in the end, and
if not they try something else - which they may or may not find more
suitable.

I provide more details about learning and teaching C++ in "The Design
and Evolution of C++" (D&E) and on my homepages. C++ can be - and often
is - taught effectively to people of a wide variety of backgrounds and
with widely varying needs.


 > As far as I'm concerned, C++ is not a language for teaching. It has too
 > many of these implicit rules to be logical, and the fact that it
 > doesn't have garbage collection and does have pointers really makes it
 > error-prone; especially for beginning programmers, this is not a good
 > thing. They should be writing WHAT should be done, and ALL that should
 > be done; they shouldn't be bothered with the 'how' part of programming,
 > like (with alternatives): memory management (garbage collection),
 > pointers (references), virtual functions (can be detected by the
 > compiler). They should not be bothered with implicit rules (like the
 > multiple inheritance rules, for instance) that they have to know of,
 > before using multiple inheritance.
 > 
 > C++ is an excellent language as an extension to C, but C is altogether
 > obsolete and much too low-level, except for systems programming, and
 > other languages are now available for writing high-level software.
 > Many people make the (IMO huge) mistake of using C++ for high-level
 > software projects, leading to buggy results and, often, lots of core
 > dumps. Programmers are not perfect, and C++ expects them to be so by
 > providing too many ways of making mistakes.

I'm not sure about what you call a "high-level software project" but
C++ has been applied successfully often enough for your description
of the results of using C++ to be a carricature. There has been failures
involving every programming language that has ever been used for
production code. Since there has been more use of C++ than for any
other comparable language, I would expect there to have been more
with C++. However, I use C++ software daily that doesn't dump. There
are many C++ programs out there that works correctly month in and month
out. Reliability and mainatainability can be eased by a programming
language (such as C++) but is the result of a more comprehensive
process.

C++ is a programming language, so it doesn't have expectations, but I
- as its designer - never suffered from the delution that programmers
were anywhere near perfect. Nor did I suffer from the delusion that
I knew enough to put restrictions in place to constrain every programmer
without exception or escape.


 > Languages like Eiffel (my personal favorite) are much more suitable for
 > high-level projects; Eiffel, for instance, does not burden the
 > programmer more than needed, and has a clean, clear syntax that can
 > even be immediately understood by people that don't know the language.

I do not personally find it so, and such claims reminds me unpleasently
of the similar claims made for COBOL. A non-programmer can sometimes be
convinced that he/she can read simple code, but it is far from obvious
that this is relevant - or ever true - for production code (that will only
be seen by programmers anyway). 


 > > Much of C++'s success has to do with fitting into existing
 > > environments and being compact and fast (yes, I know that these are
 > > not the aspects of C++ that are currently emphasized in the
 > > MS Windows world). The speed and compactness of code generated from
 > > C++ depends on a few fundamental design decisions that I think were
 > > novel at the time:
 > 
 > Speed and compactness is certainly a goal that C++ has achieved. But it
 > did not achieve one major goal: ease of use.

I wonder how you would measure ``ease of use'' objectively. For starters:
``ease of doing what kind of work?'' ``ease for whom?'' C++ isn't the
easiest programming language to learn and to use, but for a rather large
range of systems, a large range of applications, and a large range of
developer communities, it seems to be the easiest language out of those
that can actually help get the work done.

Had C++ not been relatively easy to learn and use reasonably well, it
would have disappeared long ago. By relative I mean the amount of effort
needed compared to the amount of benefit gained.


 > >         C++ offers inline member and non-member functions with zero
 > >         overhead compared to macros.
 > 
 > You shouldn't bother programmers with inlining. Inlining can be done
 > automatically by the compiler.

Not really. Some compilers can do some inlining well, but for larger
programs the compiler is hampered by having incomplete information
and by not having a particularly good idea of what optimizations are
relevant in various part of the code. Explicit inlining is a pretty
good way of giving programmers some control for the common cases where
a compiler isn't smart enough without tying users up with proprietary
and non-standard control features. Used well, inlining can make a major
difference in speed and code compactness.


 > >         C++ offers its form of dynamic (run-time) resolution, virtual
 > >         functions, with low and fixed overhead compared to ordinary
 > >         function calls (20% to 100% dependent of implementation).
 > 
 > Virtual functions must be explicitly specified. This can be done by the
 > compiler. And, virtual functions must be specified in the ancestor
 > class; this means that when a class designer forgot to put that in
 > (and this happens often), I can't redefine the function correctly.

Deciding which member functions should be virtual is a design decision,
not an optimization. If a designer has provided a poor base class, you
will typically have problems beyond what can be fixed by overriding.


 > > Over the years, C++ has evolved within a framework that was reasonably
 > > well understood early on.
 > 
 > Well understood, yes. But the framework is now obsolete, and it has
 > some serious design flaws that also bother C++ users.

Certainly there are flaws - I don't know of a language that doesn't have
flaws, and I consider the idea of a widely-used flawless language nonsense.

Once a language is used by diverse user communities, one person's serious
flaw becomes another's essential feature. Some of the aspects of C++ that
I dislike most are deemed essential by very competent system builders.
However, C++ has no flaw and no feature lacking that is so serious that
it cannot be managed with reasonable effort in a project - even if they
can be a bother and experienced programmers recognize them as such.

I do not consider C++ or its basic conceptual framework obsolete nor
do I know an alternative that could replace it in the next few years.
Like it or not, programming languages have lifecycles that span decades,
and "obsolete" often means little more than "not in accordance with the
latest fad." For most builders of real-world software a ten-year-old
language is a newborn. ``OO'' itself is more than 25 years old and we
are still learning about it - even those of us who have been part of the
process through most of those years.

The world is a whole lot messier than we would like it to be, and some of
that messiness is reflected in every successful programming language.

Good luck with your projects and the language you favor, and remember
that the world is more complicated that any of us can imagine and that
there are ways of succeeding that we would not personally have chosen.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html
	
 
 >    Bart Samwel  (bsamwel@wi.leidenuniv.nl)
 > 
 > 

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:In article <32D2E6C8.13728473@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:
:
:Wow.  The big folk are coming out. 

:)

:> 	- Unconstrained genericity, to declare a class
:> 	  as e.g. LIST [G], where G represents an arbitrary
:> 	  type, so that you can then use LIST [SOME_TYPE] regardless
:> 	  of what SOME_TYPE is.
:
:This is in Ada95:
:generic
:    type G is private;
:package List is...

Yes.

:> 	- Constrained genericity, as in e.g. 
:> 	  SORTED_LIST [G -> COMPARABLE], to require that
:> 	  some operations be applicable to all actual
:> 	  generic parameters. The rule is that
:> 	  SORTED_LIST [SOME_TYPE] is permitted if and only
:> 	  if SOME_TYPE inherits, directly or indirectly from
:> 	  COMPARABLE.
:
:This too is in Ada95:
:
:generic
:    type G is new Comparable with private;
:package Sorted_List is ...
:
:Same instantiation constraints as in the Eiffel case...

Yes. However, I'm not sure whether you lose some of the power of combining 
genericity with inheritance through Ada's module-type distinction. Since 
genericity in Ada is essentially module-based and inheritance is type-based,
I suspect you may lose something here.

:> 	- True static typing (with no cast a la C++).
:
:Yes, this is in Ada95 too.  

No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't 
to say it isn't needed for some things (and is why some vendors do provide 
type conversion between basic types and bits, for example). 

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :) 

:In fact it is better in Ada95 since it
:does not have system validity problems.

Perhaps not the same kind of problems. But it's dead easy to write 'system
invalid' Ada which will result in runtime errors. For example, by using the 
value of a parent type where a subrange value is required.

[...]

:> it possible to apply objects of type G a wide range of operations
:> applicable to all objects: equality comparison (redefinable
:> in any class as long as it satisfies the original assertions),
:> copying, cloning, even (in the latest version of ELKS) hash
:> coding.
:
:Here is where you actually get some more flexibility with Ada as you
:can parameterize your generic (either the constrained or unconstrained
:type) with more than just types.  You can specify complete signatures
:including operations and/or packages as well.  What's more, these can
:have constraints on them as well.  

Yes. However, these kinds of formal parameters are only needed in Ada because
it distinguishes between module and type. Eiffel's unification of module and
type obviates the need for them. :)  Eiffel's genericity mechanism is also
simpler because it is a *pure* OOPL compared to hybrid Ada.

:Of course, it doesn't have real
:assertions, so I suppose this is kind of a wash...


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Bart said
>
>"You shouldn't bother programmers with inlining. Inlining can be done
>automatically by the compiler."
>
>I don't see this is possible across modules without violating the integrity
>of separation of specs and implementations.

So?  Why is it so important to preserve the "integrity of separation"?

I prefer compilers that provides a full range of trade-offs between
(re)compilation speed and the efficiency of the generated code.  In
most circumstances, programmers are best served by a compiler that
compiles fast during development (when you want to avoid cross-module
inlining, to avoid unnecessary recompilation) but that can pull out all
stops for the optimized version.

There are times when you want optimizations yet you want to avoid
cross-module optimizations, but those should be exceptions;
automatic cross-module inlining ought to be the norm.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Richie Bielak]

Fergus Henderson wrote:

[...]
 
> I prefer compilers that provides a full range of trade-offs between
> (re)compilation speed and the efficiency of the generated code.  In
> most circumstances, programmers are best served by a compiler that
> compiles fast during development (when you want to avoid cross-module
> inlining, to avoid unnecessary recompilation) but that can pull out all
> stops for the optimized version.
> 
> There are times when you want optimizations yet you want to avoid
> cross-module optimizations, but those should be exceptions;
> automatic cross-module inlining ought to be the norm.
> 

Optimizations that require global analysis of all the classes
of a program at compile time do not work if we need dynamic loading
of classes at runtime, because adding a new class to a running system
may invalidate optimizer's assumptions.

...richie

-- 
* richieb@netlabs.net       - at home |  Richie Bielak             *
* richieb@calfp.com         - at work |                            *
*          Home page:   http://www.netlabs.net/hp/richieb          *
*        "Fight software piracy, use free software!" (me)          *

Re: What is wrong with OO ?

[William Clodius]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.

There are two aspects of the concept of integrity logical and physical.
Inlining disobeys physical integrity, but obeys logical integrity if the
final result of the computation does not ("significantly") affect the
final result of a computation. Under the "as if" rules of most
standards, the compiler writer should primarilly concerned with logical
consistency. However, as the inlining can result in intermodule
dependencies that, on modification of the module containing the inlined
code, can result in a chain of recompilations, I would probably not
recomend that such inlining be the default for the compiler, but it is
certainly allowable (perhaps advisable) as an optional switch in the
compilation process.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: What is wrong with OO ?

[Simon Willcocks]

In article <dewar.852772995@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) says:
>
>Bart said
>
>"You shouldn't bother programmers with inlining. Inlining can be done
>automatically by the compiler."
>
>I don't see this is possible across modules without violating the integrity
>of separation of specs and implementations.
>
I take it you're coming from an Ada perspective, where each package can
be separately compiled without any information from other packages'
implementations?

I think that even in this case inlining could be done by a suitable linker,
provided the compiler could mark parts of object code as suitable for inlining.
The linker could insert the relevant code in place of the call statement,
rather than just setting the location to be called.

Simon Willcocks

Re: OO, C++, and something much better!

[Ted Dennison]

Robert Dewar wrote:
> 
> Ken writes
> 
> "Actually, back with Ada was a MIL-STD, there was a requirement to review
> it
> every _five_ years for updates. As I recall, no one wanted to do an
> update
> on the first cycle, in order to give implementations a chance to mature.
> The
> second cycle ended with Ada 95."
> 
> (Ken can you keep your lines from folding, makes it hard to read your posts)

In particular, when your newsposter automaticly wraps text for you, you
really have no choice but to let it. Trying to terminate lines manually
will just lead to tough to read text. But its a damn tough habit to get
out of, once you are used to hitting that return key at the end of the
line.

> This is rewriting history. Ada was standardized in 1983, and it is
> definitely NOT the case that no one thought about a revision till
> 1993. On the contrary, what happened is that people *did* start 
> thinking about a revision in the time period consistent with the five

Does that mean that they ALSO started thinking about the revision again
in 1993, even though the Ada 95 effort was well underway?  ;-)




-- 
T.E.D.          
             |  Work - mailto:dennison@escmail.orl.lmco.com  |
             |  Home - mailto:dennison@iag.net               |
             |  URL  - http://www.iag.net/~dennison          |

Re: What is wrong with OO ?

[Bertrand Meyer]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.


The ISE Eiffel compiler performs inlining completely automatically.
There is no "pragma inline" or comparable programmer intervention,
since it is not the programmer's job to worry about whether a routine
is inlinable or not. This is a job for a compiler.

(In addition, for an object-oriented language, inlining is only
possible for a routine that is never subject to dynamic binding.
This requires extensive analysis of the software. If the programmer
requests
inlining but it is semantically wrong, the compiler should ignore
the request. But then if the compiler is capable of doing this analysis
it should take care of the inlining too, without bothering the
programmer!)

ISE Eiffel does give the user a degree of parameterization:
a compilation option specifies the size threshold beyond which
a routine will not be inlined. This is measured in internal units
(number of bytecode words), but easy to relate to number of
instructions. This option provides a way to control space-time
tradeoffs. In practice, however, most users are happy with the
default, which inlines small, frequently called routines.

This automatic optimization is crucial because the object-oriented
style of development, with its emphasis on  abstraction, naturally
tends to yield many small routines. With ISE Eiffel, you can write the
software as it should be, not asking yourself all the time "should
I violate abstraction here and avoid writing a small routine because
of the effect on performance?". You just leave this kind of concern
to the compiler. ("Inline" pragmas would be almost worse here, because
you would have to perform yourself the analysis of what is inlinable
and what is not. The incrementality problem is particularly nasty:
change a single line somewhere in a large system, and a routine that was
inlinable,
far away in the software text, now becomes  non-inlinable! This
kind of systematic, exhaustive  work, error-prone when done
by humans, is what computers are for.)

I also think that the Eiffel view of "separation of specs and
implementations"
is more sophisticated than Ada's one (which I assume is the one Robert
Dewar has in mind), but that will be the topic for another debate...



-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com  or
http://www.eiffel.com/noframes.html
	(includes instructions for downloading ISE Eiffel 4 for Windows)

Re: OO, C++, and something much better!

[Bertrand Meyer]

Robert I. Eachus wrote:
> 
> 
>       Bertrand Meyer said:
> 
>    > In my opinion neither Ada (83 or 95) nor C++ has the combination
>    > of mechanisms making it possible to have the full power of
>    > generics in an object-oriented language, as present in Eiffel...
> 
>      And then listed four properties, all of which are in Ada 95!

I disagree. What Mr. Eachus showed in his message is ways to achieve
in Ada 95 the effect of the object-oriented mechanisms I described,
as implemented in Eiffel. And he is correct that one can use Ada 95
to obtain many of the same goals. (This would not be true, for example,
of C++ and even less of Java.) But this does not mean the "four
properties" that I listed are in Ada 95. Anyone who checks my
message and the Ada 95 language definition will see that.


To the four properties listed in my original I should also add two
just as essential requirements: true multiple inheritance, for combining
different abstractions (and with the right mechanisms to avoid any
ambiguity or conflict); and, most importantly, Design by Contract
and the rules on how assertions combine with inheritance. As someone
remarked, it is really impossible to understand inheritance without
understanding Design by Contract.


At some point, of course, one runs into matters of taste. I will
again contend, however, that a rational, systematic analysis of
O-O principles and how they combine with genericity, information hiding
and other software engineering concerns almost inevitably lead to the
Eiffel mechanisms.

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Ken Garlington]

Robert Dewar wrote:
> 
> Bart said
> 
> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the integrity
> of separation of specs and implementations.

Actually, with some Ada compilers, you _can_ do inlining automatically,
by
setting the optimization level high enough.
--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: What is wrong with OO ?

[Robert Dewar]

Simon said

'I take it you're coming from an Ada perspective, where each package can
be separately compiled without any information from other packages'
implementations?

I think that even in this case inlining could be done by a suitable linker,
provided the compiler could mark parts of object code as suitable for inlining.
The linker could insert the relevant code in place of the call statement,
rather than just setting the location to be called."


Right (Ada persepective, and indeed C is the same, where you see the headers
and not bodies of other units).

Inlining is MUCH more than just sticking in the code at the point of call
and cannot be done at all by a stupid linker. The whole point of inlining
is that you optimize the code that is inserted, minimally by increasing
scheduling opportunities, but in the presence of global optimization, knowing
what the body of a procedure does and does not do can buy a great deal. The
elimination of the call itself is small stuff compared to the other gains.

Re: OO, C++, and something much better!

[Don Harrison]

David Emery writes:

:>> 	- A completely consistent type structure, in which 
:>> 	  even basic types such as INTEGER are classes,
:>> 	  present in the general inheritance structure.
:>> 	  (In C++ or Java, for example, the basic types
:>> 	  are completely separate from the class and inheritance
:>> 	  structure.)
:>
:>OK, here you have me.  But, Eiffel hedges a bit here as well with its
:>"expanded types".
:
:I think that there is not a clear consensus on this as A Good Thing.
:From a practical perspective, there seems to be a significant price to
:pay for 'full generality' (e.g. integers are classes just like
:user-defined record types.)  Java, for instance, has primitive integer
:types, and my understanding that the reason for this is performance,
:pure and simple.  Making 'int' a class would result in unacceptable
:performance, both compile-time and runtime, for simple things like
:"a[i++] := b + c;" (for int a, b, c).

Eiffel expanded types (one of which is class INTEGER) are not accessed via
references so do not carry that overhead. Hence, they can be implemented as 
efficiently as Ada/C++ integers.

However, if you *do* need to define a more specific integer type, you can
inherit from the parent (reference) type, INTEGER_REF.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Jay Martin]

Bertrand Meyer <bertrand@eiffel.com> writes:

>Robert Dewar wrote:
>> 
>> Bart said
>> 
>> "You shouldn't bother programmers with inlining. Inlining can be done
>> automatically by the compiler."
>> 
>> I don't see this is possible across modules without violating the integrity
>> of separation of specs and implementations.


>The ISE Eiffel compiler performs inlining completely automatically.
>There is no "pragma inline" or comparable programmer intervention,
...

It seems to me need for "pragma inline" and "inline" is/was social.
It came from compiler writers continually slacking off since the 60's
and not implementing inlining.  Its hard to blame them as it didn't
seem a market priority due a totally irresponsible and incompetent
Computer Science Academia which produced a generation of programmers
who think "C" is Computer Science and had the attitude that it was the
job of programmers not compilers to do optimizations and said such
things as "I do low level pointer arithmetic so that my COMPILER runs
faster (a top UC Berkeley Graduate).  Pragma inline gave us a hammer
to which to pound the compiler writers into submission.

Jay

Re: What is wrong with OO ?

[Robert Dewar]

"So?  Why is it so important to preserve the "integrity of separation"?"

  No comment, let's just say that there are those of us who think the
  separation at an abstract level between specification and implementation
  is important. I am quite aware that there lots of C programmers who not
  only don't agree, they don't even understand what I am talking about!!

There are times when you want optimizations yet you want to avoid
cross-module optimizations, but those should be exceptions;
automatic cross-module inlining ought to be the norm.

  I think not. You can only do cross-module inlining if every compilation
  potentially recompiles code for the entire application. This seems out
  of the question in large applications.

  It seems to me here that the Ada approach is just right. Fergus, if you
  are aware of the Ada approach, what would you change?

Re: OO, C++, and something much better!

[Robert Dewar]

Don Harrison says

"No. Ada offers type casting in a couple of ways:

  1) UNCHECKED_CONVERSION and
  2) Address representation clauses (overlays).

Eiffel, by contrast, has no such thing in the standard language. That isn't
to say it isn't needed for some things (and is why some vendors do provide
type conversion between basic types and bits, for example).

I have been trying to think of a safe way of doing this sort of thing but
thus far haven't thought of any. :)"


Well there obviously is no safe way of doing something whose entire purpose
is to allow unsafe operations!

Still I would not characterize these as "type casting" in Ada. Rather I 
would think of them as loopholes, equivalent to calling a C or assembly
routine. Any formal analysis or discussion of the type system of Ada
has to ignore these features, and of course any real language to be used
for low level systems programming needs such features, but I don't think
it is a useful excercise to include these features in the type analysis.

If you like, consider Ada *minus* these two features as the interesting
language to be analyzed. Then understand that in real life programs can
break the bounds of this analysis to the extent they need to.

Note that it is not actually the unchecked conversion that is nasty, since
the fundamental conversion can be modeled as simply a random mapping between
values of one type to values of another type. It is that these operations
can generate abnormal values. 

This may still not be a problem, given that uninitialized values can also
be abnormal, thus:

  a := nasty_unchecked_conversion (b);

is no worse that not assigning to a at all if a is uninitialized.

Re: What is wrong with OO ?

[Robert Dewar]

Bertrand says

"This automatic optimization is crucial because the object-oriented
style of development, with its emphasis on  abstraction, naturally
tends to yield many small routines. With ISE Eiffel, you can write the
software as it should be, not asking yourself all the time "should
I violate abstraction here and avoid writing a small routine because
of the effect on performance?". You just leave this kind of concern
to the compiler. ("Inline" pragmas would be almost worse here, because
you would have to perform yourself the analysis of what is inlinable
and what is not. The incrementality problem is particularly nasty:
change a single line somewhere in a large system, and a routine that was
inlinable,
far away in the software text, now becomes  non-inlinable! This
kind of systematic, exhaustive  work, error-prone when done
by humans, is what computers are for.)"


This misunderstands the function of pragma Inline in Ada. This is NOT
a directive that the compiler should inline the function, not at all,
it is simply a permission to establish a compilation dependency on the
body, an obvious prerequisite for permitting the inlining.

If you want to let the compiler do unlimited automatic inlining, then 
you simply label every visible function as being pragma Inlined. Then
the compiler has complete freedom to inline anything. Of course it will
still only inline things if it makes sense to do so, which is something
that requires a lot of low level input (just measuring the number of
bytes of code is far too crude).

If it was consdered useful to allow unlimited inlining in Ada, it would
be trivial, and very much within the spirit of the language to add a
configuration pragma Inline_All (implementations of Ada are allowed to
add such configuration pragmas, or it could simply be a compiler switch).

To implement such a switch would be about thirty minutes work in GNAT, but
I doubt it would be found to be of much use in practice, certainly no one
has indicated an interest in such a switch. On the contrary, in large 
programs, people are VERY concerned about compilation dependencies. If
any change to any unit requires recompiling ten million lines of code,
then even with a fast compiler, the impact on development productivity
is worrisome.

Re: OO, C++, and something much better!

[Don Harrison]

Mark A Biggar writes:

:Of course there is nothing that requires 
:that the provided function realy be a less-than function (which is usefull
:as providing a ">" instead reverses the order of the list) but Eiffel has the
:same problem and there is no guarentee that a class derived from COMPARABLE
:hasn't redefined "<" to do something else either.

While it wouldn't be possible in this case, a level of confidence can be 
provided in other situations using Eiffel postconditions.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Ken Garlington]

Bertrand Meyer wrote:
> 
> ISE Eiffel does give the user a degree of parameterization:
> a compilation option specifies the size threshold beyond which
> a routine will not be inlined. This is measured in internal units
> (number of bytecode words), but easy to relate to number of
> instructions. This option provides a way to control space-time
> tradeoffs. In practice, however, most users are happy with the
> default, which inlines small, frequently called routines.

This is the way the Ada compilers we use work as well. Here is an
excerpt from one of the compiler manuals:

Optimize=<argument>, where <argument> is:

minimum  - pragma Inlines are not obeyed.
low      - pragma Inlines are not obeyed.
standard - some inline expansion
time     - aggressive inline expansion
space    - inline expansion only if smaller code results

This is, of course, compiler specific (outside the language standard).
I assume this is the case for Eiffel as well, since you called out a
specific compiler implementation?

> This automatic optimization is crucial because the object-oriented
> style of development, with its emphasis on  abstraction, naturally
> tends to yield many small routines. With ISE Eiffel, you can write the
> software as it should be, not asking yourself all the time "should
> I violate abstraction here and avoid writing a small routine because
> of the effect on performance?". You just leave this kind of concern
> to the compiler. ("Inline" pragmas would be almost worse here, because
> you would have to perform yourself the analysis of what is inlinable
> and what is not. The incrementality problem is particularly nasty:
> change a single line somewhere in a large system, and a routine that was
> inlinable,
> far away in the software text, now becomes  non-inlinable! This
> kind of systematic, exhaustive  work, error-prone when done
> by humans, is what computers are for.)

This is the way we approach our Ada software, as well. We generally use
pragma
Inline for extreme cases, where we know that our choice is smarter than
the
compiler's...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E3nFFy.C17@research.att.com> ark@research.att.com (Andrew Koenig) writes:

> > However, if I remember correctly, Alex Stepanov had earlier tried to
> > implement a library like the C++ STL in Ada, but was incapable of
> > doing it. This would indicate that the C++ template mechanism is more
> > flexible than the Ada generics.
> 
> What Alex told me about that effort was that he was unable to find
> a single Ada compiler that implemented the standard accurately enough
> to enable him to do what he wanted to do with his library.

 10+ years ago...  I wonder how well then he would have been able to
get a C++ compiler to do anything with any kind template ...  AFATG,
_today's_ C++ compilers have had more than their share of trouble with
these - and with the STL too.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robb Nebbe]

Bertrand Meyer wrote:
> 
> Robert I. Eachus wrote:
> >
> >
> >       Bertrand Meyer said:
> >
> >    > In my opinion neither Ada (83 or 95) nor C++ has the combination
> >    > of mechanisms making it possible to have the full power of
> >    > generics in an object-oriented language, as present in Eiffel...
> >
> >      And then listed four properties, all of which are in Ada 95!
> 
> I disagree. What Mr. Eachus showed in his message is ways to achieve
> in Ada 95 the effect of the object-oriented mechanisms I described,
> as implemented in Eiffel. And he is correct that one can use Ada 95
> to obtain many of the same goals. (This would not be true, for example,
> of C++ and even less of Java.) But this does not mean the "four
> properties" that I listed are in Ada 95. Anyone who checks my
> message and the Ada 95 language definition will see that.

Actually anyone who checks your message and the Ada language definition
will see that Ada provides direct support for the four properties you
listed but of course it doesn't use the same terminology (constrained
and unconstrained genericity) as Eiffel. 

Robb Nebbe

Re: OO, C++, and something much better!

[Matt Austern]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2012 bytes --]


kst@aonix.com (Keith Thompson) writes:

> In <dewar.852652911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Actually, when I talked to Alex, he indicated that there were critical
> > features in Ada 95 that were missing in C and C++ for this kind of
> > work. In particular, he noted that C lacks a general address comparison
> > operation, useful for hashing data structures, whereas Ada does have such
> > an operation (in System.Storage_Elements on type Integer_Address). It is
> > a bit ironic to identify this particular feature as crucial (since most
> > people mistakenly think that C has such a feature and Ada doesn't!)
> 
> Well, sort of.
> 
> It's true that C pointer comparison is undefined unless the pointers being
> compared point into the same object (or one past the end of an array).
> However, any real-world C implementation isn't going to go out of its
> way to make such comparisons invalid.  If pointers "look like" integers
> at the hardware level, pointer comparison is almost certainly going to be
> implemented as integer comparison.  It may be signed or unsigned, but it's
> almost certainly going to be consistent within a given implementation.

Since this article is posted to several different groups, including 
comp.lang.c++, I'd like to point out that the situation in C and in 
C++ is somewhat different.

Keith's description is correct in the case of C.  In C++, though, it's
only part of the story.  Pointer comparison in C++ using the <
operator does work just the way that he says; C++ didn't change the
meaning of the < operator.  However, C++ includes another way of
comparing the magnitude of two values: the standard library function
object less<T>.  

Operator< isn't necessarily a total ordering on pointers, but less<T>
is.  To quote the draft standard (section 20.3.3): "For templates
greater, less, greater_equal, and less_equal, the specializations for
any pointer type yield a total order, even if the built�in operators
<, >, <=, >= do not."

Re: OO, C++, and something much better!

[Marky Mark]

Don Harrison <donh@syd.csa.com.au> wrote in article
<E3rDu6.7AJ@syd.csa.com.au>...
> David Emery writes:
> 
> :>> 	- A completely consistent type structure, in which 
> :>> 	  even basic types such as INTEGER are classes,
> :>> 	  present in the general inheritance structure.
> :>> 	  (In C++ or Java, for example, the basic types
> :>> 	  are completely separate from the class and inheritance

Besides, in a hybrid language like C++ you could always have the best of
both worlds - encapsulating integers as classes or using the intrinsics as
you'd like.

Re: What is wrong with OO ?

[Marky Mark]

All you guys are talking about is inlining some code!!  Is it really worth
this long thread?

Re: What is wrong with OO ?

[Ken Garlington]

Fergus Henderson wrote:

> Hence this control should normally be expressed via
> compiler options, rather than being embedded in the source code.

However, you can't usually specify compiler options in a language
definition.
In practice, many of the capabilities expressed in the Ada language spec
as
pragmas are often available as compiler options, including pragma
Inline.

> 
> --
> Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
> WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
> PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E3q536.31D@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jon S Anthony writes:
> 
> :This too is in Ada95:
> :
> :generic
> :    type G is new Comparable with private;
> :package Sorted_List is ...
> :
> :Same instantiation constraints as in the Eiffel case...
> 
> Yes. However, I'm not sure whether you lose some of the power of combining 
> genericity with inheritance through Ada's module-type distinction.

I have never seen any example supporting your "unease" - by you or
anyone else.

> genericity in Ada is essentially module-based and inheritance is type-based,
> I suspect you may lose something here.

Presumably you forgot to add "only" to "inheritance is type-based".
But this is just plain false.  Counter-examples are everywhere.


> :> 	- True static typing (with no cast a la C++).
> :
> :Yes, this is in Ada95 too.  
> 
> No. Ada offers type casting in a couple of ways:
> 
>   1) UNCHECKED_CONVERSION and
>   2) Address representation clauses (overlays).

1. This is not "casting"
2. It's irrelevant anyway as these are type system trap doors (outside
   the type system).
3. Ada _is_ statically safer than Eiffel as it avoids broken polymorphism.

> Eiffel, by contrast, has no such thing in the standard language. That isn't 

Irrelevant.

> :In fact it is better in Ada95 since it
> :does not have system validity problems.
> 
> Perhaps not the same kind of problems. But it's dead easy to write 'system
> invalid' Ada which will result in runtime errors.

Only if you _intentionally_ do so - by using UC in a dodgy way.  You
won't get it "by accident".


> For example, by using the value of a parent type where a subrange
> value is required.

Give an example.  This sort of thing will be statically checked.


> :Here is where you actually get some more flexibility with Ada as you
> :can parameterize your generic (either the constrained or unconstrained
> :type) with more than just types.  You can specify complete signatures
> :including operations and/or packages as well.  What's more, these can
> :have constraints on them as well.  
> 
> Yes. However, these kinds of formal parameters are only needed in Ada because
> it distinguishes between module and type.

Nah.  That's irrelevant to why they are there.  They are there, as
Rober Eachus points out, because you have the flexibility of not
_only_ organizing your structures strictly hierarchically.  Or _only_
on type.


> simpler because it is a *pure* OOPL compared to hybrid Ada.

Pure, schmure.  No programming language is "pure" in my estimation.

/Jon

-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: OO, C++, and something much better!

[Robert Dewar]

Keith says

"On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
do not make sense should raise Program_Error".  The AARM (Annotated Ada
Reference Manual) gives the examples of X < Y and conversions between
Integer_Address and Address on a segmented architecture.  (Note also that
it's not necessary to use System.Storage_Elements; relational operators
on type Address are provided in System.)"

Nope, you are reading too much into the RM here. Also reading the AARM
is always a risky business (remember it is just opinion, nothing more :-)

Let's take the case of a segmented architecture. It is common for C
compilers in such environments (Large mode on the 8086) to limit objects
to 64K bytes and to compare ONLY the offset parts of the addresses
so that address comparison onlly works when it is defined to work, and
gives silent junk answers when used between different objects. One neither
expects nor encounters Keith's supposed "reasonable" behavior where this
is likely to work.

If we look at the corresponding Ada case, I cannot see any justification
whatsoever for not properly allowing conversoin of any possible segmented
address to an integer address. Such an operation makes perfect sense in
this environment and is therefore REQUIRED TO BE SUPPORTED! You are only
allowed to raise PE for things that do not make sense. Since this machine
has a well define notion of linear address, it is clear to me that (a) any
implementor on this environment would provide the obvious conversion and
(b) that if they did not, they could not seek refuge in the RM.

Let's actually look at the AARM wording, it says, if we quote it in full,
rather than paraphrase as Keith did:

        16.a   Discussion:  For example, on a segmented architecture, X < Y
        might raise Program_Error if X and Y do not point at the same segment
        (assuming segments are unordered).  Similarly, on a segmented
        architecture, the conversions between Integer_Address and Address
        might not make sense for some values, and so might raise Program_
        Error.

Why this "for some values", that's becuse the conversoin in the opposite
direction from Integer_Address to Address is indeed problematical, and
one might well decide to raise Program_Error for some values in this
direction.

Keith's point that there is a comparison operation on addresses directly
is true, but it is not a good idea to use these operations, since it is
indeed sensible to decide that certain comparisons are not meaningful
when performed directly on segmented addresses.

So, to summarize (and explain Alex's legitimate point), an implementation
of data structures in Ada which converts Address values to Integer_Address
and then compares the Integer_Address values will work on all likely
architectures including segmented architectures, and is from a formal
point of view defined to either work as expected or raise Program_Error.

By contrast, if you compare addresses in a corresponding C program, the
address comparison will in fact produce meaningless results silently
in the case of segmented architectures, and from a formal point of view
nothing at all can be said about the semantics of the comparison operation.

*quite* a difference, and enough for Alex to decide quite reasonably, that
a standard implementation of libraries for C++ (which has the same semantics
as C here) could not legitimately use these undefined comparison operations,
whereas in the Ada 95 case, they could reasonably used. 

Yes, in the Ada 95 case, one could perhaps imagine a machine in which
there was no sensible linearization of addresses, but I certainly don't
know of any such machine, so such considerations are of a purely
theoretical nature.

In the C case, many programmers have been burned by the "unexpected"
behavior of address comparisons on a segmented machine. For example,
if you have

    int p [10];

then ((p-1) < p) can be false, so a loop that works by pointing one before
the array to initialize can fail. equally if you do something like

   (x = p; x < &p[10]; p += 3)

you can find you have an infinite loop, all quite in accordance with the
C semantics, although somewhat surprising.

Re: OO, C++, and something much better!

[Roy Phillips]

Don Harrison wrote:
> Mark A Biggar writes:
> 
> :Of course there is nothing that requires
> :that the provided function realy be a less-than function (which is usefull
> :as providing a ">" instead reverses the order of the list) but Eiffel has the
> :same problem and there is no guarentee that a class derived from COMPARABLE
> :hasn't redefined "<" to do something else either.
> 
> While it wouldn't be possible in this case, a level of confidence can be
> provided in other situations using Eiffel postconditions.

   The problem with this approach is not really the deliberate
substitution
of the ">" with a "<": as stated, this can be a useful technique (I'd
hate
to have to maintain that code, all the same!).  More problematical is
the
accidental substitution, for example of an operation with same name but
an
entirely differant meaning (for example, the terms 'interest' (financial
domain) and 'interest' (marketing domain)) - blame the English language
if
you will, but without semantic specification (i.e., Eiffel assertions)
the
whole thing is a can of worms.

- Roy

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>There are times when you want optimizations yet you want to avoid
>cross-module optimizations, but those should be exceptions;
>automatic cross-module inlining ought to be the norm.
>
>  I think not. You can only do cross-module inlining if every compilation
>  potentially recompiles code for the entire application. This seems out
>  of the question in large applications.

During the edit-compile-debug cycle, you want rapid turn-around, and so
you don't want optimizations (except for those that actually speed up
the turn-around time).

Then when you're doing integration testing, when you can afford to
compile with optimization, you can usually also afford cross-module
inlining.

>  It seems to me here that the Ada approach is just right. Fergus, if you
>  are aware of the Ada approach, what would you change?

The Ada language design is OK; I consider having "private" sections
in package specifications to be a fairly low-level, implementation-oriented,
and inelegant approach, but I understand its advantages.

What I would change is the implementations: specifically, I'd like to
see a cross module inlining option for GNAT.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

Richie Bielak <richieb@calfp.com> writes:

>Optimizations that require global analysis of all the classes
>of a program at compile time do not work if we need dynamic loading
>of classes at runtime, because adding a new class to a running system
>may invalidate optimizer's assumptions.

True, but there are plenty of cross-module optimizations (such as
cross-module inlining) that require the compiler to use information
from more than one module but don't require analysis of *all* parts of
a program.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Keith Thompson]

In <dewar.852652911@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Actually, when I talked to Alex, he indicated that there were critical
> features in Ada 95 that were missing in C and C++ for this kind of
> work. In particular, he noted that C lacks a general address comparison
> operation, useful for hashing data structures, whereas Ada does have such
> an operation (in System.Storage_Elements on type Integer_Address). It is
> a bit ironic to identify this particular feature as crucial (since most
> people mistakenly think that C has such a feature and Ada doesn't!)

Well, sort of.

It's true that C pointer comparison is undefined unless the pointers being
compared point into the same object (or one past the end of an array).
However, any real-world C implementation isn't going to go out of its
way to make such comparisons invalid.  If pointers "look like" integers
at the hardware level, pointer comparison is almost certainly going to be
implemented as integer comparison.  It may be signed or unsigned, but it's
almost certainly going to be consistent within a given implementation.

On the other hand, for Ada 95, RM95-13.7.1(16) says that "Operations that
do not make sense should raise Program_Error".  The AARM (Annotated Ada
Reference Manual) gives the examples of X < Y and conversions between
Integer_Address and Address on a segmented architecture.  (Note also that
it's not necessary to use System.Storage_Elements; relational operators
on type Address are provided in System.)

The use of the word "should" means that an Ada implementation is not
*required* to raise Program_Error.  Thus it's permissible for address
comparisons to behave inconsistently.

To summarize, both C and Ada provide relational operations on addresses.
Both require such operations to be well-behaved only in certain cases,
and leave them more or less undefined in other cases.  Both are defined
in such a way that any reasonable real-world implementation will almost
certainly implement address comparison in the obvious manner, which
should be useful for hashing data structures.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Jay Martin]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Jay, in typical fulminating mode says

> "It seems to me need for "pragma inline" and "inline" is/was social.
> It came from compiler writers continually slacking off since the 60's
> and not implementing inlining."

>nonsense, all decent compilers implement inlining today, it is a more
>vital optimization than ever because of icache considerations (particularly
>in direct addressed caches).

Gee I don't remember fully general inter-unit automatic/intellegent
global analysis procedure inlining in the early 80's when "pragma
inline" and "C++ inline" features were created.  Maybe I just used
lame compilers.

But then I remembered I was just parroting Stroustrup: "I had had poor
experiences with languages that left the job of inlining to compilers
"because clearly the compiler knows best" The compiler only knows best
when if it has been programmed to inline and it has a notion of
time/space optimization that agrees with mine.  My experience with
other languages was that only "the next release" would actually
inline, and it would do so according to an internal logic that a
programmer couldn't effectively control."  (Design Evolution C++ pg
33)


>In a large project it is essential not to accidentally create interunit
>dependences so that a small change to one unit causes millions of lines
>to need to be recompiled.

>The problem is that you definitely do NOT want the compiler rushing off
>and creating unlimited body dependencies (think interunit dependencies
>if you don't want to think Ada specifically) by doing automatic interunit
>inlining.

>Still some interunit inlining is highly desirable especially with
>heavy layering of abstractions. But you want to give the programmer
>some control, to avoid the problem of inter-unit dependencies running
>amok!

Here's an ignorant question: Why would inlining or extensive
optimations be turned on for frequent builds of a quickly changing
large software project.  It seems testing of optimized builds could be
done less frequently and in parallel.  I mean if you don't inline
quickly changing source by using compiler controls, then you don't get
these sort of dependencies.  I must be missing something here.

Here is an even more ignorant question: Why is compilation time still
a driving factor? (excluding hardcore optimizations) Obviously it
still is as I watched large systems compile lately.  But wait, wasn't
Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
faster than VC++ on my P5-100.  For fun I compiled old programs with
vintage a Turbo Pascal Compiler and it seems to compile these suckers
instantanously!  It doesn't seem to me that current system build times
are keeping pace with processor speed improvements.  I mean shouldn't
a Pentium Pro 200 be compiling like a million lines a second or
something?  If its not, then how about the eventual P7-600Mhz or the
P8-2000Mhz-16(processors per chip).  I mean I can write N lines of
code a day and that is not going to change much, but computer speeds
are increasing exponentially.

Jay

Re: What is wrong with OO ?

[Simon Willcocks]

In article <dewar.852833957@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) says:

>Simon said

>"[...]
>I think that even in [Ada] inlining could be done by a suitable linker,
>provided the compiler could mark parts of object code as suitable for inlining.
>The linker could insert the relevant code in place of the call statement,
>rather than just setting the location to be called."

>[...]

>Inlining is MUCH more than just sticking in the code at the point of call
>and cannot be done at all by a stupid linker. The whole point of inlining
>is that you optimize the code that is inserted, minimally by increasing
>scheduling opportunities, but in the presence of global optimization, knowing
>what the body of a procedure does and does not do can buy a great deal. The
>elimination of the call itself is small stuff compared to the other gains.

I agree it can't be done with a stupid linker, but I was just pointing out
that inlining can be done in Ada without affecting the programmer.

You just have to leave the jobs of optimisation and (machine) code generation
to a later stage.

Simon

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said

"What I would change is the implementations: specifically, I'd like to
see a cross module inlining option for GNAT."

If you mean that you want every possible opportunity for cross-module
inlining to be attempted, that is easily achieved, just write a little
tool that generates pragma Inline's for all visible subprograms in all
package specs. Then turn on the usual -O2 -gnatn switches.

It certainly would be easy to implement a compiler option to force this
treatment, but so far none of our customers has suggested this as a
requirement.

Re: What is wrong with OO ?

[Bart Samwel]

Robert wrote:

> "You shouldn't bother programmers with inlining. Inlining can be done
> automatically by the compiler."
> 
> I don't see this is possible across modules without violating the
> integrity of separation of specs and implementations.

In C++, it's not possible, that's true. This is because C++ uses a
modular model that completely separates different parts of the system.
When compiling one module, the compiler doesn't know anything about the
other modules other than that they are there and their specifications.
This makes automatic inlining very hard, because the implementation is
just _not available_ to the compiler!

The problem here is that C++ honours the principle of modularity, which
is a Good Thing, but fails to recognize the fact that many modules
form a System as a whole. This results in C++ not doing any global
analysis of programs, so that it cannot automatically detect functions
which need dynamic binding ("virtual"), it cannot choose to inline
functions which were not designated by their writer to be inlined,
and it cannot perform optimizations that cross module boundaries (these
optimizations would be valid only within the system they were performed
on, so that when you use some of the modules in another system, other
optimizations might be chosen).

In languages like Eiffel, which provide for global analysis of the
system, automatic inlining is possible. It is even possible to inline
one call to a function (for instance, within a loop), and not to inline
another call in the same function, only a few lines later.

As for separation of specs and implementations: C++ violates this too,
by forcing inline functions to be defined in the class INTERFACE
specification. With global analysis, you can still keep this separate,
and even better, because you don't have to put the inline function in
the interface: the global analysis has access to the implementation
anyway, so you don't need that anymore.

The point I have here is that the fact that the implementation is
visible to the compiler does not directly imply it should visible to
the programmer.

   Bart

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>If it was consdered useful to allow unlimited inlining in Ada, it would
>be trivial, and very much within the spirit of the language to add a
>configuration pragma Inline_All (implementations of Ada are allowed to
>add such configuration pragmas, or it could simply be a compiler switch).
>
>To implement such a switch would be about thirty minutes work in GNAT, but
>I doubt it would be found to be of much use in practice, certainly no one
>has indicated an interest in such a switch.

Let me hereby indicate interest in such a switch!
I think it would be quite useful in practice.

>On the contrary, in large 
>programs, people are VERY concerned about compilation dependencies. If
>any change to any unit requires recompiling ten million lines of code,
>then even with a fast compiler, the impact on development productivity
>is worrisome.

My (non-Ada) experience is that many programs consist of between a few
thousand and a few hundred thousand lines of code, and that often I am
interested in building the fastest possible executable and not
particularly concerned with compilation speed (since I'm building it in
the background) and entirely unconcerned with recompilation speed
(since I am just doing `make && make install && make clean').

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Robert Dewar]

Simon says

"I agree it can't be done with a stupid linker, but I was just pointing out
that inlining can be done in Ada without affecting the programmer.

You just have to leave the jobs of optimisation and (machine) code generation
to a later stage."


Let's look at that carefully. The second paragaph implies that the link
step redoes optimization and compilations for the entire program. Even
with fast machines and fast compilers, I think that this is definitely
something that would "affect the programmer".

As I have pointed out before, it is of course a trivial adjustment
to an Ada compiler to make it automatically check for inlining everywhere
(it is in fact a one line change to the GNAT compiler). But it is not
clear that this is a useful option in practice, although maybe this
discussion will suddenly make one of our customers suggest it :-)

Re: OO, C++, and something much better!

[Bart Samwel]

Robert Dewar wrote:

> values of one type to values of another type. It is that these
> operations can generate abnormal values.

I just thought of a way to implement safe type (read: class) casting
in Eiffel:

Use the Attempted Assignment operator ?= to try to assign, as in:

   local
      object1 : CLASS1
      object2 : CLASS2

   do
      !!object1.make (whatever)
      object2 ?= object1         -- this is what I mean
      if object2 /= Void then
        ...
   end

This operation makes object2 a reference to object1, but belonging to
class CLASS2, but only if, after conversion, object2 satisfies the
class invariant of CLASS2. Otherwise, object2 will be Void.

Oh, by the way, this is meant to be interpreted as humour, not as
a serious proposal. ;-)

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said

"library?).  Hence this control should normally be expressed via
compiler options, rather than being embedded in the source code."

Are you using GNAT? I would guess not, because you seem to assume that
is not the case, but in fact inlining is controlled by compiler options
in GNAT. The pragma inlines merely enable the establishment of interunit
dependences. The extent to which inlining takes place depends on 
compiler switches -- see the GNAT documentation for details.
n

Re: What is wrong with OO ?

[Jay Martin]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Jay, in typical fulminating mode says

> "It seems to me need for "pragma inline" and "inline" is/was social.
> It came from compiler writers continually slacking off since the 60's
> and not implementing inlining."

>nonsense, all decent compilers implement inlining today, it is a more
>vital optimization than ever because of icache considerations (particularly
>in direct addressed caches).

An example of inlining getting the shaft by compiler writers is G++
which does not support the normal inlining of templated class methods.
There is a "G++ only" workaround (source code hack) in the latest
compiler but again you have to wait for the real fix until "the next
release".

Re: What is wrong with OO ?

[Michael Malak]

In article <32D64931.167E@wi.leidenuniv.nl>,
Bart Samwel  <bsamwel@wi.leidenuniv.nl> wrote:
>
>In C++, it's not possible, that's true. This is because C++ uses a
>modular model that completely separates different parts of the system.
>When compiling one module, the compiler doesn't know anything about the
>other modules other than that they are there and their specifications.
>This makes automatic inlining very hard, because the implementation is
>just _not available_ to the compiler!

Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
version 1.5 (early 1994).  MSVC++ performs "auto-inlining" (Microsoft's
terminology) by compiling all the source modules all at once.  That's
why it exhibits the curious behavior during compilation where it says
"Compiling...", then lists the modules one by one, then says
"Generating code...", then lists the modules all over again.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Robert Dewar]

Fergus said, responding to me

">To implement such a switch would be about thirty minutes work in GNAT, but
>I doubt it would be found to be of much use in practice, certainly no one
>has indicated an interest in such a switch.

Let me hereby indicate interest in such a switch!
I think it would be quite useful in practice."


Well of course people are interested if it costs them nothing to be
interested :-)

It will be interesting to see if any of our customers picks up on this
as something that might be useful to them. Right now, we have lots of
things to do that definitely *are* of interest to our customers, so
these certainly have higher priority.

Actually, not many people in practice are even using -gnatn to activate
interunit inlining (which works fine, and we use it in the compiler itself).
Relatively few applications are at the level where they are worrying about
performance that much, but of course for those that do, it helps a lot.

Also if you have efective inlining, you tend to design with this
expectation. The GNAT compiler is certainly written this way. So far,
all released compilers have had full debugging assertions turned on,
and no inlining, but the compiler we recently shipped for the second
phase of the DEC field test for the VMS Alpha port is the fast compiler
with assertions off, and full inlining, and it does make quite a
difference in speed.

I don't know if the 3.09 releases will be the fast compiler or not, we have
not decided yet ...

Robert Dewar
Ada Core Technologies

Re: OO, C++, and something much better!

[Robert Dewar]

Bart says

"This operation makes object2 a reference to object1, but belonging to
class CLASS2, but only if, after conversion, object2 satisfies the
class invariant of CLASS2. Otherwise, object2 will be Void.

Oh, by the way, this is meant to be interpreted as humour, not as
a serious proposal. ;-)"


If we are doing design at this level, we should make it clear that when
you say "the class invariant of CLASS2", you also include all the 
unstated invariants that are in the mind of the programmer only :-)

Re: What is wrong with OO ?

[Robert Dewar]

Bart said

"In languages like Eiffel, which provide for global analysis of the
system, automatic inlining is possible. It is even possible to inline
one call to a function (for instance, within a loop), and not to inline
another call in the same function, only a few lines later."

Such discrimination is typical of modern compiler technology, and has 
nothing to do with whether the "language provide[s] for global analysis
of the system", whatever that might mean. Certainly any language allows
an implementation in which you delay some or all of code generation until
link time (for example, the old MIPS C compilers used to do global
register allocation at link time).

Whether you want to do this global recompilation, with dynamic adjustment
of inlining depends on the size of the system, the speed of the compiler,
and the extent to which you worry about things not working any more if
they have been recompiled in a different inlining environment.

Re: What is wrong with OO ?

[Pieter Schoenmakers]

In article <5b4f6l$aeq@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

   Richie Bielak <richieb@calfp.com> writes:

   >Optimizations that require global analysis of all the classes
   >of a program at compile time do not work if we need dynamic loading
   >of classes at runtime, because adding a new class to a running system
   >may invalidate optimizer's assumptions.

   True, but there are plenty of cross-module optimizations (such as
   cross-module inlining) that require the compiler to use information
   from more than one module but don't require analysis of *all* parts of
   a program.

With any kind of static binding (and inlining is the summum in static
binding), the possibilities of dynamically loaded code are limited.  What
to do if a dynamically loaded class redefines some feature causing that
feature to no longer be statically bindable?  Recompile the whole
executable?  --Tiggr

Re: OO, C++, and something much better!

[Ken Garlington]

Robert Dewar wrote:
> 
> If you like, consider Ada *minus* these two features as the interesting
> language to be analyzed. Then understand that in real life programs can
> break the bounds of this analysis to the extent they need to.

I think the other interestings aspects of the Ada approach are (1) the
language
makes it clear when something potentially nasty is being done -- both in
terms
of the language definition, and in terms of the syntax making the
operation
clear in the source code -- and (2) there is at least some attempt,
through
features such as 'Valid, to try to mitigate these effects where
possible. This
won't necessarily help with formal analysis, but it is useful in "real
life"
programs.



--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: What is wrong with OO ?

[Bart Samwel]

Michael Malak wrote:
> Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
> version 1.5 (early 1994).  MSVC++ performs "auto-inlining"
> (Microsoft's terminology) by compiling all the source modules all at
> once.  That's why it exhibits the curious behavior during compilation
> where it says "Compiling...", then lists the modules one by one, then
> says "Generating code...", then lists the modules all over again.

This is a pro for VC++. However, most compilers still use the old make-
based model, especially on Unix, where compilers must comply to this
model because almost all unix software not distributed as binaries is
distributed using make projects. That VC++ does do automatic inlining
does not imply that my argument is invalid, only that there are
exceptions to the general situation I described. And it still is true
that C++ doesn't exactly invite compiler writers to implement automatic
inlining.

Re: What is wrong with OO ?

[Joe Buck]

jmartin@cs.ucla.edu (Jay Martin) writes:
>An example of inlining getting the shaft by compiler writers is G++
>which does not support the normal inlining of templated class methods.

Not quite true: only the first occurrence of a template function, the
one that causes the expansion of the template cannot be inlined.  This
is a problem with the design of the template expansion code and long
recognized by the maintainers as a bug.

This problem is fixed in the 2.8.0 snapshots, which has a new template
implementation.

>There is a "G++ only" workaround (source code hack) in the latest
>compiler

No, the workaround (explicit template expansion) is to write standard
(draft ANSI/ISO standard) code to explicitly expand the template; all
occurrences will then be inlined.





-- 
-- Joe Buck	http://www.synopsys.com/pubs/research/people/jbuck.html

Help stamp out Internet spam: see http://www.vix.com/spam/

Re: OO, C++, and something much better!

[Norman H. Cohen]

(This note, concerned only with a esoteric nit about Ada, is posted only
to comp.lang.ada.)

Robert Dewar wrote:

> Note that it is not actually the unchecked conversion that is nasty, since
> the fundamental conversion can be modeled as simply a random mapping between
> values of one type to values of another type. It is that these operations
> can generate abnormal values.
> 
> This may still not be a problem, given that uninitialized values can also
> be abnormal, thus:
> 
>   a := nasty_unchecked_conversion (b);
> 
> is no worse that not assigning to a at all if a is uninitialized.

No, uninitialized variables may be "invalid", but not "abnormal". 
Abnormal is worse than invalid.  Even uninitialized objects of a
composite type might satsify certain conditions (e.g. gaps between
record components set to zero, dope vectors properly initialized, etc.)
that an abnormal value violates.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <32D51BC8.41C67EA6@escmail.orl.lmco.com> Ted Dennison <dennison@escmail.orl.lmco.com> writes:

  > Does that mean that they ALSO started thinking about the revision
  > again in 1993, even though the Ada 95 effort was well underway?
  > ;-)

    I wouldn't have responded, but it is a funny story.

    First, there was a decision by the Ada Board in 1988 to recommend
revision of the Ada standard, and for the next revision to be the last
to use the government funded contractor approach.  I hope an
electronic copy of that report is around somewhere, but if not I may
still have it on a (Macintosh) disk.

    However, the ISO standard was not approved until 1987 due to
procedural and other problems--even though the ISO standard was a one
page document pointing to the ANSI and French standards.  (Alsys did
the French translation with a lot of involvement from Jean and Mike,
so it was very faithful to the original.)

    So at Zandvoort, after a long discussion at the WG9 meeting of
slipping the schedule for Ada 9X six months, with detailed debate on
dates for committee drafts, ISO standards processes, etc. Bob Mathis
announced during the "new business" part of the meeting that ISO had
asked him as WG9 convener if we were planning to revise the Ada 87
standard.

    And finally, the real requirement is to revisit every standard at
least every five years to take action on it: keep it, revise it or
abandon it.  After 10 years most standards organizations automatically
abandon a standard if no action has been taken.  There was a lot of
discussion about whether to take explicit action on the ANSI Ada 83,
or to let it disappear. (For most purposes it was technically already
superceded by the identical ISO standard, which wouldn't expire until
1997.)  This was resolved by the Memorandum of Agreement between the
DoD, ANSI and ISO.  All three basically agreed to approve Ada 9X
together, and that Ada 83/87 would be in force until then.

    Since Ada 95 was actually approved in January 1995, we have until
December 2005 to amend it or whatever.  At this point I hope we can
have a nice little fold in the fixes to minor gotchas revision, and
leave any major revision for Ada 10X.  (If you want to think of it as
a fix the annexes revision, fine.  Most of the problems the ARG has
discussed so far are either chapter 13 issues or related to one or
another annexes.  The core language apparently got lots of attention
during the revision process, but the annexes were trying to track a
moving target.)



--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: What is wrong with OO ?

[Robert I. Eachus]

In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

  > The ISE Eiffel compiler performs inlining completely automatically.
  > There is no "pragma inline" or comparable programmer intervention,
  > since it is not the programmer's job to worry about whether a routine
  > is inlinable or not. This is a job for a compiler.

   For some things this works, but Bertrand then says:

  > (In addition, for an object-oriented language, inlining is only
  > possible for a routine that is never subject to dynamic binding.
  > This requires extensive analysis of the software. If the
  > programmer requests inlining but it is semantically wrong, the
  > compiler should ignore the request. But then if the compiler is
  > capable of doing this analysis it should take care of the inlining
  > too, without bothering the programmer!)

  This is where the problem arises.  If you compile everyting in one
big batch, this is possible.  But if you don't then the user needs to
be able to say:

  "I don't expect any later subclass to override this method.  If I do
that (or some other programmer does), I'm willing to take a big
recompilation hit."

  Add to this the fact that a lot of apparently dynamic links in Ada
are actually resolvable at compile or link time, and you want the
ability to mark methods this way.  

  For instance, you can have a call on a method of a specific type
which dispatches to an inherited method which then makes many other
calls on methods of the type.  If the outer call is inlined, then all
the inner calls dispatch statically as well.  Often these inner calls
are to placeholder routines which contain no code, or to routines
which are only a few machine instructions in most static cases.

  > ISE Eiffel does give the user a degree of parameterization:
  > a compilation option specifies the size threshold beyond which
  > a routine will not be inlined. This is measured in internal units
  > (number of bytecode words), but easy to relate to number of
  > instructions. This option provides a way to control space-time
  > tradeoffs. In practice, however, most users are happy with the
  > default, which inlines small, frequently called routines.

   Ah, most Ada compilers do this as well.  But occasionally there is
a big payoff from inlining an otherwise large routine.  One case is
that you know that it is only called in one place.  Another is
mentioned above--inlining a "big" routine may result in further
automatic optimizations so that the final code is very small.

  > This automatic optimization is crucial because the object-oriented
  > style of development, with its emphasis on  abstraction, naturally
  > tends to yield many small routines. With ISE Eiffel, you can write the
  > software as it should be, not asking yourself all the time "should
  > I violate abstraction here and avoid writing a small routine because
  > of the effect on performance?"...

  Same in Ada.

  > You just leave this kind of concern to the compiler. ("Inline"
  > pragmas would be almost worse here, because you would have to
  > perform yourself the analysis of what is inlinable and what is
  > not. The incrementality problem is particularly nasty: change a
  > single line somewhere in a large system, and a routine that was
  > inlinable, far away in the software text, now becomes
  > non-inlinable! This kind of systematic, exhaustive work,
  > error-prone when done by humans, is what computers are for.)

  This is why the Ada pragma is ADVICE.  If the compiler can no longer
follow the advice, it has to go back and recompile things.
(Technically, the compiler can just tell the user which items are
obsolete, but all Ada compilers I'm aware of do this automagically or
through a make facility.)  The important thing is that pragma INLINE
can affect speed, executable size and/or compilation time, but it can
never affect correctness.

  > I also think that the Eiffel view of "separation of specs and
  > implementations" is more sophisticated than Ada's one (which I
  > assume is the one Robert Dewar has in mind), but that will be the
  > topic for another debate...

    If a classical debate, one well worth following.  But please don't
frame it that way.  It is not a feature war.  Both Eiffel and Ada had
models in mind when the languages were developed, but the set of
models supported in each case is richer, and overlapping.  AFAIK, the
"pure" Eiffel and Ada models are supported in both languages.
However, there are design models that work in Ada but not Eiffel and
vice-versa.  Also there are features in both languages that make
impure versions of their design models much easier to work with.

    For example, in the previous discussion, we have seen a case where
the user wants to limit a generic to one with comparisions.  Ada can
follow the Eiffel model:

    generic
      type Foo is new Comparable with private;
      ...

    But more normally in Ada this will be done as:

    generic
      type Foo (<>) is private;
      with function ">" (L,R: Foo) return Boolean;
      ...

    As I pointed out, this is because the Ada type model sees classes
as sets of types all having a specific set of operations.  Therefore
it is more normal (in Ada) to specify a class by specifying the
required operations.  The fact that a class is hierarchical is
expressed by/visible because of the available type conversion
operations.  Two types are members of the the same class if an object
of one type can be explicitly converted to an object of the other, or
both can be converted to a third type.  (To make that "if only if" is
complex since I can't specify the third type to class mapping in less
than a page. For example all discrete types can be converted to
_universal_integer_ by 'Pos.)  In a hierarchical class all objects can
be converted to / passed as a parameter of the type at the top.

    In Eiffel, even though the actual concept of class is very
similar, the model is explicitly hierarchical.  (You can implement the
Ada number class in Eiffel by adding explicit conversions which break
the hierarchy.)  As I said, it is not that it is not possible in
Eiffel, it is more that it is not done.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO, C++, and something much better!

[Robert Dewar]

oops, my last example of surprising C code

   (x = p; x < &p[10]; p += 3)

should of course be

   (x = p; x < &p[10]; x += 3)

Re: OO, C++, and something much better!

[Norman H. Cohen]

Andrew Koenig wrote:

> What Alex told me about that effort was that he was unable to find
> a single Ada compiler that implemented the standard accurately enough
> to enable him to do what he wanted to do with his library.

Alex Stepanov's Ada project took place nine years ago.  A lot of early
Ada compilers had trouble with intricate uses of generics, particularly
with such things as generics nested within generics.  However, most Ada
compilers have been much more reliable than that for many years now.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <32D536C6.64880EEB@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

> Robert I. Eachus wrote:
> > 
> > 
> >       Bertrand Meyer said:
> > 
> >    > In my opinion neither Ada (83 or 95) nor C++ has the combination
> >    > of mechanisms making it possible to have the full power of
> >    > generics in an object-oriented language, as present in Eiffel...
> > 
> >      And then listed four properties, all of which are in Ada 95!
> 
> I disagree. What Mr. Eachus showed in his message is ways to achieve
> in Ada 95 the effect of the object-oriented mechanisms I described,
> as implemented in Eiffel. And he is correct that one can use Ada 95
> to obtain many of the same goals. (This would not be true, for example,
> of C++ and even less of Java.) But this does not mean the "four
> properties" that I listed are in Ada 95. Anyone who checks my
> message and the Ada 95 language definition will see that.

I am willing to buy this - more or less - as I noted in my original
reply.  But, your original post (with the relevant part right up there
just above) does not SAY this.  It certainly _reads_ like you are
saying that Ada 95 has none of these properties - and that is just
plain outright indisputably FALSE.  In fact, the _only_ one that it
does not have at the level you suggest is the so called "completely
consistent type system" which seems to really mean "an Eiffel style
type system".  The other three are there and actually are rather
better done in Ada, IMO, than the equivalent Eiffel.


> At some point, of course, one runs into matters of taste. I will
> again contend, however, that a rational, systematic analysis of
> O-O principles and how they combine with genericity, information hiding
> and other software engineering concerns almost inevitably lead to the
> Eiffel mechanism

Well, the big problem here is that there are so many "loaded" terms in
this without any universally accepted definitions and certainly no
universally accepted _value_ judgements and absolutely no objective
series of studies supporting anything one way or the other, that it
just doesn't say anything more than: "In my reasoned view, Eiffel is
better, and I have listed various reasons for my belief."

Fair enough.  But having done the above so called "rational,
systematic analysis" of so called "O-O principles", I've arrived at
rather a different conclusion and have listed reasons for this in the
past as well.  In particular, MI useage, in my perusals, is nearly
universally conceptually confused.  It is not a very good way of
"modeling" things.  It _can_ be a decent way of "code reuse" - but it
is not worth the conceptual price given readily available
alternatives.

Shrug.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Robert Dewar]

Marky said

"All you guys are talking about is inlining some code!!  Is it really worth
this long thread?"

Inlining is an important optimization, and becoming more so for two reasons.

  1. In pipelined machines, especially those with small primary direct
     addressed caches, inlining calls in a loop can avoid nasty effects
     due to cache address clashes.

  2. layered development, particularly the style associated with layered
     abstract data structures or objects, can result in lots of trivial
     subprograms being called, which can severely affect performance, again
     because of I-cache effects, this gets worse in modern machines.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>... some interunit inlining is highly desirable especially with
>heavy layering of abstractions.

I'm glad you agree.

>But you want to give the programmer
>some control, to avoid the problem of inter-unit dependencies running
>amok!

Yes, you should give the programmer some control.  But the degree to
which inter-unit dependencies and recompilation speed are important
varies considerably between different situations, even for the same
source code (e.g. How fast is the computer you are compiling it on? 
Do you plan to modify the code and recompile, or are you just doing a
build and install?  Are you building an executable or a shared
library?).  Hence this control should normally be expressed via
compiler options, rather than being embedded in the source code.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Jay Martin]

jbuck@synopsys.com (Joe Buck) writes:

>jmartin@cs.ucla.edu (Jay Martin) writes:
>>An example of inlining getting the shaft by compiler writers is G++
>>which does not support the normal inlining of templated class methods.

>Not quite true: only the first occurrence of a template function, the
>one that causes the expansion of the template cannot be inlined.  This
>is a problem with the design of the template expansion code and long
>recognized by the maintainers as a bug.

>This problem is fixed in the 2.8.0 snapshots, which has a new template
>implementation.

As I said the "next release".

>>There is a "G++ only" workaround (source code hack) in the latest
>>compiler

>No, the workaround (explicit template expansion) is to write standard
>(draft ANSI/ISO standard) code to explicitly expand the template; all
>occurrences will then be inlined.

Well gee if I have to insert "explicit template expansion" lines not
needed by any other C++ compiler or the standard that sounds like "G++
only source code hack" to me.  Of course, since I might also use an
older C++ compiler on my code that doesn't yet recognize expansions,
then I am going to have to put "#ifdefs" around these expansions.
Yee Haw!

This "bug" (lack of inlining) has been in G++ for YEARS, it just shows
how much priority (Zero) that so many programmers give to basic data
abstraction (you can't efficiency implement abstract data-structures
like "smart pointers" in C++ without inlining).

Jay

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:

bertrand> The ISE Eiffel compiler performs inlining completely
bertrand> automatically.  There is no "pragma inline" or comparable
bertrand> programmer intervention, since it is not the programmer's job
bertrand> to worry about whether a routine is inlinable or not. This is
bertrand> a job for a compiler.

It seems contrary to reasonabless: there are many contexts where
inlining is not necessary and others in which it is important, *even for
the same procedure*. Thus there is (usually) a space/time tradeoff, but
*at each call site*. It sounds astonishing to me an argument that the
compiler should try to second guess or infer space/time tradeoffs
(except perhaps in the simplest cases), in addition to doing its job of
compiling valid translations of a source.

bertrand> (In addition, for an object-oriented language, inlining is
bertrand> only possible for a routine that is never subject to dynamic
bertrand> binding.

This is not quite the whole story. It all depends on call sites: at some
call sites a procedure can well be inlined, if at those call sites the
procedure implementation invoked can be identified statically. If it is
*also* invoked at call sites where this cannot be done, then an
out-of-line version must also be generated.

A lot of people forget that overloading resolution *and* procedure
implementation call/inlining are crucially dependent, both as to
validity and desirability, on specific call sites. Call sites that are
part of inner loops tend to make inlining more desirable (there are
often opportunity for code reorganizations of various sorts), for
example. Static resolution and perhaps inlining can also be possible at
some call sites but not others.

bertrand> This requires extensive analysis of the software. If the
bertrand> programmer requests inlining but it is semantically wrong, the
bertrand> compiler should ignore the request. But then if the compiler
bertrand> is capable of doing this analysis it should take care of the
bertrand> inlining too, without bothering the programmer!)

Here is a confusion two very different concepts: whether inlining is
*useful* and whether it is *possible* (valid). It may be a job for the
compiler to check whether inlining a procedure at a given call site is
*possible*, as claimed here; but it may require a lot harder work for
the compiler to determine whether that inlining is also *useful*. A
programmer's suggestion as to the *usefulness* of inlining a procedure
at a given call site (or all call sites, much more coarsely and rather
less desirably) is not replaceable by the a compiler check on the
*possibility* of inlining it.

Ideally a compiler would use profiling feedback to evaluate whether it
is worth inlining a procedure at a given call site, by running the
program with an without (this check ought to be done for each procedure
at each call site for which is is possible, and every combination
thereof :->).

Cruder hints may be used:

bertrand> ISE Eiffel does give the user a degree of parameterization: a
bertrand> compilation option specifies the size threshold beyond which a
bertrand> routine will not be inlined. This is measured in internal
bertrand> units (number of bytecode words), but easy to relate to number
bertrand> of instructions. This option provides a way to control
bertrand> space-time tradeoffs.

but, just like the 'inline' keyword of ``C++'', it does not quite
recognize that hinting for inlining a procedure at *all* call sites is
not quite as useful as hinting for it to be inlined at particular call
sites. However probably simple compiler heuristics can be useful, like:

bertrand> In practice, however, most users are happy with the default,
bertrand> which inlines small, frequently called routines.

As to this some Ada compilers do allow selective inlining at call site,
or at least at call sites thru a region of code only (if I remember
well).

bertrand> This automatic optimization is crucial because the
bertrand> object-oriented style of development, with its emphasis on
bertrand> abstraction, naturally tends to yield many small
bertrand> routines.

Where have I heard some of those word already? Ah, yes, those are the
words used by Ken Thomson and Dennis Ritchie about the C procedure
calling conventions. Then people instead started using '#define'. :-)

bertrand> With ISE Eiffel, you can write the software as it should be,
bertrand> not asking yourself all the time "should I violate abstraction
bertrand> here and avoid writing a small routine because of the effect
bertrand> on performance?". You just leave this kind of concern to the
bertrand> compiler. ("Inline" pragmas would be almost worse here,
bertrand> because you would have to perform yourself the analysis of
bertrand> what is inlinable and what is not. The incrementality problem
bertrand> is particularly nasty: change a single line somewhere in a
bertrand> large system, and a routine that was inlinable, far away in
bertrand> the software text, now becomes non-inlinable! This kind of
bertrand> systematic, exhaustive work, error-prone when done by humans,
bertrand> is what computers are for.)

Exactly! As to the *possibility* of inlining. On the other hand
complexity analysis to determine where it is *useful* to inline is not
quite what programs are very good at.

[ ... ]

Re: What is wrong with OO ?

[Robert Dewar]

Bjarne, in the middle of a very nice extended discussion of C++, says

"Had C++ not been relatively easy to learn and use reasonably well, it
would have disappeared long ago. By relative I mean the amount of effort
needed compared to the amount of benefit gained."


Hmmm! I don't think I buy that. People will learn what is at hand pretty
much regardless of whether something is easy to learn and use. After all
I am sure that far more programs are written using macro languages of
spread sheets, most of which are truly awful, very difficult to use, and
pretty difficult to learn. Nevertheless people do at least "sort of"
learn something regardless. Actually elsewhere in his article, Bjarne
complains of this phenomenon :-)

By the way just a quick note on spreadsheet languages. I saw a couple of
years ago a fairly comprehensive study of spread sheet programs (if you
don't think of spread sheets as a programming language, then you don't
know what people are trying to do with these programs :-) It showed that
over 50% of production spread sheets in use at Fortune 500 companies
that were studied contained serious errors. Now of course any such survey
is subject to concerns about sampling stablity. Still one would think that
such a result would spread wide alarm, but as far as I can tell everyone
shrugged and continued ("it must be the other guy who has all the errors,
I am sure my spreadsheets are fine!")

Going back to the main subject, which is the allegation that popularity
indicates ease of learning and use, I think the point is that such
popularity indicates accesibility more than anything else. By accessibility
I mean that something is available, viewed as hot, and can be learned well
enough to do *something*. Consider the situation today, students want to
learn Java, not C++, they see C++ as yesterday's language, and Java as
the language of tomorrow. Just from the incredible rate at which Java books
are cascading into bookstores, I have to guess that the rate of learning of
Java far exceeds the rate of learning of C++. But I would NOT conclude from
this that Java is easier to learn or use than C++. Maybe it is, but you
cannot conclude anything just from popularity.

Ada folks have never played the game of claiming popularity as an indicator
of any kind of quality, because they have not been able to. I realize that
C++ is in a position to make such claims, but I recommend against it, because
I think you will find that your arguments will backfire as Java becomes
the next hot language, at least for a while :-)

Robert

Re: What is wrong with OO ?

[Robert Dewar]

Chris said

"If it's that easy we would like to try it (customer #133) :-)"

Well, as I noted to him, if people have suggestions for GNAT enhancements
they should be sent to report@gnat.com with a very clear suggestion of
what feature is needed, and why it is important for a given application.

Note that the fact that something is easy to do is not in itself a good
justification for adding a feature to a language or compiler implementation.
Every feature you add adds complexity, so you have to be conservative in
adding new features and switches.

Chris, if you are really interested in trying this out, do it the simple
way first. Write an edit script that adds pragma Inline statements to all
subprograms in all specs, then recompile the program. That way you can
get some data as to whether this option would be worthwhile.

Re: What is wrong with OO ?

[Bjarne Stroustrup]

jsa@alexandria (Jon S Anthony) writes:

 > 
 > In article <fxtu3oysbzp.fsf@isolde.mti.sgi.com> Matt Austern <austern@isolde.mti.sgi.com> writes:
 > 
 > > jsa@alexandria (Jon S Anthony) writes:
 > > 
 > > > Oh, I don't know.  I think C++ was created simply because BS was
 > > > saddled with C (at ATT) and wanted _something_ that had a least _some_
 > > > abstraction capabilities in it.  Voila.  C++.  Whether it is any more
 > > > "usable" than several other options is highly open to question.  And
 > > > in fact, in general I would say the answer is "no".
 > > 
 > > It's not necessary to speculate on why Bjarne Stroustrup made the
 > > design decisions that he did: he discusses them, in a fair amount
 > > of detail, in _The Design and Evolution of C++_.
 > 
 > He also gave various descriptions of this process while it was
 > happening cira 87-89 and I happened to attend some of these.

What was happening circa 87-89 was the refinements of C++ version 2
(abstract classes, multiple inheritance, etc.) and beyond (templates,
exceptions, etc.). The initial work was much earlier (1979-1983).


 > > he was trying to create a language that, like C, made it possible to
 > > write low-level programs, but that also, like Simula, included
 > > high-level abstraction facilities.  
 > 
 > Exactly.  This came from his direct experience of having to recode a
 > Simula program for his thesis into BCPL.  The resulting nightmare was
 > not something he wished to have to go through again.  When getting to
 > ATT and seeing that it was C or nothing, he decided to "fix it" before
 > suffering the same experience.
 
This description is misleading on two counts:

(1)	I wanted something from both Simula and BCPL. Both have strengths
	and weaknesses relatively to my needs.

		Simula, had classes and a (much) stronger type system.

		BCPL had speed, easy porting of implementations, and the
		ability to easily cooperate with code fragments written
		in other languages (it was ``open'').

	The issue was not as simple as ``Simula was ideal except for
	efficiency concerns.'' That was the case for my Cambridge
	simulations, but not for the work I wanted to do later.

	The lessons I drew from my experiences in Cambridge was that I
	needed both sets of "good aspects" (and that there were "bad
	aspects" to both that I'd rather do without) NOT that one was
	strictly better than the other. This is documented in D&E and
	in papers written earlier than '87-'89. What I synthesized from
	my Cambridge rogramming experience was an initial set of criteria
	for a tool for higher-level systems programming.

(2) It was not "C or nothing" at AT&T. I was in a research organization
	that did not dictate what languages to use and several languages
	were used in various parts of AT&T at the time. The alternatives
	I knew of during the first years included C, Simula, Algol68, BCPL,
	Pascal, Modula-2, and Lisp. Naturally, I knew of more languages,
	but not every language I knew was an alternative for the work I
	was doing.

	I chose C because I rated it the best systems programming language
	at the time. It had obvious flaws, but I rated them secondary and
	manageable, whereas I considered the other alternatives to have
	more fundamental flaws relative to my needs. Being in THE hotbed
	of C at the time of course helped me appreciate the strengths of
	C and taught me how the experts compensated for its weaknesses,
	but that is a far cry from "C or nothing."


Why is any of this relevant now? Why do I bother with this debate on
"innovation?" Because some of what is said related directly to what C++
is and should be, and that again affects where it is reasonable to use
it and how it is best used. If you misunderstand some of the fundamentals
of a language, the code you write in it is going to be suboptimal in several
ways.
	
	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: What is wrong with OO ?

[Robert Dewar]

Jay said

"Here is an even more ignorant question: Why is compilation time still
a driving factor? (excluding hardcore optimizations) Obviously it
still is as I watched large systems compile lately.  But wait, wasn't
Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
faster than VC++ on my P5-100.  For fun I compiled old programs with
vintage a Turbo Pascal Compiler and it seems to compile these suckers
instantanously!"

Yes, but the quality of code turned out by your "vintage Turbo pascal
compiler" is truly horrible. If you don't mind that then fine, it is
certainly possible to turn out compilers that compile lousy code
fast. It is even possible to make compilers that generate pretty good
code locally and are very fast (e.g. Realia COBOL).

But almost in the same breath you were talking about intelligent global
optimziation, and interunit IGO at that!

Global optimization, even at the level of simply worrying about good
global register allocation and good scheduling across basic blocks,
is non-trivial, and tends to eat up large amounts of computing resources.
Furthermore, anything approximating optimal algorithms tends to be
super-linear --- at least quadratic sometimes worse -- we know of
course that truly optimal code generators are NP complete in time
complexity -- but we don't go that far).

Still this super-linear behavior means that if you try doing global
optimziation across the entire program, you are liable to use very
large amounts of computing resources. The MIPS compiler did link time
register allocation, and even just doing that resulted in very long
link times.

Of course this thread is NOT about intellignemt global optimziation, it is
about something much more trivial, which is simply doing inlining. I won't
comment on the issue of "parroting" BS on inlining in the past, but the
fact of the matter is that all compilers today implement inlining, and
that was true when Ada 83 was designed. As I have repeatedly pointed out,
the pragma Inline of Ada 83 is not about asking the compiler to inline,
it is about *permitting* the compiler to establish the body dependency
necssary to inline.

Doing all possible inlining is certainly not that hard, but it is likely
to be time consuming, since it creates a large number of body dependencies.
In a million line program, there is a lot of stuff to wade through to
find out lots of cases where inlining will NOT work, and I still suspect
that the benefits of such unrestricted searching for inlining opportunities
are dubious, especially given normal Ada style in which people do write
pragma Inlines where there is some possibility of interunit inlining
being useful.

Note that interunit inlining is not one iota more difficult than
intraunit inlining. The issue here is simply one of restricting how
much stuff the compiler must look at.

Re: What is wrong with OO ?

[Fergus Henderson]

Bart Samwel <bsamwel@wi.leidenuniv.nl> writes:

>Michael Malak wrote:
>> Yet, Microsoft Visual C++ does exactly that.  In fact, it has since
>> version 1.5 (early 1994).  MSVC++ performs "auto-inlining"
>> (Microsoft's terminology) by compiling all the source modules all at
>> once.
>
>This is a pro for VC++. However, most compilers still use the old make-
>based model, especially on Unix,

Which Unix are you thinking of?  The C++ compilers from Sun (Solaris),
SGI (IRIX), and DEC (Alpha/OSF) are all capable of automatic
cross-module inlining.

Oh, I guess you must have been thinking of Linux ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>   Richie Bielak <richieb@calfp.com> writes:
>
>   >Optimizations that require global analysis of all the classes
>   >of a program at compile time do not work if we need dynamic loading
>   >of classes at runtime, because adding a new class to a running system
>   >may invalidate optimizer's assumptions.
>
>   True, but there are plenty of cross-module optimizations (such as
>   cross-module inlining) that require the compiler to use information
>   from more than one module but don't require analysis of *all* parts of
>   a program.
>
>With any kind of static binding (and inlining is the summum in static
>binding), the possibilities of dynamically loaded code are limited.  What
>to do if a dynamically loaded class redefines some feature causing that
>feature to no longer be statically bindable?  Recompile the whole
>executable?  --Tiggr

If you allow new classes to be dynamically loaded, then the compiler
can't statically bind features of objects whose dynamic type is unknown,
but it can still statically bind features of objects whose dynamic type
is known.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Fergus said
>
>"Hence this control should normally be expressed via
>compiler options, rather than being embedded in the source code."
>
>Are you using GNAT?

Nope, not at the moment, although I have used it in the past.

>I would guess not, because you seem to assume that
>is not the case, but in fact inlining is controlled by compiler options
>in GNAT.

I know that -- in fact, I don't know of any compiler that does any
inlining for which you can't control the inlining with compiler options.

But in Ada with gnat/gnatmake, the control is normally specified using
a mixture of compiler options and embedded pragmas, and there is no
way of getting maximum inlining without scattering pragmas throughout
your code.

This contrasts with e.g. SGI C++, which has command-line options
that allow you to do full cross-module inlining without a single
`inline' or pragma in your source code.

>The pragma inlines merely enable the establishment of interunit
>dependences.

But the real interunit dependencies depend on the compiler options.
If you're compiling with gnat/gnatmake without inlining enabled, but
you have the pragmas scattered throughout your source code, then you
will get some unnecessary recompilation, won't you?

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Josh Stern]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:

>Perhaps the most important advantage of inlining is that it creates
>opportunities for other optimizations, such as constant propagation,
>strength reduction, dead code elimination, common sub-expression
>elimination, and hoisting code out of loops.  The advantage of inlining
>comes not just from avoiding the call/return, but also from being able
>to specialize the subroutines's code for each particular invocation.

Agreed!  And I would go one step further to add that when
a programmer can assume that these sort of optimizations
will take place, then it is possible to produce code at
a given level of performance efficiency that is much
more readable and maintainable than otherwise.
And it will also be faster to write this code.

-Josh

Re: OO, C++, and something much better!

[Richard Riehle]

On 6 Jan 1997, Ole-Hjalmar Kristensen FOU.TD/DELAB wrote:

> However, if I remember correctly, Alex Stepanov had earlier tried to
> implement a library like the C++ STL in Ada, but was incapable of
> doing it. This would indicate that the C++ template mechanism is more
> flexible than the Ada generics.
> Any comments?

  In an in-depth interview published in Dr. Dobbs (I do not recall the
  date) Stepanov was both complimentary of Ada and critical of it. His
  primary criticsim was the inability to create generic packages in which
  he could use generic formal package parameters.  C++ and Eiffel both
  allow something analogous to this.

  This was perceived by many as a problem in Ada 83, and "fixed" in 
  Ada 95.  ISO Standard 8652:1995 Ada does include generic formal 
  package parameters, though the model seems, to some, a little more 
  awkward to use than the same mechanism in C++ or Eiffel. STL could be
  implemented in Ada 95 if anyone wanted to take the time to do it.

  Probably a better approach than STL, for Ada 95, would be that by
  Bertrand Meyer as published in his book, "Reusable Software" from
  Prentice-Hall. 

  At a Tri-Ada conference in Los Angeles, Mr. Stepanov re-visited
  this Ada 83 criticism while on a panel discussion with Tucker Taft.
  At that time, Tucker made it clear to Mr. Stepanov that Ada 95 does
  include generic formal package parameters. 

  Richard Riehle

Re: What is wrong with OO ?

[Robert Dewar]

iFergus said

"But the real interunit dependencies depend on the compiler options.
If you're compiling with gnat/gnatmake without inlining enabled, but
you have the pragmas scattered throughout your source code, then you
will get some unnecessary recompilation, won't you?"

No, of course not. The pragma Inline's represent *permission* to create
dependencies, not a requirement to do so, and as clearly documented in 
the gnat users guide, if you do not use -gnatn, then pragma Inline is
ignored.

Re: What is wrong with OO ?

[Slavik Zorin]

Inlining in Smalltalk is a pain in the ass, esspecially when the
compiler bluntly chooses to do it for you.  Message like >>isNil which
is automatically inlined by the compiler wreeks all kinds of havoc when
one uses proxies which are subclasses of nil.  When I initialize an
instance variable with some semantic proxy which gets dereferenced when
it receives its first message (goes to DB and caches the real object in
its place), the message >>isNil to this proxy should return true, that
is the message isNil should be overriden!  But, since the compiler
rudely ignores it (how can it not, Smalltalk has not types, so there is
now way the compiler knows the expression "obj isNil" should not be
precompiled), one must replace all isNil messages to = or ~=; what a
pain!!!

How about:
	Compiler
		doNotInlineSelectors: someSelectorArray
		forMeta: aClassOrMetaclass

If Smalltalk icludes a compiler, its time to include some public
compiler APIs as well.

Slavik Zorin

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "eachus" == Robert I Eachus <eachus@spectre.mitre.org> writes:

[ ... interesting discussion on Ada generics and inling and OO ... ]

eachus>     As I pointed out, this is because the Ada type model sees classes
eachus> as sets of types all having a specific set of operations. [
eachus> ... ]
eachus>     In Eiffel, even though the actual concept of class is very
eachus> similar, the model is explicitly hierarchical. [ ... ]

Let me put here a warning to the reader: this is true only in a certain
sense that is apparent to those familiar with the Ada 95 usage of the
word "class"; in Ada 95 the word "class" denotes something more like
what is called a "protocol", for example in ``Smalltalk''-like
languages, or rather the classes that share a protocol, while "class" in
most OO languages means a single instantiable module/type.

Re: What is wrong with OO ?

[Martin ELLISON]

Robert Dewar wrote:
> 
> Simon says
> 
> "I agree it can't be done with a stupid linker, but I was just pointing out
> that inlining can be done in Ada without affecting the programmer.
> 
> You just have to leave the jobs of optimisation and (machine) code generation
> to a later stage."
> 
> Let's look at that carefully. The second paragaph implies that the link
> step redoes optimization and compilations for the entire program. Even
> with fast machines and fast compilers, I think that this is definitely
> something that would "affect the programmer".

Why can't the compiler optimise the whole program? (Assuming that it is
all written in the same language). Who says that you have to compile and
generate code for each module and then link them together? Doing so may
be quicker for a development version, but surely a production compile
can be optimised across the whole system.
---------------------------------------------------
Martin Ellison                  		mailto:martin@mpce.mq.edu.au  
				    		http://www.jrcase.mq.edu.au/~martin/

Re: What is wrong with OO ?

[Matt Telles]

Bjarne Stroustrup <bs@research.att.com> wrote in article 
> 
> First, here is the way I phrased the "learning" criteria in "The Design
> and Evolution of C++":
> 
> 	If in doubt, pick the variant of a feature that is easiest to teach

I certainly agree with this statement.

> C++ is a language primarily aimed at creating production software. Like
> all such languages, it together with its associated libraries, tools, and
> programming techniques is too large to learn quickly (unless you happen
> to be experienced in rather similar languages and techniques - and most
> students and programmers are not when they first encounter C++).
> Consequently, it must be learned in stages starting with some suitable
> subset (and a suitable subset of tools, libraries, programming
techniques).

I am curious. Does this imply that you think people should learn another
language before C++? Or is it simply that C++ is taught without the proper
emphasis on techniques. In my experience, the language is taught
syntactically, with little regard for the OO behind it. 
> 
> Many are too ambitious and try to learn too much too fast. In particular,
> many programmers focus on learning every obscure language detail rather
> than overall principles because mastery of programming language details
> is what has traditionally been valued in many programming communities.
> That way, people get lost in details.

True. Isn't it important then to emphasize the aspects of the language
which make it 
a) Maintainable and
b) Reusable?

> Traditionally, C++ has been blessed with a mass of useful libraries, and
> cursed by the absence of a good standard library. The lack of a standard
> library supplying basic types (such as string, list, and map) reinforced
> the bias of some teachers and some teaching materials towards low-level
> features and techniques that don't rely on standard library facilities.

Agreed. But where else to begin? If you are teaching C++, they say, learn
to write a linked list class, learn to write a string class. I annoyed one
of my professors long ago by handing in a linked list class that said
simply "refer to chapter xxx in the text". After all, wasn't reuse the
point we were trying to stress? How would you teach C++ without emphasizing
the low-level functions?

> I have no idea if any of this apply at your university, but I have seen
> all of those phenomena repeatedly. Usually, people manage in the end, and
> if not they try something else - which they may or may not find more
> suitable.

This is really less of an issue that the "Object Oriented Programming can
save the company" bandwagon, in my estimation.

>  > Languages like Eiffel (my personal favorite) are much more suitable
for
>  > high-level projects; Eiffel, for instance, does not burden the
>  > programmer more than needed, and has a clean, clear syntax that can
>  > even be immediately understood by people that don't know the language.
> 
> I do not personally find it so, and such claims reminds me unpleasently
> of the similar claims made for COBOL. A non-programmer can sometimes be
> convinced that he/she can read simple code, but it is far from obvious
> that this is relevant - or ever true - for production code (that will
only
> be seen by programmers anyway). 

My question is: Does the tool matter? Or is it simply an extension of the
concepts behind it. I can write object-oriented code in FORTRAN. It is
harder, but it can be done. The amount of work doesn't necessarily make it
less possible.

> Had C++ not been relatively easy to learn and use reasonably well, it
> would have disappeared long ago. By relative I mean the amount of effort
> needed compared to the amount of benefit gained.

Tell that to COBOL programmers. Or Pascal, or any of the other languages
that I have learned at one point or another in my life. The amount of
effort to learn the language becomes secondary when the boss tells you to
learn it. Why use the Microsoft compiler over the Borland compiler? Because
the company standardizes on it...

> Once a language is used by diverse user communities, one person's serious
> flaw becomes another's essential feature. Some of the aspects of C++ that
> I dislike most are deemed essential by very competent system builders.
> However, C++ has no flaw and no feature lacking that is so serious that
> it cannot be managed with reasonable effort in a project - even if they
> can be a bother and experienced programmers recognize them as such.

I have a problem here, but it is not with C++. There are certainly flaws in
the language. No serious programmer would argue that there are languages
which are flawless. The problem is that C++ lets me shoot myself in the
foot. In some cases, it aids in loading the gun and aiming it for me. The
issue is not the language, but the poor programming practices which
encourage it. Why, for example, allow the continued use of void pointers
when they lead to nothing but pain and agony in the long run (this is an
example, I understand why they were necessary). Why let me use
uninitialized pointers? Do you have any idea how many programs I have
debugged for hours because someone failed to write something as basic as:

char *p = NULL;

> 
> 
> Good luck with your projects and the language you favor, and remember
> that the world is more complicated that any of us can imagine and that
> there are ways of succeeding that we would not personally have chosen.
> 
> 	- Bjarne
> 
> Bjarne Stroustrup, AT&T Research,
http://www.research.att.com/~bs/homepage.html

I certainly won't argue with someone who created the language. My point is
simply that until we solve the problem of programmers believing they are
artists, rather than engineers, we will never have quality software.

Matt Telles

Re: What is wrong with OO ?

[Chris Morgan]

In article <dewar.852893729@merv> dewar@merv.cs.nyu.edu (Robert Dewar)
writes (regarding an "attempt automatic inline" switch :

> It certainly would be easy to implement a compiler option to force this
> treatment, but so far none of our customers has suggested this as a
> requirement.

If it's that easy we would like to try it (customer #133) :-)

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Chris Morgan]

In article <01bbff25$8b1fa3c0$26170880@annex9-38.dial.umd.edu> "Marky
Mark" <mrox@wam.umd.edu> writes:

> All you guys are talking about is inlining some code!!  Is it really worth
> this long thread?

Hint :

Yes!

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Thierry Goubier]

On 11 Jan 1997, Piercarlo Grandi wrote:

[On the subject of inlining by the compiler, with B. Meyer]

> Ideally a compiler would use profiling feedback to evaluate whether it
> is worth inlining a procedure at a given call site, by running the
> program with an without (this check ought to be done for each procedure
> at each call site for which is is possible, and every combination
> thereof :->).

I believe this technology already exists, for example in the Self 3.0 and
4.0 inlining compilers. Things like polymorphic inline caches may be used
as a tool to record profiling information for the compiler.

But I should let interested people look the Cecil/Vortex project to see
how this may be used in static compilation. What Chambers describes seems
to be relevant to this thread. A pointer is :

http://www.cs.washington.edu/research/projects/cecil/www/Overview/overview_1.html

Thierry.
___________________Thierry.Goubier@enst-bretagne.fr__________________
    Je ne suis pas un patriote car je n'ai pas peur de l'etranger
        I'm not a patriot because I don't fear foreigners
http://www-info.enst-bretagne.fr/~goubier/                    

Re: What is wrong with OO ?

[Fergus Henderson]

bs@research.att.com (Bjarne Stroustrup) writes:

>C++ is a language primarily aimed at creating production software. Like
>all such languages, it together with its associated libraries, tools, and
>programming techniques is too large to learn quickly (unless you happen
>to be experienced in rather similar languages and techniques - and most
>students and programmers are not when they first encounter C++).
>Consequently, it must be learned in stages starting with some suitable
>subset (and a suitable subset of tools, libraries, programming techniques).
>
>Many are too ambitious and try to learn too much too fast. In particular,
>many programmers focus on learning every obscure language detail rather
>than overall principles because mastery of programming language details
>is what has traditionally been valued in many programming communities.
>That way, people get lost in details.

It's not important to learn every obscure language detail, but it is
important to know all the language rules that govern the behaviour of
the subset of language features that you do use.  Without that
knowledge, it is very easy to accidentally write programs that are
non-portable or buggy.

Most C++ programmers make use of class libraries (e.g. the C++ standard
library) that use a broad range of C++ language features.  Correct use
of such class libraries may require knowledge of a large number of
those obscure details. 

(See, for example, the thread on "operator delete and template
instantiation" in comp.std.c++, or consider the many discussions in
comp.lang.c++(.moderated) on how to write "exception-safe" code.)

>Usually, people manage in the end, and
>if not they try something else - which they may or may not find more
>suitable.

Usually, people do manage in the end, but then again most software
produced today is full of bugs.  Usually it works well enough only
because it has been carefully tested and debugged, but usually it will
fail when exercised in novel ways.  Choice of programming language is
certainly not the only or the most important factor in this, but I do
think that it can make a significant difference.

>Reliability and mainatainability can be eased by a programming
>language (such as C++) but is the result of a more comprehensive
>process.

Yes, but I think one part of that comprehensive process should be
ensuring that programmers do know the language rules that govern the
behaviour of the language features that they use.  (It's not too
important for a programmer to know about the tricky cases if the
compiler will catch them, but it is important to know about possible
pitfalls that would not be caught by the compiler and would instead
result in undefined or implementation-dependent behaviour at runtime.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Fergus said, responding to me
>
>">To implement such a switch would be about thirty minutes work in GNAT, but
>>I doubt it would be found to be of much use in practice, certainly no one
>>has indicated an interest in such a switch.
>
>Let me hereby indicate interest in such a switch!
>I think it would be quite useful in practice."
>
>Well of course people are interested if it costs them nothing to be
>interested :-)

We were interested enough to implement this in the Mercury compiler.

Compiling the Mercury compiler with inter-module inlining enabled
improved performance by about 10%.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Fergus Henderson]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>Marky said
>
>"All you guys are talking about is inlining some code!!  Is it really worth
>this long thread?"
>
>Inlining is an important optimization, and becoming more so for two reasons.
[...]

Perhaps the most important advantage of inlining is that it creates
opportunities for other optimizations, such as constant propagation,
strength reduction, dead code elimination, common sub-expression
elimination, and hoisting code out of loops.  The advantage of inlining
comes not just from avoiding the call/return, but also from being able
to specialize the subroutines's code for each particular invocation.

Increasing amounts of code reuse is making this effect more important.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Pieter Schoenmakers]

In article <5bbcom$gc7@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:

   tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

   >With any kind of static binding (and inlining is the summum in static
   >binding), the possibilities of dynamically loaded code are limited.  What
   >to do if a dynamically loaded class redefines some feature causing that
   >feature to no longer be statically bindable?  Recompile the whole
   >executable?  --Tiggr

   If you allow new classes to be dynamically loaded, then the compiler
   can't statically bind features of objects whose dynamic type is unknown,
   but it can still statically bind features of objects whose dynamic type
   is known.

If a class B can be dynamically loaded, and B is a subclass of the
statically loaded (i.e. known to the compiler) class A, then every feature
invocation of an object accessed through a variable of type A, where the
actual object could just as well be a B, can not be statically bound or
inlined.  If, in that situation, you inline the feature implementation of
A, and B redefines that feature, the wrong code is executed if the actual
object (still denoted by the variable with type A) is a B and not an A.
--Tiggr

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:> Yes. However, I'm not sure whether you lose some of the power of combining 
:> genericity with inheritance through Ada's module-type distinction.
:
:I have never seen any example supporting your "unease" - by you or
:anyone else.

Oh well. 
 
:> genericity in Ada is essentially module-based and inheritance is type-based,
:> I suspect you may lose something here.
:
:Presumably you forgot to add "only" to "inheritance is type-based".

No.

:> No. Ada offers type casting in a couple of ways:
:> 
:>   1) UNCHECKED_CONVERSION and
:>   2) Address representation clauses (overlays).
:
:1. This is not "casting"

1) is; 2) isn't. But both violate safe typing.

:2. It's irrelevant anyway as these are type system trap doors (outside
:   the type system).

Yes. They're loopholes.

:> For example, by using the value of a parent type where a subrange
:> value is required.
:
:Give an example.

Would like to. There's something wrong with the system here at the moment.
If I get an example running, I'll send it to you.

:This sort of thing will be statically checked.

I agree it ought to be.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Robert Dewar writes:

:I have been trying to think of a safe way of doing this sort of thing but
:thus far haven't thought of any. :)"
:
:
:Well there obviously is no safe way of doing something whose entire purpose
:is to allow unsafe operations!

Yes, these mechanisms are inherently unsafe but their purpose is to allow 
different views of the same data. There are different ways of acheiving 
that and some ways are safer than others. For example, UNCHECKED_CONVERSION 
is safer than overlaying because the data is copied thus protecting the 
original object.

As you suggest, there's no completely safe scheme of allowing alternate
views.

:Still I would not characterize these as "type casting" in Ada. Rather I 
:would think of them as loopholes, equivalent to calling a C or assembly
:routine. Any formal analysis or discussion of the type system of Ada
:has to ignore these features, and of course any real language to be used
:for low level systems programming needs such features, but I don't think
:it is a useful excercise to include these features in the type analysis.
:
:If you like, consider Ada *minus* these two features as the interesting
:language to be analyzed. Then understand that in real life programs can
:break the bounds of this analysis to the extent they need to.

Agree.

:Note that it is not actually the unchecked conversion that is nasty, since
:the fundamental conversion can be modeled as simply a random mapping between
:values of one type to values of another type. It is that these operations
:can generate abnormal values. 
:
:This may still not be a problem, given that uninitialized values can also
:be abnormal, thus:
:
:  a := nasty_unchecked_conversion (b);
:
:is no worse that not assigning to a at all if a is uninitialized.

True.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Bart Samwel]

Fergus Henderson wrote:

> Usually, people do manage in the end, but then again most software
> produced today is full of bugs.  Usually it works well enough only
> because it has been carefully tested and debugged, but usually it will
> fail when exercised in novel ways.  Choice of programming language is
> certainly not the only or the most important factor in this, but I do
> think that it can make a significant difference.

I certainly agree! The reason I like Eiffel so much is that it has
language support for pre- and postconditions, class invariants, loop
variants and invariants and in-code assertions, which are closely linked
to the exception mechanism. In alpha, beta and gamma releases,
one can compile with a specific subset of these assertions tested at
run time, so that when a program is used in a way it didn't expect and
wasn't prepared for, the program generates an exception. With the
compilers I've seen so far, this results (when no exception handler is
installed) in displaying of the call stack and the precise class and
feature name in which the exception occurred, and the name of the
assertion that failed.

Because of this language support, many of the Eiffel programmers use
these assertions throughout all of their code. They do this because
they know that when something goes wrong, they will more often know
exactly _where_ things went wrong, and _what_ went wrong, without
debugging.

> Yes, but I think one part of that comprehensive process should be
> ensuring that programmers do know the language rules that govern the
> behaviour of the language features that they use.  (It's not too
> important for a programmer to know about the tricky cases if the
> compiler will catch them, but it is important to know about possible
> pitfalls that would not be caught by the compiler and would instead
> result in undefined or implementation-dependent behaviour at runtime.)

And indeed, C++ does have many of these pitfalls, IMHO anyway. There
are languages available that are able to catch many more of these
pitfalls. One of the reasons these languages can catch these pitfalls
better than C++ can is that they are a bit more constrained than C++,
which is not necessarily a Bad Thing.


   Bart

Re: OO, C++, and something much better!

[Robert Dewar]

Don Harrison said

"Yes, these mechanisms are inherently unsafe but their purpose is to allow
different views of the same data. There are different ways of acheiving
that and some ways are safer than others. For example, UNCHECKED_CONVERSION
is safer than overlaying because the data is copied thus protecting the
original object."


That is a misconception. Unchecked_Conversion does not require the data
to be copied. The whole point of 13.9(12) is to remove this requirement:

12   An implementation may return the result of an unchecked conversion by
reference, if the Source type is not a by-copy type.  In this case, the
result of the unchecked conversion represents simply a different (read-only)
view of the operand of the conversion.



The design principle here is that since this is a d0-it-at-your-own-risk
and make-sure-you-know-what-you-are-doing operation, it is inappropriate
to waste time trying to increase the safety of the operation. If you
want to ensure that a copy is made, you must make the copy. Note that
in the common case of:

   a := unchecked_convert (b);

the assignment makes a copy anyway (and this is the case where avoiding
the requirement for unchecked_conversion to make a copy of its own 
improves efficiency -- well to be fair the compiler can optimize this
case since it is transparent, but encouraging return by reference will
generally improve efficiency, and is unlikely to be noticeable.

GNAT does take advantage of this permission where appropriate, and UC
for large objects works by pointer punning if the alignments are
compatible (if the alignments don't match, or more specifically if the
target has a stricter alignment than the source, then of course you have
no choice but to make a copy.

Re: OO, C++, and something much better!

[Ken Garlington]

Don Harrison wrote:
> 
> Robert Dewar writes:
> 
> :I have been trying to think of a safe way of doing this sort of thing but
> :thus far haven't thought of any. :)"
> :
> :
> :Well there obviously is no safe way of doing something whose entire purpose
> :is to allow unsafe operations!
> 
> Yes, these mechanisms are inherently unsafe but their purpose is to allow
> different views of the same data. There are different ways of acheiving
> that and some ways are safer than others. For example, UNCHECKED_CONVERSION
> is safer than overlaying because the data is copied thus protecting the
> original object.

Why does UC require copying? The following code works fine with my copy
of
GNAT, and I've used the same technique on Ada 83 compilers as well...

  with Unchecked_Conversion;
  with Ada.Text_IO;
  procedure Test_UC is

    type My_Integer is new Integer;    
    function To_Int is new Unchecked_Conversion ( My_Integer, Integer );
  
    Foo : My_Integer := 7;
    Bar : constant Integer := 0; 

  begin

    To_Int(Foo) := Bar;
    Ada.Text_IO.Put_Line(My_Integer'Image(Foo));
  
  end;

Re: What is wrong with OO ?

[ak]

Chris Morgan wrote:
> 
> Mark" <mrox@wam.umd.edu> writes:
> 
> > All you guys are talking about is inlining some code!!  Is it really worth
> > this long thread?
> 
> Hint :  Yes!

If so, then please give it a proper subject name that describe 
the case instead of "what is wrong with OO"
This will help the readers to realise the content of the post ..
and anybody not interested should simply skip it

Cheers
   Ak

Re: OO, C++, and something much better!

[Robert I. Eachus]

In article <E3xprM.4pB@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

  > :> No. Ada offers type casting in a couple of ways:
  > :> 
  > :>   1) UNCHECKED_CONVERSION and
  > :>   2) Address representation clauses (overlays).
  > :
  > :1. This is not "casting"

  > 1) is; 2) isn't. But both violate safe typing.

   Casting in C normally maps to type conversions in Ada:

   foo a;
   bar b;
   ...
   b = bar(a);

   Should be translated as:

   A: Foo;
   B: Bar;
   ...
   B := Bar(A);
   -- The case changes are due to standard Ada and C style.

   This in Ada is a completely type safe conversion.  If you want to
go outside the compilers type checking, you can use
Unchecked_Conversion.  But interpret what you are doing correctly.
You the programmer are taking responsibility for doing type checking
which the compiler is unable to do.  There are many uses for
Unchecked_Conversion where this is exactly what is going on...  For
example, in one version of the ADAR components, to preserve the
visible (to the user of the components) type hierarchy, I had to do an
Unchecked_Conversion in the body of one unit--from a derived type to
its parent, but the actual derivation wasn't visible at that point in
the code.

   Doing "punning" using Unchecked_Conversion from the formal point of
view is an error, and Ada compilers are allowed (but not able in all
cases) to detect such violations and raise Program_Error.  For
example, someone was just asking how to do a boolean or on two Ada
strings.  The answer posted was more complex than necessary because it
used Unchecked_Conversion.  An Ada character can be converted to a
(universal) integer type, and "or" exists for unsigned integer types
in Ada 95.  So a better approach would be:

    function "or"(L,R: Character) return Character is
      type Byte is mod 256;
    begin return Character'Val(Byte(Character'Pos(L)) or
                               Byte(Character'Pos(R))); 
    end "or";

    function "or"(L,R: String) return String is
      Result: String(1..L'Length) := L;
    begin
      if L'Length /= R'Length then raise Constraint_Error; end if;
      for I in Result'Range loop
        Result(I) := Result(I) or R(I-R'First+1);
      end loop;
      return Result;
    end "or";

    With appropriate compiler inlining ;-) this should give results as
good or better than the non-portable version, but that is another subject.


--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: OO, C++, and something much better!

[Norman H. Cohen]

Ken Garlington wrote:

> Why does UC require copying? The following code works fine with my copy
> of
> GNAT, and I've used the same technique on Ada 83 compilers as well...
> 
>   with Unchecked_Conversion;
>   with Ada.Text_IO;
>   procedure Test_UC is
> 
>     type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );
> 
>     Foo : My_Integer := 7;
>     Bar : constant Integer := 0;
> 
>   begin
> 
>     To_Int(Foo) := Bar;
>     Ada.Text_IO.Put_Line(My_Integer'Image(Foo));
> 
>   end;

I can confirm that this works on my copy of GNAT too.  The only problem
is that this should NOT work!  (To_Int(Foo) is a function call, not a
variable.)  

RM 13.9(12) mentions that an instance of Unchecked_Conversion can return
its result by reference, meaning that the result is just another view of
the argument (i.e., there is no copying), but it is specifically stated
that this is a read-only view.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: OO, C++, and something much better!

[Don Harrison]

Jon S Anthony writes:

:> For example, by using the value of a parent type where a subrange
:> value is required.
:
:Give an example.

The following is a valid Ada83 program (and presumably valid Ada95):

procedure Test_Type_Hole is
  subtype Sub_Integer is Integer range 1 .. 10;
  I: Integer;
  S: Sub_Integer;

  procedure Use_Subtype (S: Sub_Integer) is
  begin
    null;
  end;

begin
  I := 1000;
  Use_Subtype (I);       -- System Invalid call - raises 
                         -- Constraint_Error at runtime.
end Test_Type_Hole;

So, contrary to your claim, Ada *does* permit a form of broken polymorphism.


:Don.
:=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
:Don Harrison             donh@syd.csa.com.au
:
:



-- 
Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Chris Morgan]

In article <dewar.853041031@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Chris, if you are really interested in trying this out, do it the simple
> way first. Write an edit script that adds pragma Inline statements to all
> subprograms in all specs, then recompile the program. That way you can
> get some data as to whether this option would be worthwhile.

Robert has told me how to try this out either the above method or a
local gnat tweak, either of which will be fine until (and if) we
identify a firm need for this facility.

We have found manual control of inlining using pragma inline and the
-gnatn option can offer very good performance increases, but I agree
that a brainless "attempt to inline everything" facility is a rather
marginal extra (but I will probably try it when our project gets built).

Chris
-- 
Never run with scissors.

Re: What is wrong with OO ?

[Fergus Henderson]

tiggr@es.ele.tue.nl (Pieter Schoenmakers) writes:

>fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>   If you allow new classes to be dynamically loaded, then the compiler
>   can't statically bind features of objects whose dynamic type is unknown,
>   but it can still statically bind features of objects whose dynamic type
>   is known.
>
>If a class B can be dynamically loaded, and B is a subclass of the
>statically loaded (i.e. known to the compiler) class A, then every feature
>invocation of an object accessed through a variable of type A, where the
>actual object could just as well be a B, can not be statically bound or
>inlined.

Yes, but often the compiler can prove that the actual object type
must be A, not B.  Some languages, e.g. Ada, allow the programmer to
distinguish between something of type A (meaning just type A, nothing
else) and something of type A'class (meaning something of type A
or some type that inherits from A).  Even if the language doesn't
distinguish, the compiler can often see the type used when an object
is created.

(All I'm trying to say is that you _can_ do useful inter-module
optimization even in the presence of dynamic loading.  Sheesh!)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Robert Dewar]

Ken Garlington wrote

"    type My_Integer is new Integer;
    function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"


Why on earth use an unchecked conversion here when a perfectly ordinary,
and completely safe type conversion will work just fine?

Re: OO, C++, and something much better!

[Don Harrison]

Marky Mark writes:

:Don Harrison <donh@syd.csa.com.au> wrote in article
 ^^^^^^^^^^^^
No, it was Bertrand Meyer.

:> :>> 	- A completely consistent type structure, in which 
:> :>> 	  even basic types such as INTEGER are classes,
:> :>> 	  present in the general inheritance structure.
:> :>> 	  (In C++ or Java, for example, the basic types
:> :>> 	  are completely separate from the class and inheritance
:
:Besides, in a hybrid language like C++ you could always have the best of
:both worlds - encapsulating integers as classes or using the intrinsics as
:you'd like.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Don Harrison]

Robert Dewar writes:

:Don Harrison said
:
:"Yes, these mechanisms are inherently unsafe but their purpose is to allow
:different views of the same data. There are different ways of acheiving
:that and some ways are safer than others. For example, UNCHECKED_CONVERSION
:is safer than overlaying because the data is copied thus protecting the
:original object."
:
:
:That is a misconception. Unchecked_Conversion does not require the data
:to be copied. The whole point of 13.9(12) is to remove this requirement:
:
:12   An implementation may return the result of an unchecked conversion by
:reference, if the Source type is not a by-copy type.  In this case, the
:result of the unchecked conversion represents simply a different (read-only)
:view of the operand of the conversion.

Okay. So, in both cases - whether a copy or a reference is returned -  the
source object is protected. Correct? If so, I don't follow why you might
bother making a copy:

:The design principle here is that since this is a d0-it-at-your-own-risk
:and make-sure-you-know-what-you-are-doing operation, it is inappropriate
:to waste time trying to increase the safety of the operation. If you
:want to ensure that a copy is made, you must make the copy.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: OO, C++, and something much better!

[Jeff Carter]

Don Harrison wrote:
> 
> The following is a valid Ada83 program (and presumably valid Ada95):
> 
> procedure Test_Type_Hole is
>   subtype Sub_Integer is Integer range 1 .. 10;
>   I: Integer;
>   S: Sub_Integer;
> 
>   procedure Use_Subtype (S: Sub_Integer) is
>   begin
>     null;
>   end;
> 
> begin
>   I := 1000;
>   Use_Subtype (I);       -- System Invalid call - raises
>                          -- Constraint_Error at runtime.
> end Test_Type_Hole;
> 
> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> 
Nonsense. This is a violation of an explicit precondition (that the
actual value associated with S be in the range of Sub_Integer).
-- 
Jeff Carter
Innovative Concepts, Inc.

Re: What is wrong with OO ?

[Vos nom et pr�nom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]


Bjarne Stroustrup <bs@research.att.com> a �crit dans l'article
<E3pzy4.DHE@research.att.com>...
...
> Had C++ not been relatively easy to learn and use reasonably well, it
> would have disappeared long ago. By relative I mean the amount of effort
> needed compared to the amount of benefit gained.

In an absolute way, surely C++ is harder to learn than a lot of other
languages.

Now, let's talk about the "relatively easy to learn". Another way that
effort vs benefit to relativise is language's complexity vs the complexity
of the job to do.
An exemple : if you want to display the "hello world", C++ is not the
better language. 

Conclusion : More and more complex becomes the job to do, the less and less
the language is hard to learn (still talking relatively).
...
> Deciding which member functions should be virtual is a design decision,
> not an optimization. If a designer has provided a poor base class, you
> will typically have problems beyond what can be fixed by overriding.
Just a question about it (I just posted a new thread about this) : when a
member function is better as non virtual ?


-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "goubier" == Thierry Goubier <goubier@palmarella.enst-bretagne.fr> writes:

goubier> On 11 Jan 1997, Piercarlo Grandi wrote:
goubier> [On the subject of inlining by the compiler, with B. Meyer]

piercarl> Ideally a compiler would use profiling feedback to evaluate
piercarl> whether it is worth inlining a procedure at a given call site,
piercarl> by running the program with an without (this check ought to be
piercarl> done for each procedure at each call site for which is is
piercarl> possible, and every combination thereof :->).

goubier> I believe this technology already exists, for example in the
goubier> Self 3.0 and 4.0 inlining compilers. Things like polymorphic
goubier> inline caches may be used as a tool to record profiling
goubier> information for the compiler.

From what I have read I haven't the impression that the Self compiler
actually decides _whether_ to inline an implementation using the
profiles/inference used to decide _which_ implementation *can* be
inlined.

In other words, my impression is that Self implementations use
profiles/inference to find out whetherit is _possible_ to inline at some
cal site and which implementatin(s) may be inlined, not whether it is
_useful_ to inline them, and as the latter they use heuristics not
dissimilar from those used in ``Eiffel'' or ``C++'' compilers, such as
the size of the implementation.

Perhaps somebody more familiar with the innards of the Self
implementation can throw some light on this.

BTW, the point I was making above is that one of the great worths of
inlining is that it allows merging the code of the callee in the
caller, and those provides significantly greater/easier opportunities
for optimization. However if there are several call sites of several
different potentially inlinable callees in a given caller procedure,
*which* of these calles at which call sites are worth inlining is not so
obvious for not only merging in the code at each call site with that of
the caller produces _different_ opportunities for optimization, it also
results in merging the codes of the callees as well. *Which* combination
of inlinings is optimal is thus an intricate problem.

Consider the following example (in something like C, so we have that
each implementation has exactly one interface and overload resolution,
offline and inline, does not complicate the picture)

  p(a,b,c)
  {
    .... q1(a); ....
    .... q2(b); ....
    .... q3(c); ....
    .... q1(42); ....
  }

Now each of the four calls to the three implementations might or might
now be worth inlining seaprately; for example 'q1(a)' may not be worth
inlining, but 'q1(42)' later on may well be, because it is passed a
statically know argument. Inlining each of these call sites may produce
positive interactions with the code of their caller. But it may well
happen that inling 'q2(b)' merges in code that then makes the merged in
code of 'q3(c)' significantly more optimizable, but neither call is
worth merging into 'p' on its own.

This effect actually _might_ well be important; after all if there are
several call sites of several procedures in a block it is because they
supposedly cooperate in establishing some result and are thus related,
and this perhaps could well provide good optimizations.

Thus in theory one should verify the possibility for optimization for
every possibly combination of call site inlinings... :-)

What I really think should be done, and this is not a new idea, but one
that is rarely considered, is to do compilers as symbolic reduction
engines, which operate in the domain of instances (that is operate as
intepreters) when such are known and in the domain of abstractions (that
is operate as compilers) when they are not; then inlining would become a
mere byproduct of symbolic reduction between dependent modules.

goubier> But I should let interested people look the Cecil/Vortex
goubier> project to see how this may be used in static compilation. [
goubier> ... ]

That's very interesting work. I also hope that Sun be deploying their
Self technology towards the Java compiler, for it is claimed rather
convincingly that the Self compiler technology can result in Self or
``Smalltalk'' code that runs only twice as slow as C code. Given that
Java is a more constrained sort of language than Self or ``Smalltalk'',
the same technology should get it to deliver much the same performance
as statically compiled C, while instead being dynamically compiled.

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "martin" == Martin ELLISON <martin@mpce.mq.edu.au> writes:

martin> Why can't the compiler optimise the whole program? (Assuming
martin> that it is all written in the same language). Who says that you
martin> have to compile and generate code for each module and then link
martin> them together? Doing so may be quicker for a development
martin> version, but surely a production compile can be optimised across
martin> the whole system.

This is more or less what Ole Agesen has done for type inference in Self
for the production of shrink wrapped applications...

The problem with type inference and OO is that OO modules are supposedly
designed to be as resuable as possible, that is as generic as
possible. Thus type inference returns wide sets of types for
constraints; consider for example a stack class: you can infer that all
variables in it will have a type constraint like 'Object', that is
anything.

Unfortunately such tyep inference is next to useless, for type ifnerence
results in significant safety advantages when type constraints are
narrower, and in optimization when type constrains are narrowest, that
is about a single type.

Since supposedly an OO program is composed mostly of reusable modules,
which are written to be as generic as possible, the situation seems
hopeless.

What Oleg Agesen has done for Self is a kind of type-based ``tree
shaker''; it is base don the idea that if one infers type on reusable
modules *in the context of each application in which they are reused*
then type inference can become significantly stronger (the price of
course one payus to take advantage of it is then code duplication).

So for example a matrix package which is otherwise totally generic can
in the context of a numerical application to be about matrixes of
floats, and in the context of a graphics application to be about
matrixes of integers/pixels.

What then happens is that the whole source of the application is
examined at the same time, and the type constraints of the application,
which are usually quite specific, are propagates across call sites back
to the generic reuable modules that i t references, and these are
specialized for those type constraints. The specialized modules are then
optimized mercilessly as a whole.

This technique naturally has some severe limitations; in practice it is
only useful to develop shrink wrapped, standalone applications, for it
involves a stark tradeoff between code replication and slowness.

Very vaguely similar techniques are used in recent versions of some
``C++'' implementations where template instantion/inlining is in effect
done by the linker in a somewhat clumsy iterative way; or the programmer
does inference by hand listing which templates instances are neded, like
in ``Ada''.

I may be wrong, but the Sather compiler does much the same automatic
process (less clumsily) of global inference and instantiation; in this
is is significantly helped by the rather regrettable limitation which
still exists AFAIK that Sather does not allow separate compilation, so
all modules are merged as _sources_, and (possibly slow) compilation
then on the full source (application plus reusable modules).

Re: OO, C++, and something much better!

[Michael F Brenner]

   > Why does unchecked_conversion require copying? The following 
   > code works fine with my copy of GNAT, and I've used the same 
   > technique on Ada 83 compilers as well...

First, the code in that post gets the following error message
under gnat:

    spectre% gnatmake test_uc
    gcc -c test_uc.adb
    test_uc.adb:13:12: left hand side of assignment must be a variable
    gnatmake: "test_uc.adb" compilation error

Second, unless the code generator in the compiler includes specific
copy optimizations to eliminate the copy, unchecked_conversion is
in the form of a function which logically returns a copy of the 
argument. Unless the compiler has this optimization the code will
make a copy. This is in contrast to the situation where you use
address clauses to overlay variables. Then the two variables are
permanent aliases to each other, and you do not have to copy
the value from one to the other. 

There are many algorithms in mathematics that require an object of 
one type to be considered as an object of another type, for example,
fast Fourier transforms, set membership, ASCII to numerical conversion,
braid group conjugacy, floating point normalization, integer square
root, extracting bits from binary numbers, binary radix exchange
sorting, hash codes, multiple precision integer division, parity bits,
garbage collectores, cyclical redundancy checks, segmenting, and 
pixel maps. In each of these cases, an ordinary exact number (which
happens to be a twos complement on every CPU that survived the
IBM PC era), needs to be viewed as an algebraic integer with
Addition, Subtraction, Multiplication, and Division, YET at the
same time, as a bit string to do And, Or, Xor, Substr, Set_bit,
Set_substr, First_nonzero_bit, Impl, Nand, Nor, Next_bit, and
Bit_merge sequentially according to a bit_pattern_vector. In 
all of these algorithms there is one choice of representing
the <Number As Bitstring> two different memory addresses
with an unchecked_conversion to get the data from one address
to the other. And there is another choice to represent it
as two objects of different types at the same memory
address with an address clause. Without a copy optimization
to remove the copy implied by the output of the function
unchecked_conversion (or any other function), the algorithms
which use unchecked_conversion will run slower than those
using the address overlay technique.

In some cases, such as FFTs and hash codes, that copy time can
occur several times and add up to more than the rest of the
algorithm, so there is evidence for requiring support for
address overlays, and for asking vendors to improve the  
code generation of their compilers to automatically alias
the addresses of objects being converted through unchecked
conversion to their targets address, when this can be done,
so that no copy has to take place. 

Purists sometimes forbid explicit aliasing via addressing overlays.
But that can be short-sighted for the above algorithms, because
aliasing in the address dimension also occurs whenever
a variable has more than one name: equivalences, renames, overlays, 
common variables, objects with tags or discriminants, polymorphisms, 
external objects shared with other languages, parameters passed by 
reference, and pointers. The last three are more troublesome
than the rest (for analysis tools) because they potentially 
involve multiple copies of pointers. Aliasing also occurs in 
the name dimension when a name can refer to two different objects, 
e.g., array elements, homonyms, and inheritance. 

Re: OO, C++, and something much better!

[Don Harrison]

Ken Garlington writes:

:> Yes, these mechanisms are inherently unsafe but their purpose is to allow
:> different views of the same data. There are different ways of acheiving
:> that and some ways are safer than others. For example, UNCHECKED_CONVERSION
:> is safer than overlaying because the data is copied thus protecting the
:> original object.
:
:Why does UC require copying? 

It may not, as Robert Dewar suggests. However, IMO, the source object should
be protected from corruption by any alternative view of its data. One way is
by copying it.

BTW, your program contains an illegal assignment to a function! :)

:    To_Int(Foo) := Bar;
                 ^^


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Vos nom et pr�nom]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]


Piercarlo Grandi <piercarl@sabi.demon.co.uk> a �crit dans l'article
<yf3afqg12ho.fsf@sabi.demon.co.uk>...
> >>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:
> 
> bertrand> The ISE Eiffel compiler performs inlining completely
> bertrand> automatically.  There is no "pragma inline" or comparable
> bertrand> programmer intervention, since it is not the programmer's job
> bertrand> to worry about whether a routine is inlinable or not. This is
> bertrand> a job for a compiler.
> 
> It seems contrary to reasonabless: there are many contexts where
> inlining is not necessary and others in which it is important, *even for
> the same procedure*. Thus there is (usually) a space/time tradeoff, but
> *at each call site*. It sounds astonishing to me an argument that the
> compiler should try to second guess or infer space/time tradeoffs
> (except perhaps in the simplest cases), in addition to doing its job of
> compiling valid translations of a source.
etc...

Here's my 2cts...
If the function is very short, it's obvious for the compiler to
automatically inline it.
When it's long, it's also obvious not to make it inline.
But where is the point where the short function becomes a long function ?
For all these cases, it's the programmer's responsability to inline or not
regarding size vs speed.

-- 
Chris
"The nail pulling up calls the hammer"
                                     zen proverb

Re: What is wrong with OO ?

[Jay Martin]

lga@sma.ch (Laurent Gasser) writes:

>In article <dewar.853091062@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>> Jay said
>> 
>> "Here is an even more ignorant question: Why is compilation time still
>> a driving factor? (excluding hardcore optimizations) Obviously it
>> still is as I watched large systems compile lately.  But wait, wasn't
>> Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
>> faster than VC++ on my P5-100.  For fun I compiled old programs with
>> vintage a Turbo Pascal Compiler and it seems to compile these suckers
>> instantanously!"
>> 
>> Yes, but the quality of code turned out by your "vintage Turbo pascal
>> compiler" is truly horrible. 
>[ sound arguments about global optimization and inlining deleted ]

>I am no more sure about the fact for Turbo Pascal.  But it may had used 
>the same strategy than Think Pascal on Mac (once a Lightspeed product, 
>still sold by Symantech today, a record sale life span).  The compilation 
>was extra speedy because the syntax tree building was embodied in the editor.

>While you typed down the source, the syntax was checked and the front
>part of the compilation (decorated syntax tree) was done.

Turbo Pascal was a normal compiler.  

Going back to the original question: I understand that a compiler can
spend an practically infinite time optimizing, but when optimizations
are disabled or restricted to the typical simple ones it still seems
to me that compilers have not kept up with processor speeds.  Its as
if compilers are parallelling the code bloat practices of other
software areas, eating processor cycles as they come available.
Suppose optimizations give a factor of 2X-3X, why would I bother
turning on the time consuming optimizations early in a project needing
a rapid development cycle?  (Though optimized builds could be continiously
be built as a background task)  

Jay

Re: OO, C++, and something much better!

[Don Harrison]

Jeff Carter writes:

:> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
:> 
:Nonsense. This is a violation of an explicit precondition (that the
:actual value associated with S be in the range of Sub_Integer).

It's both and it shows that Ada is not typesafe.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Bjarne Stroustrup]

"Matt Telles" <matttelles@sprynet.com> writes:

 > Bjarne Stroustrup <bs@research.att.com> wrote in article 
 > > 
 > > First, here is the way I phrased the "learning" criteria in "The Design
 > > and Evolution of C++":
 > > 
 > > 	If in doubt, pick the variant of a feature that is easiest to teach
 > 
 > I certainly agree with this statement.
 > 
 > > C++ is a language primarily aimed at creating production software. Like
 > > all such languages, it together with its associated libraries, tools, and
 > > programming techniques is too large to learn quickly (unless you happen
 > > to be experienced in rather similar languages and techniques - and most
 > > students and programmers are not when they first encounter C++).
 > > Consequently, it must be learned in stages starting with some suitable
 > > subset (and a suitable subset of tools, libraries, programming
 > techniques).
 > 
 > I am curious. Does this imply that you think people should learn another
 > language before C++? Or is it simply that C++ is taught without the proper
 > emphasis on techniques. In my experience, the language is taught
 > syntactically, with little regard for the OO behind it. 

I don't really mind, you can learn C++ as a first language - and use it
as a vehicle for learning sound concepts, principles, and techniques
- or learn it later. I have seen both paths work well - and I have seen
both fail. I have a natural bias for "C++ first" especially for people
who aims at becoming professional software developers, but I am strongly
of the opinion that every programmer should be comfortable in more than
one language.

I do object to the "toy approach" to teaching programming: Give people
a tool that is great for writing little demos, let them produce a few
of those without hitting any hard conceptual barriers, any efficiency
problems, and any limitations of the tool/language. Then let them go
on to something else - such as "high-level design" or management.

That is the way to produce non-programmers with unrealistic estimates
of their own ability and a total lack of understanding of the problems
faced by people who produce production code.

The "the language is taught syntactically, with little regard for
the OO behind it" is exactly what I'm arguing against - as I have
done consistently over the years.


 > > Many are too ambitious and try to learn too much too fast. In particular,
 > > many programmers focus on learning every obscure language detail rather
 > > than overall principles because mastery of programming language details
 > > is what has traditionally been valued in many programming communities.
 > > That way, people get lost in details.
 > 
 > True. Isn't it important then to emphasize the aspects of the language
 > which make it 
 > a) Maintainable and
 > b) Reusable?

I think I do.


 > > Traditionally, C++ has been blessed with a mass of useful libraries, and
 > > cursed by the absence of a good standard library. The lack of a standard
 > > library supplying basic types (such as string, list, and map) reinforced
 > > the bias of some teachers and some teaching materials towards low-level
 > > features and techniques that don't rely on standard library facilities.
 > 
 > Agreed. But where else to begin? If you are teaching C++, they say, learn
 > to write a linked list class, learn to write a string class. I annoyed one
 > of my professors long ago by handing in a linked list class that said
 > simply "refer to chapter xxx in the text". After all, wasn't reuse the
 > point we were trying to stress? How would you teach C++ without emphasizing
 > the low-level functions?


Here is one way:

Initially, you supply people with a good set of basic classes: vector,
list, map, string, iostreams, simple graphics. Nothing too fancy or
daunting. Based on that, you teach the basics of writing small programs
using variables, constants, loops, functions. Then teach how to write
simple classes - such as dates and strings. Then teach how to add classes
to a class hierarchy and how to build a class hierarchy.

Templates are first simply used where needed, and defining new ones is done
wherever the examples need parameterization. The initial set of classes
provides a good set of examples for "dissecting" to understand class design
and implementation. During that "dissection" you introduce the lower-level
facilities as needed to explain the implementation.


 > > I have no idea if any of this apply at your university, but I have seen
 > > all of those phenomena repeatedly. Usually, people manage in the end, and
 > > if not they try something else - which they may or may not find more
 > > suitable.
 > 
 > This is really less of an issue that the "Object Oriented Programming can
 > save the company" bandwagon, in my estimation.
 > 
 > >  > Languages like Eiffel (my personal favorite) are much more suitable
 > for
 > >  > high-level projects; Eiffel, for instance, does not burden the
 > >  > programmer more than needed, and has a clean, clear syntax that can
 > >  > even be immediately understood by people that don't know the language.
 > > 
 > > I do not personally find it so, and such claims reminds me unpleasently
 > > of the similar claims made for COBOL. A non-programmer can sometimes be
 > > convinced that he/she can read simple code, but it is far from obvious
 > > that this is relevant - or ever true - for production code (that will
 > only
 > > be seen by programmers anyway). 
 > 
 > My question is: Does the tool matter? Or is it simply an extension of the
 > concepts behind it. I can write object-oriented code in FORTRAN. It is
 > harder, but it can be done. The amount of work doesn't necessarily make it
 > less possible.

Tools matter. Languages matter. If I didn't think I was seeing evidence of
significant improvements I would have stopped working on C++ years ago.

A good language helps solve some of our problems building good systems,
but it is only part of a solution. This is one reason that there has been
much more good software written in languages deemed bad than in languages
proclaimed great. Often people who focus on language issues are blindsided
by the non-language issues.


 > > Had C++ not been relatively easy to learn and use reasonably well, it
 > > would have disappeared long ago. By relative I mean the amount of effort
 > > needed compared to the amount of benefit gained.
 > 
 > Tell that to COBOL programmers. Or Pascal, or any of the other languages
 > that I have learned at one point or another in my life.

Actually, I have. I have taught C++ to people with COBOL and Pascal
backgrounds (it is easier to those with Pascal background - on average
as easy as to teach it to people with a C background though the problems
faced by Pascal and C programmers tend to differ in interesting ways).

However, it is important to remember the difference between learning
enough to write a student exercise and enough to write a piece of code
to be used by others. I tend to be strongly focussed on the latter -
and sometimes underestimate the importance of the former.


 > The amount of
 > effort to learn the language becomes secondary when the boss tells you to
 > learn it. Why use the Microsoft compiler over the Borland compiler? Because
 > the company standardizes on it...

In an ideal world, people would choose their own languages and their own
tools. I have had the priviledge to deal primarily with people who did
have a choice. There are more of those than is sometimes claimed. Often,
the problem is not lack of choice but that the choice is conditioned by
what others are doing (or what others are perceived to be doing or what
other people are perceived to soon be doing ...).

To be useful, a piece of software has to fit into a very complicated mesh
of real-world concerns - of which the choice of programming langauge is
typically not the most important.


 > > Once a language is used by diverse user communities, one person's serious
 > > flaw becomes another's essential feature. Some of the aspects of C++ that
 > > I dislike most are deemed essential by very competent system builders.
 > > However, C++ has no flaw and no feature lacking that is so serious that
 > > it cannot be managed with reasonable effort in a project - even if they
 > > can be a bother and experienced programmers recognize them as such.
 > 
 > I have a problem here, but it is not with C++. There are certainly flaws in
 > the language. No serious programmer would argue that there are languages
 > which are flawless. The problem is that C++ lets me shoot myself in the
 > foot. In some cases, it aids in loading the gun and aiming it for me. The
 > issue is not the language, but the poor programming practices which
 > encourage it. Why, for example, allow the continued use of void pointers
 > when they lead to nothing but pain and agony in the long run (this is an
 > example, I understand why they were necessary).

As you point out, they are unavoidable so how could I ban them without
saying "go and use C whenever you need to do low-level stuff?" I do not
believe in making a language prettier by making it incomplete and leaving
programmers to write significant parts of their code in a language with
no support for abstraction.


 > Why let me use
 > uninitialized pointers? Do you have any idea how many programs I have
 > debugged for hours because someone failed to write something as basic as:
 > 
 > char *p = NULL;

If I had designed C++ today, every variable that did not have a default
constructor would have to be initialized. When I wrote the first C++
compiler, I had it issue a warning whenever you tried to use an uninitialized
variable. However, I could not ban uninitialized variables without getting
into an unwinnable fight with the C community. I have been quite annoyed
that the quality of warnings against legal but almost certainly wrong
constructs have on average declined. I can hope that they will improve
again now we (almost) have a standard but there is typically no way of
forcing people to do what they really don't want to do.

See "The Design and Evolution of C++" for a discussion of such issues.


 > > Good luck with your projects and the language you favor, and remember
 > > that the world is more complicated that any of us can imagine and that
 > > there are ways of succeeding that we would not personally have chosen.
 > > 
 > > 	- Bjarne
 > > 
 > > Bjarne Stroustrup, AT&T Research,
 > http://www.research.att.com/~bs/homepage.html
 > 
 > I certainly won't argue with someone who created the language. My point is
 > simply that until we solve the problem of programmers believing they are
 > artists, rather than engineers, we will never have quality software.

Maybe, more programmers believe that they are artists than actually are,
and more programmers believe they are engineers than actually are.

I suspect that I'll take the artist and the engineer any time I can find
them, but the real issue is than many aren't even craftsmen yet. We are
seeing progress, but we have a long way to go. In my opiion, education
has to be major part of any solution. This may sound obvious, but there
seems to be no shortage of people in industry who would prefer to reduce
software production to a semi-skilled activity - in which case we would
have to reduce the amount of education and replace most current programmers
with people with less education and more training in following rules.

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: What is wrong with OO ?

[Bjarne Stroustrup]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

 > Bjarne, in the middle of a very nice extended discussion of C++, says
 > 
 > "Had C++ not been relatively easy to learn and use reasonably well, it
 > would have disappeared long ago. By relative I mean the amount of effort
 > needed compared to the amount of benefit gained."
 > 
 > Hmmm! I don't think I buy that. People will learn what is at hand pretty
 > much regardless of whether something is easy to learn and use.
 > ...
 > Going back to the main subject, which is the allegation that popularity
 > indicates ease of learning and use,

I don't think I claimed that, and I don't think that I have to. C++ use grew
very nicely for years without hype. I base my statement on years of looking
at C++ use, teching, and learning - many of those years were before anyone
was given time off from their day job to learn C++.

I think that if C++ was as hard to understand and use as some people claim,
it would have failed to become popular in the first place and would have
vanished under the continuous barrage of fair and unfair criticism - despite
its (eventual) popularity.

 >  I think the point is that such
 > popularity indicates accesibility more than anything else. By accessibility
 > I mean that something is available, viewed as hot, and can be learned well
 > enough to do *something*. Consider the situation today, students want to
 > learn Java, not C++, they see C++ as yesterday's language, and Java as
 > the language of tomorrow. Just from the incredible rate at which Java books
 > are cascading into bookstores, I have to guess that the rate of learning of
 > Java far exceeds the rate of learning of C++. But I would NOT conclude from
 > this that Java is easier to learn or use than C++. Maybe it is, but you
 > cannot conclude anything just from popularity.

It is amazing what hype and serious marketing dollars can do, but what
little objective data I can lay my hands on indicates that C++ use is
still increasing very nicely. However, I have my doubts whether all of
those books will actually help the Java community. 

I have often found myself wondering if the C++ wouldn't have been much better
for all concered had there (just) been two dozen good C++ books instead of
the 400+ books that mostly fail to teach the basic principles and mostly
lead students and programmers astray. The snag, of course, is that we have
no mechanism of separating the good from the bad. I doubt such a mechanism
could exist - at least while things change as fast as they do in our industry
and we have little agreement on what is good and bad.

 > Ada folks have never played the game of claiming popularity as an indicator
 > of any kind of quality, because they have not been able to. I realize that
 > C++ is in a position to make such claims, but I recommend against it, because
 > I think you will find that your arguments will backfire as Java becomes
 > the next hot language, at least for a while :-)

Thanks for the advice. The furthest I go is to claim that unless C++
had at least some of the virtues I claim for it, it would have died during
the early years where there were essentially no C++ marketing and alternatives
languages with marketing dollars behind them existed.

Naturally, even that is invariably mistaken for the disreputable "5 million
morons cannot be wrong" argument :-(

	- Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

Re: OO, C++, and something much better!

[Don Harrison]

Robert I. Eachus writes:

:   Casting in C normally maps to type conversions in Ada:

Okay.


Don.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Don Harrison             donh@syd.csa.com.au

Re: What is wrong with OO ?

[Laurent Gasser]

In article <dewar.853091062@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Jay said
> 
> "Here is an even more ignorant question: Why is compilation time still
> a driving factor? (excluding hardcore optimizations) Obviously it
> still is as I watched large systems compile lately.  But wait, wasn't
> Turbo Pascal long ago seemly compile stuff faster on a 4.77MHz PC
> faster than VC++ on my P5-100.  For fun I compiled old programs with
> vintage a Turbo Pascal Compiler and it seems to compile these suckers
> instantanously!"
> 
> Yes, but the quality of code turned out by your "vintage Turbo pascal
> compiler" is truly horrible. 
[ sound arguments about global optimization and inlining deleted ]

I am no more sure about the fact for Turbo Pascal.  But it may had used 
the same strategy than Think Pascal on Mac (once a Lightspeed product, 
still sold by Symantech today, a record sale life span).  The compilation 
was extra speedy because the syntax tree building was embodied in the editor.

While you typed down the source, the syntax was checked and the front
part of the compilation (decorated syntax tree) was done.

So, when you finally decided to see it running, it only had to generate
the object code and link.

The strategy seemd to be one cause of the abandon of Think Pascal (it still 
only generates 68K, and never did the PowerPC leap).  Today, compiler favor 
a much clearer separation with text editors.

-- 
Laurent Gasser (lga@sma.ch)
Computers do not solve problems, they execute solutions.

Re: What is wrong with OO ?

[Jonas Nygren]

Laurent Gasser wrote:
> 
> I am no more sure about the fact for Turbo Pascal.  But it may had used
> the same strategy than Think Pascal on Mac (once a Lightspeed product,
> still sold by Symantech today, a record sale life span).  The compilation
> was extra speedy because the syntax tree building was embodied in the editor.
> 
> While you typed down the source, the syntax was checked and the front
> part of the compilation (decorated syntax tree) was done.
> 
> So, when you finally decided to see it running, it only had to generate
> the object code and link.
> 

Ah yes, Lightspeed, in my case C, defines what an IDE should be.
Lightning
fast compilation, as Laurent stated, but also linking. LC did not really
link the application when it was inside the IDE, only if you wanted to 
generate a standalone app. The '.o' files were kept linked together in
memory 
and after a file had been compiled these linked '.o' files were patched
up
to link in the new '.o' file, and then the IDE executed the image given
by the
linked '.o' files.

I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
fix something small - compile - link - ready to test again' was under 30
secs,
with a M68000 ~7 MHz!!

I still haven't found anything as fast :-( 

/jonas

Re: OO, C++, and something much better!

[Richard Kenner]

In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>equally if you do something like
>
>   (x = p; x < &p[10]; p += 3)
>
>you can find you have an infinite loop, all quite in accordance with the
>C semantics, although somewhat surprising.

This case must work.  Such a reference to the end of an object is required
to be treated like a reference within the object.

Re: OO, C++, and something much better!

[Ken Garlington]

Robert Dewar wrote:
> 
> Ken Garlington wrote
> 
> "    type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> 
> Why on earth use an unchecked conversion here when a perfectly ordinary,
> and completely safe type conversion will work just fine?

Because then it wouldn't demonstrate the use of an unchecked conversion,
would it?
(I _knew_ someone was going to ask that. :)

Anyway, if it didn't already get posted, the example is wrong. It works
with GNAT 3.05,
but is flagged as a compile-time error in 3.07. However, via access
values, an
unchecked conversion could still be used without creating a copy, so the
comment is
still valid: using address specs to create an overlay should not be
significantly less/more safe than unchecked_conversion, at least not for
the reason originally given...

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Ole-Hjalmar Kristensen FOU.TD/DELAB]

In article <5bie2d$eat$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

   In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
   >equally if you do something like
   >
   >   (x = p; x < &p[10]; p += 3)
   >
   >you can find you have an infinite loop, all quite in accordance with the
   >C semantics, although somewhat surprising.

   This case must work.  Such a reference to the end of an object is required
   to be treated like a reference within the object.

Yes, indeed it must work, and it does, but it IS an infinite loop.
So it is probably not what you wanted the program to do....

Ole-Hj. Kristensen

Re: OO, C++, and something much better!

[Fergus Henderson]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>>equally if you do something like
>>
>>   (x = p; x < &p[10]; p += 3)
>>
>>you can find you have an infinite loop, all quite in accordance with the
>>C semantics, although somewhat surprising.
>
>This case must work.  Such a reference to the end of an object is required
>to be treated like a reference within the object.

No, you missed the subtle point of Robert Dewar's example.
(Robert could obviously get a job advertising PC-LINT if he wanted ;-)
If it was `p++' rather than `p += 3', you would be right, but
since it is `p += 3', the behaviour is undefined -- ANSI/ISO C
only allows a reference to one past the end of an object, not
two past the end.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: OO, C++, and something much better!

[Ken Garlington]

Keith Thompson wrote:
> 
> In <dewar.853194201@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> > Ken Garlington wrote
> >
> > "    type My_Integer is new Integer;
> >     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> >
> >
> > Why on earth use an unchecked conversion here when a perfectly ordinary,
> > and completely safe type conversion will work just fine?
> 
> 1. I think it was meant to be a simple example of what you can do
>    Ada.Unchecked_Conversion, not a useful program.
> 
> 2. A simple conversion wouldn't work; you can't assign to a conversion
>    (unless passing it as an "out" or "in out" parameter is considered
>    assignment).
> 
> 3. Actually, Unchecked_Conversion won't work either; an earlier version
>    of GNAT incorrectly allowed assignment to an Unchecked_Conversion.

As do various Ada83 compilers (which is why I tried it in the first
place!)

> If you really want a writable view of an object with a type other than the
> object's declared type, you can use 'Access and Unchecked_Conversion on
> access types, though it's generally simpler to do an Unchecked_Conversion
> on the type itself in the opposite direction.  Be careful; it's really
> easy to get erroneous execution this way.
> 
> --
> Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
> TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
> 10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
> "SPOON!" -- The Tick

--
LMTAS - The Fighter Enterprise - "Our Brand Means Quality"
For job listings, other info: http://www.lmtas.com or
http://www.lmco.com

Re: OO, C++, and something much better!

[Keith Thompson]

In <dewar.853194201@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> Ken Garlington wrote
> 
> "    type My_Integer is new Integer;
>     function To_Int is new Unchecked_Conversion ( My_Integer, Integer );"
> 
> 
> Why on earth use an unchecked conversion here when a perfectly ordinary,
> and completely safe type conversion will work just fine?

1. I think it was meant to be a simple example of what you can do
   Ada.Unchecked_Conversion, not a useful program.

2. A simple conversion wouldn't work; you can't assign to a conversion
   (unless passing it as an "out" or "in out" parameter is considered
   assignment).

3. Actually, Unchecked_Conversion won't work either; an earlier version
   of GNAT incorrectly allowed assignment to an Unchecked_Conversion.

If you really want a writable view of an object with a type other than the
object's declared type, you can use 'Access and Unchecked_Conversion on
access types, though it's generally simpler to do an Unchecked_Conversion
on the type itself in the opposite direction.  Be careful; it's really
easy to get erroneous execution this way.

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: What is wrong with OO ?

[Patrick Doyle]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]


In article <01bbd23a$5b667cc0$LocalHost@christophe-leph>,
Vos nom et pr�nom <gaijin@infonie.fr> wrote:
>Just a question about it (I just posted a new thread about this) : when a
>member function is better as non virtual ?

  Suppose a function does some important manipulation of private data
members.  If it were virtual, then an heir class could override this
function without ever calling it, and the data manipulation would never
happen.  This could leave the object in an invalid state.  In C++, the
only way to prevent this is by NOT declaring the function virtual.

  In Eiffel, I presume, this could be prevented using postconditions?


-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Patrick Doyle]

In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
Risto Lankinen <rlankine@us.oracle.com> wrote:
>
>Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
><E440xD.Lu0@ecf.toronto.edu>...
>> 
>>   Suppose a function does some important manipulation of private data
>> members.  If it were virtual, then an heir class could override this
>> function without ever calling it, and the data manipulation would never
>> happen.  This could leave the object in an invalid state.  In C++, the
>> only way to prevent this is by NOT declaring the function virtual.
>
>This is true.  I would like to add, that if *both* the important data
>manipulation *and* virtualness are needed, then there is still a way
>to do it.  Here's how:
>
>--------------------------------------------------
>class Base
>{
>private:
>   virtual void Function_imp()

  I was not aware that private virtual functions existed.  Can a descendant
class override this function even though it does not have access to it?

>Note that *IF* the Java keyword 'final' was also in C++ (in Java
>it means that a member function cannot be overridden, or a class
>cannot be derived) then in the example, 'Base::Function()' could
>itself be a virtual function derived from yet-another-base, but
>then overridden and declared as 'final'.  Obviously this would
>make it possible to stack postcondition checks by doing the same
>'final'-trick to 'Derived::Function_imp()' and have it call, say,
>private virtual 'Function_imp_imp()' that *its* derived classes
>can override...

  Woah, sorry, you lost me here.  Do you have an example of what you're
thinking of?

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E440xD.Lu0@ecf.toronto.edu>...
> 
>   Suppose a function does some important manipulation of private data
> members.  If it were virtual, then an heir class could override this
> function without ever calling it, and the data manipulation would never
> happen.  This could leave the object in an invalid state.  In C++, the
> only way to prevent this is by NOT declaring the function virtual.

This is true.  I would like to add, that if *both* the important data
manipulation *and* virtualness are needed, then there is still a way
to do it.  Here's how:

--------------------------------------------------
class Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Base' stuff
   }

public:
   void Function();
   {
      // do some important manipulation of private data
      Function_imp();
      // do more important manipulation of private data
      // enforce postconditions
};

class Derived : public Base
{
private:
   virtual void Function_imp()
   {
      // enforce preconditions
      // do 'Derived' stuff
   }
};
--------------------------------------------------

Then, any derived class can override the implementation, while
the public interface remains the same (hence the postconditions
are checked whenever the method is called, and the integrity of
the object becomes easier to maintain).

Note that *IF* the Java keyword 'final' was also in C++ (in Java
it means that a member function cannot be overridden, or a class
cannot be derived) then in the example, 'Base::Function()' could
itself be a virtual function derived from yet-another-base, but
then overridden and declared as 'final'.  Obviously this would
make it possible to stack postcondition checks by doing the same
'final'-trick to 'Derived::Function_imp()' and have it call, say,
private virtual 'Function_imp_imp()' that *its* derived classes
can override...

terv: Risto

Re: What is wrong with OO ?

[Risto Lankinen]

Hi!

Patrick Doyle <doylep@ecf.toronto.edu> wrote in article
<E448IK.4qI@ecf.toronto.edu>...
> In article <01bc03db$2de477c0$ba1e1990@ap352pc.us.oracle.com>,
> 
>   I was not aware that private virtual functions existed.  Can a
descendant
> class override this function even though it does not have access to it?

Sure can.  The descendant cannot, however, *call* the base version.
Also, the descendant is responsible for using the proper protection
for its own version: 'Derived::Function_imp' can be made public if
that is desired.

> >Note that *IF* the Java keyword 'final' was also in C++ (in Java
[blah blah blah]
> >can override...
> 
>   Woah, sorry, you lost me here.  Do you have an example of what you're
> thinking of?

Here is (in a hypothetical language that looks like C++ but has a
keyword 'final' to declare a class that cannot be derived from; or
a class method that cannot be overridden by a method in a derived
class):

---------------------------------------------
class Bottom
{
public:
   virtual void do()
   {
      // do what bottom objects do
   }
};

class Middle : public Bottom
{
private:
   virtual void do_imp()
   {
      // do what middle objects do
   }

public:
   final void do() // <<<<<<<<<<<< see below (#)
   {
      // middle preconditions
      do_imp();
      // middle postconditions
   }
};

class Top
{
private:
   virtual void do_imp()
   {
      // do what top objects do
   }
};
---------------------------------------------

Note (#):
In original example this function was a non-virtual.  Here, it is
an inherited virtual.  Alas, declaring it 'final' prevents it from
being overridden by any derived class.

If 'Middle::do()' was non-final, the programmer of class 'Top' may
be tempted to override that instead of 'do_imp()', shortcutting the
integrity maintenance performed by 'Middle::do()'.

Furthermore, if class 'Top' has a reason to make its postcondition
more strict, it can declare 'do_imp()' as 'final', and have its own
implementation call a private virtual 'do_imp_imp()'.  Here is such
modified definition of class 'Top' (note how it looks like 'Middle'
in previous example):

---------------------------------------------
class Top
{
private:
   virtual do_imp_imp()
   {
      // do what top objects do
   }

   final void do_imp()
   {
      // top preconditions
      do_imp_imp();
      // top postconditions
   }
};
---------------------------------------------

When a 'Top' object is passed to a function as a 'Base' pointer
or a reference, it performs the following calls, when 'do()' is
called:

   do() [Middle]
    + // middle preconditions
    + do_imp() [Top]
    |  + // top preconditions
    |  + do_imp_imp() [Top]
    |  |  + // do what top objects do <<<<<<<< see below (@)
    |  + // top postconditions
    + // middle postconditions

Note (@):
Because 'Middle::do()' and 'Top::do_imp()' would be final, the
only function that could be overridden is do_imp_imp().  Note,
that doing so cannot by-pass any of the integrity maintenance
that are performed by some of its base classes.

terv: Risto L.

Re: What is wrong with OO ?

[Mark Woodruff]

Vos nom et pr�nom wrote:

> If the function is very short, it's obvious for the compiler to
> automatically inline it.
> When it's long, it's also obvious not to make it inline.

When should a call to Ackerman() be inlined? Or exit()?

Key questions seem to be: 

What information is required to make the decision?
Can the information be represented programatically?
Can an algorithm be written to make the decision?

I'm not convinced it's decidable because performance criteria frequently can't be 
determined in advance. Should a function be inlined if the resultant code pushes 
code onto a new page and causes page faults?
-- 
My views may reflect the presence of the company I'm in
but don't reflect my company's views nor my clients.

Re: What is wrong with OO ?

[Lawrence G. Mayka]

bs@research.att.com (Valerie Torres) wrote:

>In the area of exceptions, C++ may have added something important:
>C++ exceptions can be of arbitrary type and inheritance is taken
>into account when catching an exception. This provides important
>possibilities for grouping exceptions that I don't know precedence
>for (though the need for grouping has been known for decades).

The use of inheritance in defining and handling conditions dates at
least back to Symbolics' New Error System, circa 1984, which was the
forerunner of the Pittman Condition System, circa 1985.  The latter
quickly found its way into the other commercial Common Lisp
implementations and was incorporated into ANSI Common Lisp.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "gaijin" =3D=3D Vos nom et pr=E9nom <gaijin@infonie.fr> writes:

piercarl> It seems contrary to reasonabless: there are many contexts
piercarl> where inlining is not necessary and others in which it is
piercarl> important, *even for the same procedure*. Thus there is
piercarl> (usually) a space/time tradeoff, but *at each call site*. It
piercarl> sounds astonishing to me an argument that the compiler should
piercarl> try to second guess or infer space/time tradeoffs (except
piercarl> perhaps in the simplest cases), in addition to doing its job
piercarl> of compiling valid translations of a source.

gaijin> Here's my 2cts...  If the function is very short, it's obvious
gaijin> for the compiler to automatically inline it.  When it's long,
gaijin> it's also obvious not to make it inline.  But where is the point
gaijin> where the short function becomes a long function ?  For all
gaijin> these cases, it's the programmer's responsability to inline or
gaijin> not regarding size vs speed.

Those are good points, but not necessarily true. The situation is
*really* subtler than most people think.

Consider the two extremes:

Should we always inline very short functions?

  Not necessarily, because this makes a number of activities, from
  profiling to debugging/backtracing rather harder, for it breaks simple
  correspondences between the structure of the source and that of the
  generated code. Also, it is not always worth doing it, and by default
  it should not be done unless there is a clear advantage; consider for
  example an inline functione like:

    vs(x) { return (x > 0) ? take_a_long_time : also_take_along_time)() ; }

Should we always leave outofline very long functions?

  Not necessarily, because when they are inlined they might shrink
  dramatically. Consider:

    vl(x) { if (x < 0) return 0; else { ... /*lots of lines*/ }; }
    ....
    vl(-23); // this is worth inlining

Again the choice depends often on the context of the call site.

Re: What is wrong with OO ?

[Michael Malak]

In article <5bo7nq$b8b@news.istar.ca>,
Tom Bushell <tbushell@fox.nstn.ns.ca> wrote:
>
>As I believe someone else already pointed out, the C++ compiler
>convention of creating an optimized, native code, standalone
>executable file on disk is ass backwards - this should be a batch
>operation that is performed once to create the production version of
>the program.  The rest of the time, it is much more important to allow
>rapid turnaround for modifications, at the expense of execution speed
>if necessary.

The reason C++ is not interpreted is because there don't even exist
correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
And the reason for that, of course, is because C++ is a complicated,
quickly evolving (mutating?) language.

-- 
Michael Malak         Magic forwarding e-mail address:
Washington, DC        malak@acm.org

Re: What is wrong with OO ?

[Tom Bushell]

On Wed, 15 Jan 1997 14:13:05 +0100, Jonas Nygren
<ehsjony@ehs.ericsson.se> wrote:

>
>I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
>fix something small - compile - link - ready to test again' was under 30
>secs,
>with a M68000 ~7 MHz!!

30 seconds seems like a lifetime after you get used to RAD languages
like Smalltalk, VB, or Prograph.  Turnaround is instant, and you can
usually fix the program _while it is running_ - no need to even
restart.  This allows the programmer to much more easily stay in an
immersive state of "flow", and probably accounts for a large portion
of the productivity gains possible with these language/environments.

As I believe someone else already pointed out, the C++ compiler
convention of creating an optimized, native code, standalone
executable file on disk is ass backwards - this should be a batch
operation that is performed once to create the production version of
the program.  The rest of the time, it is much more important to allow
rapid turnaround for modifications, at the expense of execution speed
if necessary.

I was impressed by the description of Eiffel's approach to this -
sounds exactly right to me.

-Tom



----------------------------------------------------------
Tom Bushell           * Custom Software Development
Telekinetics            * Process Improvement Consulting
2653 Highway 202          * Technical Writing
RR#1, Elmsdale, NS
B0N 1M0
(902)632-2772         Email: tbushell@fox.nstn.ns.ca
----------------------------------------------------------

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E42nv9.LL7@syd.csa.com.au> donh@syd.csa.com.au (Don Harrison) writes:

> Jeff Carter writes:
> 
> :> So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> :> 
> :Nonsense. This is a violation of an explicit precondition (that the
> :actual value associated with S be in the range of Sub_Integer).
> 
> It's both and it shows that Ada is not typesafe.

Sorry, Don.  You are in the weeds.  It shows absolutely nothing of the
kind.  Ada may or may not be "type safe" but your absurd example has
nothing to say on the matter.

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[Eirik Mangseth]

Tom Bushell wrote:
> 
> On Wed, 15 Jan 1997 14:13:05 +0100, Jonas Nygren
> <ehsjony@ehs.ericsson.se> wrote:
> 
> >
> >I remember I had a GUI app on my MacPlus where the cycle 'stop testing -
> >fix something small - compile - link - ready to test again' was under 30
> >secs,
> >with a M68000 ~7 MHz!!
> 
> 30 seconds seems like a lifetime after you get used to RAD languages
> like Smalltalk, VB, or Prograph.  Turnaround is instant, and you can
> usually fix the program _while it is running_ - no need to even
> restart.  This allows the programmer to much more easily stay in an
> immersive state of "flow", and probably accounts for a large portion
> of the productivity gains possible with these language/environments.
> 
> As I believe someone else already pointed out, the C++ compiler
> convention of creating an optimized, native code, standalone
> executable file on disk is ass backwards - this should be a batch
> operation that is performed once to create the production version of
> the program.  The rest of the time, it is much more important to allow
> rapid turnaround for modifications, at the expense of execution speed
> if necessary.
> 
> I was impressed by the description of Eiffel's approach to this -
> sounds exactly right to me.

Check out Bertrand Meyer's article regarding the work ISE is doing on
concurrency in Eiffel. It's a gem and Mr. Meyer is just impressive.

(Just hope he signs my copy of the OOSC 2nd ed. book)

> 
> -Tom
> 
> ----------------------------------------------------------
> Tom Bushell           * Custom Software Development
> Telekinetics            * Process Improvement Consulting
> 2653 Highway 202          * Technical Writing
> RR#1, Elmsdale, NS
> B0N 1M0
> (902)632-2772         Email: tbushell@fox.nstn.ns.ca
> ----------------------------------------------------------

Eirik M.

/Eirik Mangseth			United Consultants A/S, Oslo Office, Norway
ema@uc-unitedconsultants.com	"Quality Software Through Quality People"
(TM)
emangset@online.no								/

Re: OO, C++, and something much better!

[Norman H. Cohen]

Don Harrison, referring to the fact that Ada subtype constraints are
checked at run time, wrote:

> ... it shows that Ada is not typesafe.

Wrong.  It shows that Ada is not subtype-safe.  Anyone who expects
otherwise does not understand how the term "subtype" is used in Ada.

Long before Luca Cardelli used the term "subtype" to mean a type bearing
a certain relationship to some other type, Ada used the term to mean a
subset of the values of a given type, consisting of those values of the
type obeying a particular constraint.  In Ada, a subtype is not a kind
of type, and distinctions between subtypes are qualitatively different
from distinctions between types.  It can be determined at compile time
that the value of an expression belongs to a particular type, but it
cannot in general be determined until run time whether the value of an
expression obeys the constraint of a particular subtype.  (Indeed, the
answer may be different for different evaluations of the expression.) 
One cannot, in general, deduce from the fact that A and B belong to a
particular subtype that A+B will as well.

Ada subtypes are specifically meant to express assertions beyond those
implicit in the type of an expression.  These are assertions about
values, assertions that cannot, in general, be checked until those
values are generated.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: What is wrong with OO ?

[Kent Budge, sandia,]

Michael Malak wrote:
...
> The reason C++ is not interpreted is because there don't even exist
> correct C++ _compilers_ that conform to the ANSI Draft Working Paper.
> And the reason for that, of course, is because C++ is a complicated,
> quickly evolving (mutating?) language.
> 
...
But there is at least one C++ interpreter out there -- CenterLine C++.
Of course, it's not fully consistent with the latest ANSI working paper, 
for the reasons you mention.

-- 

-Kent

-------------------------------------------------------------------------------
					   
     _/_/_/  _/    _/  _/          SANDIA NATIONAL LABORATORIES    
_/_/_/    
   _/       _/_/  _/  _/          Department 9231                   
_/_/    
  _/_/_/   _/ _/ _/  _/          Albuquerque, NM 87185-0819    
_/_/_/_/_/_/
       /  _/  _/_/  _/          tel: 505 284 3825              _/  _/_/ 
_/
_/_/_/   _/    _/  _/_/_/_/    fax: 505 844 0918              _/  _/_/ 
_/
                                                                _/_/_/ 
  Computational Physics Research             
 and Development Department               Kent G. Budge -
kgbudge@sandia.gov
-------------------------------------------------------------------------------

(usual disclaimer)
Return address hacked to foil junk mail; edit before replying.

Re: OO, C++, and something much better!

[Keith Thompson]

In <32DCFB78.605A@lmtas.lmco.com> Ken Garlington <GarlingtonKE@lmtas.lmco.com> writes:
[...]
> However, via access values, an unchecked conversion could still be used
> without creating a copy, so the comment is still valid: using address
> specs to create an overlay should not be significantly less/more safe
> than unchecked_conversion, at least not for the reason originally
> given...

Personally, I'd still be more comfortable using Unchecked_Conversion
rather than overlays.  Part of this is a remnant of Ada-83-think; Ada
83 specifically stated that overlays are erroneous.  Also, it's not
necessarily guaranteed that updating one of the overlaid objects will
update the other; one of the objects may be cached in a register when
the other is updated.

I believe that applying pragma Volatile to one or both objects will
solve this problem (though there may still be some problems I'm missing).

-- 
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick

Re: OO, C++, and something much better!

[Patrick Doyle]

In article <E3z0zy.9qL@syd.csa.com.au>,
Don Harrison <donh@syd.csa.com.au> wrote:
>
>The following is a valid Ada83 program (and presumably valid Ada95):
>
>procedure Test_Type_Hole is
>  subtype Sub_Integer is Integer range 1 .. 10;
>  I: Integer;
>  S: Sub_Integer;
>
>  procedure Use_Subtype (S: Sub_Integer) is
>  begin
>    null;
>  end;
>
>begin
>  I := 1000;
>  Use_Subtype (I);       -- System Invalid call - raises 
>                         -- Constraint_Error at runtime.
>end Test_Type_Hole;
>
>So, contrary to your claim, Ada *does* permit a form of broken polymorphism.

  To me, this seems more of a broken assertion than broken polymorphism.

  (However, I've never use Ada in my life... :-)

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Robert C. Martin]

In article <E448IK.4qI@ecf.toronto.edu>, doylep@ecf.toronto.edu (Patrick
Doyle) wrote:

>   I was not aware that private virtual functions existed.  Can a descendant
> class override this function even though it does not have access to it?
> 

Yes.  Visibility is not the same as accessibility.  You can override anything
that is visible, even if it is unaccessable.

If a class D overrides a private function F of its base B, the functions of 
D still cannot access B::f, but they *can* access D::f.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "lgmayka" == Lawrence G Mayka <lgmayka@sprynet.com> writes:

lgmayka> bs@research.att.com (Valerie Torres) wrote:

bs> In the area of exceptions, C++ may have added something important:
bs> C++ exceptions can be of arbitrary type and inheritance is taken
bs> into account when catching an exception. This provides important
bs> possibilities for grouping exceptions that I don't know precedence
bs> for (though the need for grouping has been known for decades).

lgmayka> The use of inheritance in defining and handling conditions
lgmayka> dates at least back to Symbolics' New Error System, circa 1984,
lgmayka> which was the forerunner of the Pittman Condition System, circa
lgmayka> 1985.  The latter quickly found its way into the other
lgmayka> commercial Common Lisp implementations and was incorporated
lgmayka> into ANSI Common Lisp.

Unfortunately exceptions-as-object is a bad idea, and claiming priority
for bad ideas is hardly a sport worth engaging into. :-)

Re: What is wrong with OO ?

[Matthew Heaney]

In article <E424x4.5A3@research.att.com>, bs@research.att.com (Bjarne
Stroustrup) wrote:


> > Why let me use
> > uninitialized pointers? Do you have any idea how many programs I have
> > debugged for hours because someone failed to write something as basic as:
> > 
> > char *p = NULL;
>
>If I had designed C++ today, every variable that did not have a default
>constructor would have to be initialized.

Perhaps it has already been stated elsewhere in this thread, but in Ada,
access objects are by default initialized to null.  An attempt to
dereference a null access value raises Constraint_Error.

I see C++, Ada, and Eiffel being on a scale of safety with respect to
pointers (and other things, too).

Eiffel takes the attitude that pointers are unsafe (they can be), so
removes them from the language.  This is the approach taken by Java, too.

C++ is pragmatic, and given its C and systems-programming roots, has
pointers, and you can basically do anything you want.  In fact, a pointers
are often used to do a typeless kind of programming; this is the norm, for
example, in making UNIX system calls.  But there is little safety in that
approach, and your example proves the point that perhaps some built-in
support for pointer-safe programming is called for.

Ada is in the middle: it's pragmatic *and* safe.  You are free to use
pointers, but pointer type "casting" is not allowed.  Pointers to
statically declared objects are safe too, because you are only allowed to
point to an object that has a longer life than you.  "Reference" variables
are made safe by parameterizing the object with a reference to a
longer-lived object.

Of course, if you really do want to leave the type system in Ada, you can
do so by explicitly marking the conversion or dereference as "unchecked." 
So you can have your cake and eat it too.

I have said it before: I like Eiffel, and don't disagree with its
philosophy, but I think there's room for pragmatism.  I think Bjarne would
agree that it's important to give programmers all the tools they need to do
their job, and that includes pointers.  Ada's philosophy is give them
pointers, but make pointer manipulation safe.

If you are frustrated by repairing code that is broken because of
non-initialized pointers, then perhaps you should give Ada a try. 
Programming is a lot more productive then debugging, and a lot less
frustrating.

-matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Exceptions as objects (was Re: What is wrong with OO ?)

[Patrick Doyle]

In article <yf3sp3y9ur6.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>
>Unfortunately exceptions-as-object is a bad idea, and claiming priority
>for bad ideas is hardly a sport worth engaging into. :-)

  Could you elaborate on why that is a bad idea?

 -PD
-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: What is wrong with OO ?

[Jay Martin]

bs@research.att.com (Bjarne Stroustrup) writes:


>dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> > Bjarne, in the middle of a very nice extended discussion of C++, says
> > 
> > "Had C++ not been relatively easy to learn and use reasonably well, it
> > would have disappeared long ago. By relative I mean the amount of effort
> > needed compared to the amount of benefit gained."
> > 
> > Hmmm! I don't think I buy that. People will learn what is at hand pretty
> > much regardless of whether something is easy to learn and use.
> > ...
> > Going back to the main subject, which is the allegation that popularity
> > indicates ease of learning and use,

>I don't think I claimed that, and I don't think that I have to. C++ use grew
>very nicely for years without hype. I base my statement on years of looking
>at C++ use, teching, and learning - many of those years were before anyone
>was given time off from their day job to learn C++.

>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

I find this incredibly naive.  C++ is popular because it is perceived
as "C version 2" or "C 8X-9X".  You pretty much automatically get
usage by a large number of C programmers.  That it came from Bell Labs
pretty much guaranteed its success over Objective C which came from
some pint size "is it out of business yet" company.  Since C
programmers are notorously ignorant of computer language design, the
audience is not too discerning.  Suppose instead that you had chosen
to do an almost identical language except with a clean well designed
syntax that was not syntactically upward compatible from C.  I believe
this "alternate reality C++" would have failed miserably.  I thought
it was brilliant the way you appealed to the anti-SE neanderthal
dark-side of C programmers with the "No nanny-ism, any safety checks
would be "dangerous" and demeaning".  You see there is a huge segment
of programmers who love the arcane, the complex and the hard to
understand.  This is because they are smart and they know that hard to
learn tools that require alot of special expertise will give them a
competive advantage in the programming marketplace because it limits
the number of programmers that can do the work thus guaranting high
salaries and job security!  Thus "high learning curve" tools leads to
daydreams of speeding down the freeway in your high powered BMW
convertable with an adoring and beautiful big titted blond bimbo at
your side.

Is their any wonder why the software field is not "rational"?

Still I find C++ a remarkable job given that you had to stay upward
compatible (syntax/sematically and philosophy-wise) with a turd.

> >  I think the point is that such
> > popularity indicates accesibility more than anything else. By accessibility
> > I mean that something is available, viewed as hot, and can be learned well
> > enough to do *something*. Consider the situation today, students want to
> > learn Java, not C++, they see C++ as yesterday's language, and Java as
> > the language of tomorrow. Just from the incredible rate at which Java books
> > are cascading into bookstores, I have to guess that the rate of learning of
> > Java far exceeds the rate of learning of C++. But I would NOT conclude from
> > this that Java is easier to learn or use than C++. Maybe it is, but you
> > cannot conclude anything just from popularity.

>It is amazing what hype and serious marketing dollars can do, but what
>little objective data I can lay my hands on indicates that C++ use is
>still increasing very nicely. However, I have my doubts whether all of
>those books will actually help the Java community. 

This field is driven by marketing and rational behavior is at a
minimum.  Sometimes I wish a rational force like some academic
scholars would actually study the field in an objective fashion.
Alas, CS Academia is total failure (I will restrain myself from the
usual explicative strewn rant).  Anyway, any argument based
on the rationality of field "like it must be good because people
use it" is nonsense.  There are just too many non-SE factors
in these decisions.
  

I think though Java may turn out to be a better software engineering
language than C++ and Ada95 as it contains two extra design
philosophies which I deem necessary for good language design:

                                 C++      Ada95     Java
1. Simplicity                    No        No        Yes
2. Programmers are morons.       No        Yes       Yes


> > Ada folks have never played the game of claiming popularity as an indicator
> > of any kind of quality, because they have not been able to. I realize that
> > C++ is in a position to make such claims, but I recommend against it, because
> > I think you will find that your arguments will backfire as Java becomes
> > the next hot language, at least for a while :-)

>Thanks for the advice. The furthest I go is to claim that unless C++
>had at least some of the virtues I claim for it, it would have died during
>the early years where there were essentially no C++ marketing and alternatives
>languages with marketing dollars behind them existed.

>Naturally, even that is invariably mistaken for the disreputable "5 million
>morons cannot be wrong" argument :-(

Of course programmers are morons, just look at them!

Jay

Re: What is wrong with OO ?

[Richard A. O'Keefe]

bs@research.att.com (Bjarne Stroustrup) writes:
>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

Speaking as someone who bought the first C++ book to come out,
the C++ that became popular in the first place
is not the C++ that people discuss now.
To start with, it didn't have multiple inheritance, templates,
exceptions, or RTTI.

It follows that claims about the difficulty of understanding
about C++ *AS IT IS NOW* cannot fairly be founded on its
acceptance *AT FIRST*, just as arguments about the difficulty
or otherwise of learning or teaching Ada 95 cannot be directly
founded on the acceptance or otherwise of Ada 83 (ditto with
Fortran 90 and Fortran 66).

>I have often found myself wondering if the C++ wouldn't have been much better
>for all concered had there (just) been two dozen good C++ books instead of
>the 400+ books that mostly fail to teach the basic principles and mostly
>lead students and programmers astray.

Here of course it is very important to separate out the books from the
language.  The marked prevalance of trash books about C++ says nothing
about C++ except that it is popular.

>Thanks for the advice. The furthest I go is to claim that unless C++
>had at least some of the virtues I claim for it, it would have died during
>the early years where there were essentially no C++ marketing and alternatives
>languages with marketing dollars behind them existed.

Hmm.  When I learned about C++ in the mid-80s, the only available
alternatives _that I was aware of_ were some sort of Lisp (Common
Lisp not then being available) with some sort of home brew Flavors
lookalike (CLOS not then being available) or Smalltalk.  Simula 67
_may_ have been available for VAX & Sun but if there were marketing
dollars behind it they never managed to put a mention of it where I
could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
a decade ago?

-- 
My tertiary education cost a quarter of a million in lost income
(assuming close-to-minimum wage); why make students pay even more?
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: OO, C++, and something much better!

[Jon S Anthony]

In article <E47rDG.AC8@ecf.toronto.edu> doylep@ecf.toronto.edu (Patrick Doyle) writes:

> In article <E3z0zy.9qL@syd.csa.com.au>,
> Don Harrison <donh@syd.csa.com.au> wrote:
> >
> >The following is a valid Ada83 program (and presumably valid Ada95):
> >
> >procedure Test_Type_Hole is
> >  subtype Sub_Integer is Integer range 1 .. 10;
> >  I: Integer;
> >  S: Sub_Integer;
> >
> >  procedure Use_Subtype (S: Sub_Integer) is
> >  begin
> >    null;
> >  end;
> >
> >begin
> >  I := 1000;
> >  Use_Subtype (I);       -- System Invalid call - raises 
> >                         -- Constraint_Error at runtime.
> >end Test_Type_Hole;
> >
> >So, contrary to your claim, Ada *does* permit a form of broken polymorphism.
> 
>   To me, this seems more of a broken assertion than broken polymorphism.
> 
>   (However, I've never use Ada in my life... :-)

Well, now this is amusing.  Patrick here states he's never used Ada
in his life, but he gets it _right_!  Nice little piece of anecdotal
evidence for the readability of Ada... :-)

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com

Re: What is wrong with OO ?

[David Emery]

With many OO languages, including C++ and SmallTalk, I've observed that
it seems to be easy to get familiar with the language, but it's much 
harder to become fluent/expert in it.  I suspect we'll see a similar
pattern with Java.  This is certainly my personal experience learning
Java.  

Thus I'd suspect that the initial popularity of C++ was due to the 
following: (no ranking)

	*  popularity of C
	*  price
	*  ease/intuition for the basic OO concepts.  

So, once Joe/Jane Programmer has reached the "familiarity" stage, the
real issue is the amount of time it takes to get to the "fluent"
stage.  

Thus I think that a more appropriate way at looking at this is not
popularity or familiarity, but rather time to reach expertise.  I'll
leave it to others to define "expertise" for a given language.  At the
minimum, I'd expect "expertise" to include the ability to avoid common
syntax/semantic mistakes, the ability to read/reason about and
maintain code written by others, and at least passing familiarity with
the distinction between "the language specifies..." and "this
implementation does...".

If you are going to be a practicing/professional programmer, producing
real code, "familiarity" is not good enough.  Expertise is required. 

				dave
-- 
<.sig is away on vacation>

Re: OO, C++, and something much better!

[Andrew Koenig]

In article <5bie2d$eat$1@news.nyu.edu> kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

> In article <dewar.852928982@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> >equally if you do something like

> >   (x = p; x < &p[10]; p += 3)

> >you can find you have an infinite loop, all quite in accordance with the
> >C semantics, although somewhat surprising.

> This case must work.  Such a reference to the end of an object is required
> to be treated like a reference within the object.

I haven't seen the original of this, but the fragment above appears
to contain at least three mistakes (not counting the missing `for'
as a mistake):

	1. It probably should have said `x += 3' instead of `p += 3';
	   as it is, the loop will just keep incrementing p until something
	   dire happens.

	2. If we change `x += 3' to `p += 3,' it still won't work,
	   because p will take on the value of &x[9], and then
	   &x[12], which is undefined, assuming that p has 10 elements.

	3. If p is indeed the name of a 10-element array, then
	   &p[10] is undefined in C.  Really!  The reason is that
	   it is defined as equivalent to *(p+10), and, although it
	   is legal to create p+10, the effect of dereferencing it
	   is undefined.  So, formally speaking, &p[10] is supposed
	   to be written as p+10.

I hope I haven't derailed the discussion too much.
-- 
				--Andrew Koenig
				  ark@research.att.com
				  http://www.research.att.com/info/ark

Re: What is wrong with OO ?

[rharlos*cybercomm.net]

bs@research.att.com (Bjarne Stroustrup) wrote:

   << snipped the debate parts >>

| Why is any of this relevant now? Why do I bother with this debate on
| "innovation?" Because some of what is said related directly to what C++
| is and should be, and that again affects where it is reasonable to use
| it and how it is best used. If you misunderstand some of the fundamentals
| of a language, the code you write in it is going to be suboptimal in several
| ways.

PMFJI.  If there is a gem to be gleaned from this debate, it is in the above
paragraph.

Every development environment (DE) has strengths and weaknesses.  These are the
"fundamentals" of the DE.  As developers, we have a responsibility to understand
both the needs of the situation to be "solved" and the fundamentals of the
various tools which may be used to create a solution to the situation at hand.

Our ability to select the right tool for the job can make the solution several
times easier to implement, maintain and enhance than if we had selected a less
optimal DE.  Its a message that, in my experience, can never be overemphasized!

Thanks for this little gem -- it's a keeper!

  O-------------------------0   0----------------------------------0
  |  Richard C Harlos II     \ /       Software Analyst/Developer  |
  |  aka:   .:.Richard.:.     X    Logical Design Solutions, Inc.  |
  |  rharlos@cybercomm.net   / \               http://www.lds.com  |
  0-------------------------0   0----------------------------------0

  ** opinions expressed are mine, not necessarily those of LDS, Inc.

  Anit-Spam Tactic:  replace the '*' with '@' when replying to
            me via e-mail as I've been inundated with spam !!!

Re: What is wrong with OO ?

[John W. Sarkela]

Richard A. O'Keefe wrote:
> 
... text ommitted ...
> Hmm.  When I learned about C++ in the mid-80s, the only available
> alternatives _that I was aware of_ were some sort of Lisp (Common
> Lisp not then being available) with some sort of home brew Flavors
> lookalike (CLOS not then being available) or Smalltalk.  Simula 67
> _may_ have been available for VAX & Sun but if there were marketing
> dollars behind it they never managed to put a mention of it where I
> could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
> a decade ago?
> 
There were some very sound alternatives. In the days when C++ was
still in the 1.x range (ie pre multiple inheritance, pre templates,
pre exceptions, etc) the languages Trellis/OWL, Eiffel and Modula-3
were around. 

In fact, there was a protracted thread in the comp.lang.eiffel and
comp.lang.c++ groups about Eiffel v. C++. Most of the content 
revolving upon the need for multiple inheritance and genericity
(templates) in a statically typed OOP language and the need for 
exceptions for robustness. All three languages paid great homage
to the needs of software engineering. All three are worth reading
about, if only for historical perspective.

John Sarkela
jsarkela@enfish.com
-- Standard disclaimers apply.

Re: What is wrong with OO ?

[Ulrich Windl]

I guess it's just a matter of fact that short routines are most
oftenly called (If you don't manipulate your instance variables
directly).

Ulrich Windl

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "ok" == Richard A O'Keefe <ok@goanna.cs.rmit.EDU.AU> writes:

[ ... on ease of learning ``C++'' and its popularity ... ]

ok> Speaking as someone who bought the first C++ book to come out, the
ok> C++ that became popular in the first place is not the C++ that
ok> people discuss now.  To start with, it didn't have multiple
ok> inheritance, templates, exceptions, or RTTI.

Very good point! Which adds to the motivation for my oft repeated stance
that ``C++'' is a brand name, and can in effect mean any of a few quite
different (even if related by very good backwards compatibility) languages.

ok> Hmm.  When I learned about C++ in the mid-80s, the only available
ok> alternatives _that I was aware of_ were some sort of Lisp (Common
ok> Lisp not then being available) with some sort of home brew Flavors
ok> lookalike (CLOS not then being available) or Smalltalk.  Simula 67
ok> _may_ have been available for VAX & Sun but if there were marketing
ok> dollars behind it they never managed to put a mention of it where I
ok> could see it.  What _were_ the VAX, Sun, Apollo alternatives to C++
ok> a decade ago?

This is an excellent point, but one that has some (partial) answers.

Most importantly there was ``Objective-C'' which was implemented rather
portably by generating ``C'', like 'cfront' was doing for ``C++''; I
have my early copy of Brad Cox's "OOP: and evolutionary approach"
describing it dated 1986, and indeed I bout it over ten years ago.  It
was used to develop RMG, an impressive ``Smalltalk''-like graphical
environment, which would still be impressive today, never mind 10 years
ago, which was being distributed, in very good shape as well, to
universities and research institutes in 1987. It is easy to argue that
Objective-C never achieved lasting fame for a number of unfortunate
reasons; among them that Brad Cox ``cleverly'' kept its compiler
proprietary instead of more or less givin it away ("cfront" was licensed
fairly cheaply, so that even a one man company like Comeau could port it
and sell it on a variety of platforms).

But there were other alternatives, which however have remained
resolutely locked up in the research world (and some like ``Smalltalk''
have only escaped it as their sell-by-date has already expired).

Some of them originated from BTL themselves; there was a number of C
derived languages being developed at BTL concurrently with ``C++'', some
of them being good contestants. But it was ``C++'', for various not
necessarily technical reasons, that became popular within AT&T and the
world (again, easy compiler licensing was IMNHO crucial: a bit like the
sudden popularity of Pascal in Universities was due to the easy
availability of the bytecode compiler, and of the CDC sample
implementation).

Now, I personally like ``C++'' (up until 2.x, that is, more recent
features I like less), for I am a language lawyer and a system
implementor with it; but I find it abhorrent that it has become popular
as the application development language of choice by anybody, as it is
simply too sophisticated and low-level (just like C itself). If only had
Objective-C become the application development language of choice! If
only more people had seen RMG! and so on.

Re: What is wrong with OO ?

[Bertrand Meyer]

Chris Bitmead wrote:
 
[Quoting me, quotation abridged:]

> >ISE Eiffel does give the user a degree of parameterization:
> >a compilation option specifies the size threshold beyond which
> >a routine will not be inlined. 

[...]

> >Most users are happy with the
> >default, which inlines small, frequently called routines.

[Chris Bitmead:]

> How on earth does the compiler know if a routine is "frequently
> called"?

Sorry, sloppy wording on my part. I meant "called from many different
places in the code", which  does tend to correlate with the numbers of
times the routine will be called, although of course this is not always
true (as with a routine that is called from just one place, but that
place is in a loop). Just one criterion among others. Thanks for noting
the incongruity in my original message. 

-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Bertrand Meyer]

Bjarne Stroustrup wrote:

> C++ use grew
> very nicely for years without hype. I base my statement on years of looking
> at C++ use, teching, and learning - many of those years were before anyone
> was given time off from their day job to learn C++.

[...]

> [C++] would have died during
> the early years where there were essentially no C++ marketing and alternatives
> languages with marketing dollars behind them existed.

This is really too far off the reality to let pass. Not that I think
Bjarne Stroustrup is less than forthcoming; he is undoubtedly sincere in
believing that he was a researcher led by purely intellectual motives
competing against crass commercialists. From within Bell Labs he may
have had that impression. But anyone seeing the real situation in the
software world at large could not fail to notice the gigantic amount of
both "hype" (his term in the first paragraph) and "marketing" (his term
in the second) behind C++. The mere fact that it came from AT&T and was
from the start endorsed by other billion-dollar companies was what got
the industry to listen. It does not mean that the language was bad (and
neither does it mean the reverse) - simply that the quality of the
language was, if not completely irrelevant, far secondary to the
marketing push.

In the field of advanced technology, furthermore, marketing is not just
expensive ads in magazines. It is also access of various approaches to
scientific conferences and publications. The record of OOPSLA in this
respect has been (and continues to be) less than pristine. To put it
politely, it has always been made very clear that some approaches were
more equal than others.

This has had a rather vicious consequence: that people promoting
less-hyped and less-politically-correct approaches, coming in many cases
from private industry (often precisely because they were more innovative
and could not find a hospitable environment in academia or even large
corporate research labs) had to resort to the normal, commercial forms
of "marketing", thus allowing their better endowed competitors to drape
themselves in the mantle of Pure Science and accuse the former of crass
commercialism. This is a very effective tactic, and worked quite well in
the history of O-O: keeping innovators  away from the Establishment,
forcing them to go to the commercial sector, and then frowning on them
on the grounds of academic impurity. Quite smart.

All this being said, I must add that while I am not a great fan of C++ I
agree with Bjarne Stroustrup that marketing and hype alone, on any
scale, would not by themselves have been able to bring C++ to the level
of success that it reached. Clearly, it filled for many people a
pressing need at the right time. Although Dr. Stroustrup's second
paragraph as quoted above (the point about there being no marketing for
C++) does not hold water, the first part (omitted above):

	[U]nless C++ had at least some of the virtues I claim for it,
	it would have died during the early years

is absolutely correct. To take  the first analogy that comes to mind,
the Apple Newton is yet one more example that no company, however big,
can force on the public a technology that the public does not want.


-- 
Bertrand Meyer, President, ISE Inc., Santa Barbara (California)
805-685-1006, fax 805-685-6869, <bertrand@eiffel.com> -
ftp://ftp.eiffel.com
Visit our Web page: http://www.eiffel.com
	(including instructions to download Eiffel 4 for Windows)

Re: What is wrong with OO ?

[Chris Bitmead]

In article <32D53473.4DAA423A@eiffel.com> Bertrand Meyer <bertrand@eiffel.com> writes:

>ISE Eiffel does give the user a degree of parameterization:
>a compilation option specifies the size threshold beyond which
>a routine will not be inlined. This is measured in internal units
>(number of bytecode words), but easy to relate to number of
>instructions. This option provides a way to control space-time
>tradeoffs. In practice, however, most users are happy with the
>default, which inlines small, frequently called routines.

How on earth does the compiler know if a routine is "frequently
called"?

language marketing question, was Re: What is wrong with OO ?

[Tom Moran]

> But anyone seeing the real situation in the
> software world at large could not fail to notice the gigantic amount of
> both "hype" (his term in the first paragraph) and "marketing" (his term
> in the second) behind C++. 
  Does anyone know of a marketing case study of the initial growth of C
and Unix?  Both the words and the money behind them?

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "doylep" == Patrick Doyle <doylep@ecf.toronto.edu> writes:

doylep> In article <yf3sp3y9ur6.fsf@sabi.demon.co.uk>,
doylep> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> Unfortunately exceptions-as-object is a bad idea, and claiming
piercarl> priority for bad ideas is hardly a sport worth engaging
piercarl> into. :-)

doylep>   Could you elaborate on why that is a bad idea?

Of course, and easily; somebody asked me the same idea by private
e-mail, so I can just paste in the reply(s) and do a little bit of
editing. It's also one of my pet peeves... And it is astonishing that
what I am going to say, that has been part of the state of the art for
some dozen years, is not yet apparently widely known.

Let's start with the nature of exceptions. The first point is that if a
procedure implements a total function then it will never have an
exception.

Therefore exceptions arise only and only if a procedure implements a
partial function, and arise only and only when the inputs to a procedure
are outside its domain.

This means that an exception can only arise when at some point in a
procedure where there is a 'if' (or similar) statement whose
precondition is stronger than the postcondition of the statement that
precedes it. For example:

  float sqrt(float f) { if (f >= 0) return exp(0.5*ln(f)); }

Here the precondition of the 'if' is $f >= 0$, but the postcondition
preceding it is (more or less) $true$.

Now exception handling means extending the precondition of a procedure,
up to making it become a total function. This means simply weakening the
precondition of 'if's by adding 'else'/'elif' clauses.

Consider:

  extern float sqrt_neg_arg(float);

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : sqrt_neg_arg(f); }

Now 'sqrt' is a total function. This is the general way of``defining''
and ``raising'' exceptions: provide an 'else' that invokes a procedure;
the name of the procedure is the name of the ``exception''.

Unfortunately in the general case this simply cannot be done as written,
because the author of a piece of software may not be in a position to
know what to code in those 'else's, for the more appropriate action may
depend on the runtime context. It is thus inappropriate to assign a
statically defined association between a name like "sqrt_neg_arg"
and a procedure implementation.

The obvious and correct solution is to make the name of the procedure
dynamically scoped; then it can be redefined whenever this is needed.

Thus:

* an exception is a fact, not an object;

* the fact is the absence of a suitable 'else' somewhere when it should
  be there;

* defining and raising an exception means simply adding an 'else' and a
  call to a dynamically bound procedure;

* handling an exception means simply resolving the dyanmically scoped
  name to a procedure body and executing it.

Finally, recovery from an exception may involve non local control
transfers out of the procedure that handles the exception; but this is
an entirely separate issue. It need not be the case.

So, basically *everything* is wrong (and clumsily so) with the ``C++''
exception-as-object system:

* the name of the exception class should be that of a dynamically scoped
  procedure.

* an exception object is really just a clumsy and silly way of
  specifying an argument list to that dynamically scoped procedure.

* non local control transfers are then mandatory.

Consider the stark contrast between (in some language reminiscent of
``C++''):

  fluid float sqrt_neg_arg(float);

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : sqrt_neg_arg(f); }

  main()
  {
    {
      fluid float sqrt_neg_arg(float f) { return 0.0; }

      printf("%f\n",sqrt(-2.0));
    }

    {
      fluid float sqrt_neg_arg(float f)
      {
	fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",f);
	abort();
      );
      
      printf("%f\n",sqrt(-2.0));
    }
  }

and

  class sqrt_neg_arg {
  public: float n;
    sqrt_neg_arg(float f) : n(f) {}
  };

  float sqrt(float f)
  {
    if (f >= 0)
	  return exp(0.5*ln(f));
    else  throw sqrt_neg_arg(f);
  }

  main()
  {
    try { printf("%f\n",sqrt(-2.0)); }
    catch(sqrt_neg_arg &sna)
    {
      // cannot just return 0.0 -- too bad.
      puts("0.0"); // not really what we wanted
    }

    try { printf("%f\n",sqrt(-2.0)); }
    catch(sqrt_neg_arg &sna)
    {
      fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",sna.f);
      abort();
    }

  }

As you can see the second solution is really just a clumsy, misleading,
limited version of the first. Exceptions are not objects; and exception
objects are just stupid ways of passing a parameter list to a
dynamically scoped procedure name, which is confused with a class.

However, in most cases even for exception handling one does not really
need dynamically scoped function names; dynamically scoped function
pointer variables are about as good, as in (rewriting my example):

  float sqrt_neg_arg_default(float f)
    { fprintf(stderr,"sqrt neg arg: %f\n",f); abort(); }

  fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_default;

  float sqrt(float f)
    { return (f >= 0) ? exp(0.5*ln(f)) : (*sqrt_neg_arg)(f); }

  float sqrt_neg_arg_zero(float f)	{ return 0; }
  float sqrt_neg_arg_abs(float f)	{ return sqrt(-f); }

  main()
  {
    {
      fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_abs;
      printf("%f\n",sqrt(-4.0));  // prints 2.0
    }

    {
      fluid float (*sqrt_neg_arg)(float) = sqrt_neg_arg_zero;
      printf("%f\n",sqrt(-42.0)); // prints 0.0
    }

    printf("%f\n",sqrt(-33.0)); // default, aborts
  }

Dynamically scoped function pointers have the advantage that they don't
require introducing into the language nested functions, and allow one
more easily to separate ``exception handler'' interface and
implementation.

Note that in effect in ``C++'' the 'fluid' storage class that turns a
variable into a dynamically scoped one is pretty easy to simulate (in
the shallow binding way) using constructors/destructors:

------------------------------------------------------------------------
typedef void		*Fluid;

class FluidFrame
{
private:
  Fluid		   	  saved;
  Fluid			  *variable;
public:
  construct		  FluidFrame(Fluid *);
  destruct		  ~FluidFrame();
};

static inline		FluidFrame::FluidFrame
( register Fluid	  *const avariable)
{
  this->saved	  = *avariable;	/* Save old value	    */
  this->variable  = avariable;	/* Note where to restore it */
}

static inline		FluidFrame::~FluidFrame()
{ *this->variable = saved; }

#define fluid(NAME)							\
  FluidFrame Fluid_##NAME(& (Fluid) (NAME)); NAME

#define fluidfor(CLASS,MEMBER,NAME)					\
  FluidFrame Fluid_##CLASS##_##NAME					\
    (& (Fluid) (CLASS MEMBER NAME));					\
  CLASS MEMBER NAME
------------------------------------------------------------------------

The the example above becomes:

  float sqrt_neg_arg_default(float f)
    { fprintf(stderr,"sqrt neg arg: %f\n",f); abort(); }

  float (*sqrt_neg_arg)(float) = sqrt_neg_arg_default;

  float sqrt(float f) // implements a total function
    { return (f >= 0) ? exp(0.5*ln(f)) : (*sqrt_neg_arg)(f); }

  float sqrt_neg_arg_zero(float f)	{ return 0; }
  float sqrt_neg_arg_abs(float f)	{ return sqrt(-f); }

  #include <Fluid.H>

  main()
  {
    {
      fluid (sqrt_neg_arg) = sqrt_neg_arg_abs;
      printf("%f\n",sqrt(-4.0));  // prints 2.0
    }

    {
      fluid (sqrt_neg_arg) = sqrt_neg_arg_zero;
      printf("%f\n",sqrt(-42.0)); // prints 0.0
    }

    printf("%f\n",sqrt(-33.0)); // default, aborts
  }

which seems rather legible, vastly more flexible/reasonable than the
convoluted and limiting current ``C++'' syntax.

Now there is completely orthogonal problem of non local control
transfers, which might well be useful in a procedure implementation that
``handles'' an exception. In the above code snippets an example of the
use of non local control transfers is the call to 'abort()', which exits
the current process and transfers control back to the invoking process;
one could use 'setjmp()' or 'longjmp()', or something better, for finer
grained control transfers.

It is a pity that the ``C++'' exception handling features tie so
intimately together the distinct concepts of dynamically scoped
identifiers (and then they are provided in a rather clumsy form) and of
non local control transfers (and then they are also provided in a rather
clumsy form).

The issue of non local control transfers, even if only the form of
upward funargs, and scope entry/exit triggers, is interesting and
``C++'' provides only ad hoc and limited machinery to deal with it.

  As to this, I rememjber reading someone stating that as far as he knew
  only TECO (yes, TECO!) of most languages around provides general clean
  entry/exit scope functions/triggers. Ah well.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Paul Kyzivat]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

[snip a long and interesting explanation of exception handling]

I found the discussion very interesting. In a theoretical way I agree
with you. However I think in a practical sense it misses the point to
an extent:

For code to be readable, it is useful to have the exception handling
easily and clearly lexically scoped with the code that it applies to.
What you suggest is really very little different than what existed in
various libraries prior to the introduction of compiler supported
exception handling. I remember it in Fortran - it did a nice job of
adding to the confusion of all those gotos.

You are right that this really has more to do with how to suport a new
form of non-local control transfer than it does exceptions. But
usually non-local control transfer is required for exception handling
because the function otherwise has no return arguments that can be
used to express what happened. And, while TRY is ugly and clumsy in
some cases, it does allow the normal flow of control to be segregated
from the abnormal flow of control while still making it clear how they
are related.

I agree with you that classes as exceptions is in a way a kludge. But
they do more than pass arguments to a handler. They also server as a
hierarchical classification system for exceptions. Using classes for
this is a matter of economy of language concepts. (Perhaps we can call
it reuse of a language concept.)

	Paul Kyzivat

Re: What is wrong with OO ?

[Damon Feldman]

 Bertrand Meyer <bertrand@eiffel.com> wrote:
>Bjarne Stroustrup wrote:

>> C++ use grew
>> very nicely for years without hype. I base my statement on years of looking
>> at C++ use, teching, and learning - many of those years were before anyone
>> was given time off from their day job to learn C++.

>This is really too far off the reality to let pass

>people promoting
>less-hyped and less-politically-correct approaches, coming in many cases
>from private industry (often precisely because they were more innovative
>and could not find a hospitable environment in academia or even large
>corporate research labs) had to resort to the normal, commercial forms
>of "marketing", thus allowing their better endowed competitors to drape
>themselves in the mantle of Pure Science and accuse the former of crass
>commercialism. This is a very effective tactic, and worked quite well in
>the history of O-O: keeping innovators  away from the Establishment

Come come.  Private industry is more innovative than academia "or even large 
corporate" labs?  "This is an effective tactic [for] keeping innovators away 
from the Establisment?"  If the innovators did get close to the establishment, 
might they have discovered who really assasinated Kennedy :-).

Just kidding, of course.

But I think that the academic success of C++ was based on acceptance by 
tenured faculty who were not payed off or otherwise influenced by big business 
or in a conspiracy to foist C++ on the programming community.

C++ was object oriented, and it was downward compatible (almost) with C, which 
was and is in wide use.

Damon

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Ronald E Jeffries]

On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
Grandi) wrote:

>Let's start with the nature of exceptions. The first point is that if a
>procedure implements a total function then it will never have an
>exception.
>
>Therefore exceptions arise only and only if a procedure implements a
>partial function, and arise only and only when the inputs to a procedure
>are outside its domain.

Yes ... and then you go on to make the function more robust, which
would be a good thing when it's practical.  But as you point out, the
exceptions arise when the inputs are out of the range contemplated by
the function as written.  

Exceptions, however, whether represented as objects or long jumps, are
about handling the unexpected.

My application system must keep on going, whether or not the input
routines are prepared to deal with B's in the middle of the numbers,
and dates like 2/31/1997.  Complexity, lack of access to the code,
limited resources mean that the input routines won't ever be made
complete.  And they can't know what their users want done with those
B's and weird dates anyway.

At the same time, when using the input routines, it is impractical
(costly and error-prone) to have every call to the routines check for
errors.  It is much more practical and convenient to choose a standard
place where, if an input error occurs, a default action can be taken.

In a project I'm presently working on, the input routines try to
handle all the errors.  Then when the application definers decided
what kind of notifications they wanted on input errors, we had to go
in and edit the input routines and change them all around to get the
job done.  Had they just thrown an exception, we could have fielded
the exception where we wanted to, and filed our notifications and gone
on.

While complete program correctness is an interesting science, it is
not something that we often attain in practice.  Exceptions are a
simple and practical way to deal with the faults we humans often leave
in our programs and our data.

Regards,

Ron Jeffries
Smalltalker
How do I know what I think until I see what I type?

Re: OO, C++, and something much better!

[Robert Dewar]

Richard said, replying to me

>>equally if you do something like
>>
>>   (x = p; x < &p[10]; p += 3)
>>
>>you can find you have an infinite loop, all quite in accordance with the
>>C semantics, although somewhat surprising.
>
>This case must work.  Such a reference to the end of an object is required
>to be treated like a reference within the object.

(note, the p += 3 should of course be x += 3, as I noted in a followup
 post, but I assume Richard understands this typo)

Chuckle, chuckle, it is nice to be able to catch Richard out like this :-)

Richard, you did not look at the example carefully enough. The fact that
you think it works even after I warned that it does not is a perfect
example of how serious this pitfall is!

>   (x = p; x < &p[10]; x += 3)


The problem in my example is that I am bumping x by 3 each time. Sure
it would work if the 3 is replaced by 1, because of the special kludge
in the ANSI standard to allow &p[10] but the increment of 3 causes the
value of x to be further past the end of the array, and this is not
required to work.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Bryan Dollery]

Ronald E Jeffries wrote:

[...]

> Exceptions, however, whether represented as objects or long jumps, are
> about handling the unexpected.

Nice misconception. Exceptions are deviations from the rule.

There has also been some discussion in this thread about partial/total
functions, and how total functions don't need exception handlers (all
implementations of functions are partial because the state of the
underlying software/hardware can not be known, and this environment
constitutes part of the input to the function, thus making any 'total'
function partial, as some of its inputs are implied). 

I beg to differ. "Exceptions" aren't just techniques to handle errors in
input, output or computation. Exceptions are exactly that, exceptions.
The reason 'exception handlers' aren't called 'error trappers' is
because they don't just trap errors.

If one has a routine to search a list from a given position for a
paricular value one could implement this algorithm:


(pseudo-code)
search( this, for, from )
{
  if from < this.LowerBounds or from > this.UpperBounds
    return -1
  i := from
  while ( i < this.UpperBound)
    if ( this[i] = for )
      return i
  loop
  return -1
}

This has all sorts of problems. Uglyness is just one of them. However,
without exceptions and attempt to tidy it up would just make it longer,
and uglier.

With exception handling:

search( this, for, from )
  try
    i := from
    while ( this[i] != for )
    loop
    return i
  except
    return -1
end

Ok, this does enforce the precondition that FROM has to be within the
bounds of the list. But this is just a side effect, and could be made
explicit with a comment, or even a condition statement, or an assertion.
The main point is that the general rule is to itterate the list, and to
find the required item. That is what this routine does. If something
unusual happens, such as the item not being in the list, then an
exceptional situation has arrisen. Perfect.

This is of course not a perfect example, better ones could be found. It
could, and probably will, be argued that a search routine generally has
as good a chance of failing as succeeding. That is irrelevant. The point
is that exceptions to general processing should be handled by exception
handlers.

As to the question of an exception being an object. I have done some
research on this. It was proposed by my supervisor Dr Carl Bamford that
a new interface be added to the class structure, to augment the Public
and Private interfaces that are generally accepted by the C++
fraternity. This is an exception interface, to which exception handling
classes could be bolted. This was a method by which information and
control from exceptions could be gained.

-- 
Bryan Dollery.
MD ByteSmart Systems Ltd.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>The obvious and correct solution is to make the name of the procedure
>dynamically scoped; then it can be redefined whenever this is needed.

Yes, it is well known that exception handling can be modeled as
dynamically-scoped procedure names.  And you explained that quite
clearly.  What is not clear (to me) is why you think that way of doing
things is so much better.

>Thus:
>
>* an exception is a fact, not an object;
>
>* the fact is the absence of a suitable 'else' somewhere when it should
>  be there;

Why "should be"?  What's wrong with partial functions?  I mean, it seems
perfectly reasonable to define "square root" such that negative numbers
don't have square roots.  Other definitions are possible (e.g. complex
numbers), but this definition is certainly a reasonable one.

>Finally, recovery from an exception may involve non local control
>transfers out of the procedure that handles the exception; but this is
>an entirely separate issue. It need not be the case.

It is almost always the case.

>So, basically *everything* is wrong (and clumsily so) with the ``C++''
>exception-as-object system:
>
>* the name of the exception class should be that of a dynamically scoped
>  procedure.
>
>* an exception object is really just a clumsy and silly way of
>  specifying an argument list to that dynamically scoped procedure.

You use words like "clumsy" and "silly", but you don't back them up with
real arguments very well.

>* non local control transfers are then mandatory.

This seems OK to me (see below).

>Consider the stark contrast between (in some language reminiscent of
>``C++''):
[example snipped]
>and
[C++ example snipped]

>As you can see the second solution is really just a clumsy, misleading,
>limited version of the first.

Sorry, but no, I can't see that.  They look more-or-less the same to me.
Here are some pieces of your example:

>    try { printf("%f\n",sqrt(-2.0)); }
>    catch(sqrt_neg_arg &sna)
>    {
>      // cannot just return 0.0 -- too bad.
>      puts("0.0"); // not really what we wanted
>    }

Why "not really what we wanted"?  If the goal is to "print out the
square root of the number, but if its negative, print 0.0", then the
above code seems to do that pretty clearly.  In your "fluid" example, on
the other hand, you trick the sqrt function into returning a bogus value
for a negative argument -- this doesn't seem clearer to me.

Alternatively, if you really want a sqrt function that returns zero for
negative arguments, why not write a wrapper function, which calls sqrt,
and has an exception handler saying "return 0.0"?  This is what you need
to do anyway, in the general case -- suppose I want to have square root
of a negative number return a complex number?  Well, I need a wrapper
function, since this new functionality has a different result type from
your sqrt, which returns a float.

But in any case, you normally don't want to print "0.0" for the square
root of -2 -- you want to print an error message, or do something else
entirely different, as in the next case:

>    try { printf("%f\n",sqrt(-2.0)); }
>    catch(sqrt_neg_arg &sna)
>    {
>      fprintf(stderr,"panic: negative arg to 'sqrt': %f\n",sna.f);
>      abort();
>    }

I claim that this is the sort of thing you usually want to do when you
handle an exception -- do something entirely different, and not just
pretend that all is well.  And your "fluid" example doesn't seem to do
this any better.

(Of course *most* exceptions aren't handled at all -- they're simply
bugs in the program, and you want to get rid of bugs before your
customers see them.  For this case, the value of an exception is just in
pinpointing the error, for ease of debugging.)

>Note that in effect in ``C++'' the 'fluid' storage class that turns a
>variable into a dynamically scoped one is pretty easy to simulate (in
>the shallow binding way) using constructors/destructors:
[example snipped]
>which seems rather legible, vastly more flexible/reasonable than the
>convoluted and limiting current ``C++'' syntax.

Again, why do you think this is better than using C++ exception
handling?

I'm reading this on comp.lang.ada, and Ada is a multi-threaded
language.  Your simulation of dynamic scoping doesn't quite work in a
multi-threaded environment.  You need to make the function pointer into
per-task data.

Note that this simulated dynamic scoping is likely to be much less
efficient than a (good) implementation of exception handling.  Exception
handling can (and should) be implemented using a PC-table-lookup
strategy, which makes it near-zero overhead to enter an exception-
handled region.

>Now there is completely orthogonal problem of non local control
>transfers, which might well be useful in a procedure implementation that
>``handles'' an exception. In the above code snippets an example of the
>use of non local control transfers is the call to 'abort()', which exits
>the current process and transfers control back to the invoking process;
>one could use 'setjmp()' or 'longjmp()', or something better, for finer
>grained control transfers.

A goto statement is what you want, but you want to goto an outer
procedure -- this is allowed in Pascal, for example.  And you want
nested procedures, of course.  (Of course, you can't use the word "goto"
in the name of a feature, or people will think you're evil.  On the
other hand, you can have a feature with semantics similar to goto, and
people will be perfectly happy -- so long as you don't call it goto.)

>It is a pity that the ``C++'' exception handling features tie so
>intimately together the distinct concepts of dynamically scoped
>identifiers (and then they are provided in a rather clumsy form) and of
>non local control transfers (and then they are also provided in a rather
>clumsy form).

OK, I guess I can see part of what you're saying: dynamic scoping and
non-local gotos ought to be two separate language features, each usable
in its own right, rather than combining them into a single feature
(exception handling).  (The "clumsy" doesn't add much to your argument,
since you don't really say what's so clumsy.)  Is this it?  I guess
there's some merit in that -- I like orthogonality.  Other than this, I
can't see any advantage of your scheme.

One advantage of the exceptions-as-objects viewpoint is that you can
have a hierarchy of exception classes.  This allows the call site to
determine the granularity of the exceptions to be handled.  E.g. handle
any I/O exception, or handle just the end-of-file exception, or handle
*all* exceptions.  This seems like a valuable capability, and I don't
see any way to do it in your "fluid" language.  E.g., suppose I want to
say, in the main program, "If I get *any* exception, send a signal to
the so-and-so device, telling it to shut down, and then I want to kill
the program"?

Another issue is efficiency:  I don't see any way to implement your
"fluid" feature with near-zero overhead on entering and leaving the
scope of a fluid object.  Exception handlers can be implemented
efficiently, because upon entering the scope of the handler, you can
know at compile time the address of the handler.  With fluid variables,
how do I know (at the original declaration point) that somebody won't
make a binding to some dynamic value?

Another issue is stack overflow: In Ada, if the stack overflows, you get
a Storage_Error exception.  The exception handler is executing *after*
chopping back the stack (i.e. after doing the non-local goto), so the
handler can reasonably do some work.  In your scheme, the handler is a
function, which is called while the stack is still "full".  You need
some way of ensuring that this function has enough stack space to do its
job -- perhaps hold a little bit of stack space "in reserve", so the
function can at least do a non-local goto.  This is easier in the Ada
case, since the only such function is the run-time system's
Raise_Exception procedure, which the compiler can know about.

I realize this is irrelevant to C++, where you can't even *try* to
handle stack overflows.

>  As to this, I rememjber reading someone stating that as far as he knew
>  only TECO (yes, TECO!) of most languages around provides general clean
>  entry/exit scope functions/triggers. Ah well.

What are "entry/exit scope functions/triggers".  (I don't know much
about TECO, except that it is terse to the point of looking like line
noise.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <32e9e445.163056932@library.airnews.net>,
Ronald E Jeffries <jeffries@ic.net> wrote:
>In a project I'm presently working on, the input routines try to
>handle all the errors.  Then when the application definers decided
>what kind of notifications they wanted on input errors, we had to go
>in and edit the input routines and change them all around to get the
>job done.  Had they just thrown an exception, we could have fielded
>the exception where we wanted to, and filed our notifications and gone
>on.

But this is true in Mr. Grandi's scheme, too.  Instead of raising an
exception, Mr. Grandi calls a function to handle the error.  And that
function is *dynamically scoped*, which means that the call site can
define it.  Just like the call site defines the handler code in the C++
or Ada way of doing things.

What you say above is the whole point of exceptions -- one piece of code
detects an error, and a different piece of code decides what to do about
it.  And Mr. Grandi's scheme is just as good as the C++/Ada scheme, in
this regard.  (I'm not sure why Mr. Grandi thinks his scheme is so
vastly superior, though.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>The obvious and correct solution is to make the name of the procedure
>dynamically scoped; then it can be redefined whenever this is needed.

How about this: The exception-handler is a procedure that is passed to
the procedure that detects the error.  So, in your sqrt example, the
sqrt function would take a Float parameter, and a function to call in
case the Float is negative.  This is essentially how Smalltalk does
things.  If you allow defaults on parameters, then you can make the
default handler be "print out a message and kill the program" or "enter
the debugger" or whatever.  So callers only have to worry about it if
they want to do something special on sqrt(negative).

Is this not pretty much equivalent to your dynamic-scoping scheme?
And it has the advantage that the relevant information is in the
specification of the procedure that wants to "raise" the exception.

- Bob

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "bertrand" == Bertrand Meyer <bertrand@eiffel.com> writes:


Chris> ISE Eiffel does give the user a degree of parameterization: a
Chris> compilation option specifies the size threshold beyond which a
Chris> routine will not be inlined.

Bertrand> Most users are happy with the
Bertrand> default, which inlines small, frequently called routines.

Chris> How on earth does the compiler know if a routine is "frequently
Chris> called"?

bertrand> Sorry, sloppy wording on my part. I meant "called from many
bertrand> different places in the code", which does tend to correlate
bertrand> with the numbers of times the routine will be called, although
bertrand> of course this is not always true (as with a routine that is
bertrand> called from just one place, but that place is in a loop). Just
bertrand> one criterion among others. Thanks for noting the incongruity
bertrand> in my original message.

So it is the number of static invocations rather than dynamic calls.

However it is often possible and actually rather easy to estimate
dynamic call frequency in a compiler; usually by propagating loop
repetition estimates across procedur boundaries, which is not that
hard. Loop repetition estimates are actually often surprisingly easy, as
a few loops have statically known repetition counts, and for the others
assuming a notional repetition count (something like 10) often gives
suprisingly good results (I remember reading this in somebody's work, I
think the author of PCCTS, but I am not sure).

Re: What is wrong with OO ?

[Sean Case]

In article <E413nz.9IA@research.att.com>,
bs@research.att.com (Bjarne Stroustrup) wrote:

>I think that if C++ was as hard to understand and use as some people claim,
>it would have failed to become popular in the first place and would have
>vanished under the continuous barrage of fair and unfair criticism - despite
>its (eventual) popularity.

and also

>I have often found myself wondering if the C++ wouldn't have been much better
>for all concered had there (just) been two dozen good C++ books instead of
>the 400+ books that mostly fail to teach the basic principles and mostly
>lead students and programmers astray.

So, C++ must be easy to learn, or else there wouldn't be hundreds of books
about it by people who don't understand it properly.

Or, to put it another way, C++ looks easy to learn, but has hidden pitfalls
that bedevil even those who write books on the subject.

Sean Case


---------------------------------------------
Sean Case                  gscase@tpgi.com.au

Code is an illusion. Only assertions are real.

Re: What is wrong with OO ?

[William Grosso]

On Sun, 26 Jan 1997 16:09:42 +1100, gscase@tpgi.com.au (Sean Case)
wrote:
>
>So, C++ must be easy to learn, or else there wouldn't be hundreds of books
>about it by people who don't understand it properly.
>
>Or, to put it another way, C++ looks easy to learn, but has hidden pitfalls
>that bedevil even those who write books on the subject.
>

Or, to put it another way, lots of crappy books have been written on 
C++ because people who don't know much about it have decided
to demonstrate their ignorance (and make a quick buck or two). 

Why this reflects on C++ rather than the authors is pretty much a 
mystery to me. 


Cheers,

Andy
"In the beginning, everything was even money"
       --Mike Caro

Re: OO, C++, and something much better!

[Richard Riehle]

On Thu, 9 Jan 1997, Bertrand Meyer wrote:

> To the four properties listed in my original I should also add two
> just as essential requirements: true multiple inheritance, for combining
> different abstractions (and with the right mechanisms to avoid any
> ambiguity or conflict); and, most importantly, Design by Contract
> and the rules on how assertions combine with inheritance. As someone
> remarked, it is really impossible to understand inheritance without
> understanding Design by Contract.

  Bertrand,

  I understand that the notion of "design by contract" was probably
  your original contribution to the literature, and I also realize
  that your concept of it is inextricably linked to the Eiffel 
  model for assertions.  However, I would like to suggest another
  view of the same idea.

  Assertions, as I understand them are predominately a run-time
  check on the software entities.  If I may oversimply, Preconditions
  "require" that certain propositions are true for a feature to begin
  executing, Postconditions "ensure" the other propositions are true upon
  leaving a routine, and Invariants guarantee that certain 
  entities remain intact during execution. While this description does
  seem to oversimplify the Eiffel design of assertions, I hope it will not
  offend you.  

  The Eiffel assertion model contains all of the elements of an Ada
  type, though an Ada data type does not contain all the elements of
  an Eiffel assertion.  When I say, 

            type T is ... ;

  I am saying for T that there is a set of assertions which are post-,
  pre-, and invariant.  These assertions, implied to be sure, are also
  checked at run-time.  I am saying by the declaration for T, that
  there is a minimum value for T, a maximum value, and any routine
  that uses T must not let it stray from that range.  Also, in Ada 95,
  I can check the validity of that value at any time using the 
  expression,

            if T1'Valid then ... end if;

  where T1 is a value of type T.  

  My question is, can one write an invalid assertion in Eiffel?  That is,
  can the expression  for an assertion be some complex that it contains
  the very kind of error that we are trying to avoid with procedural
  code?

  If I define an assertion,


              require
                   some complex mathematical expression
              ensure
                   another complex expression
  
  is there some mechnism inherent in Eiffel that can evaluate my
  assertions for correctness?

  The Ada model for pre-, post- and invariant conditions is, to be sure,
  more conservative and less sophisticated than designed into Eiffel. But
  that very conservatism contributes to the simplicity of the process of
  creating specifications. 

  Although Ada software developers do not customarily use the expression,
  "design by contract," that is exactly what they are doing whenever they
  design their own data types and specify the acceptable ranges and
  boundaries acceptable for those types.  

  As for the assertion mechanism, itself, there is probably no reason
  why a compiler publisher could not add to an implementation three
  pragmas,

          pragma Precondition  ( expression )
          pragma Postcondition ( expression )
          pragma Invariant     ( expression )

  but in so doing we must ask whether the addition of such pragmas would
  really make the resulting program more reliable than it was using 
  the more conservative model of simple type definition.

  Bertrand, on a personal note, I am glad to see you engaged in this
  dialogue.  We need more of this level of discussion here. Thanks.


  Richard

Re: OO, C++, and something much better!

[Nick Leaton]

Roy Phillips wrote:
> ... More problematical is
> the
> accidental substitution, for example of an operation with same name but
> an
> entirely differant meaning (for example, the terms 'interest' (financial
> domain) and 'interest' (marketing domain)) - blame the English language
> if
> you will, but without semantic specification (i.e., Eiffel assertions)
> the
> whole thing is a can of worms.
> 

If we take two classes, car and array. We have an array of cars and car
is comparable. We can then have a sort implemented in array and sort
cars. But if we wish to sort cars by size or price, then it becomes a
little more difficult. You have two meanings to comparable for a car.
Personally, I'm not sure of the best way to approach this problem but I
suspect it would involve a sorter class, with price_sorter and
size_sorter classes derived from the base class sorter.
-- 

Nick

Re: What is wrong with OO ?

[Robert C. Martin]

In article <5bub0e$jfc@uni.library.ucla.edu>, jmartin@cs.ucla.edu (Jay
Martin) wrote:

> Since C
> programmers are notorously ignorant of computer language design, the
> audience is not too discerning. 

This is a an unworthy, biased, and biggotted statement.  The only common
attribute shared by the class of people called "C programmers" is that they
write programs in C.  They do not share any form of common ignorance. Any
notoriety to that effect comes from those who erroneously take such notice.  
They form another class of people whose sole common characteristic is that they
think C programmers are ignorant.

-- 
Robert C. Martin    | Design Consulting   | Training courses offered:
Object Mentor       | rmartin@oma.com     |   Object Oriented Design
14619 N Somerset Cr | Tel: (847) 918-1004 |   C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com  

"One of the great commandments of science is:
    'Mistrust arguments from authority.'" -- Carl Sagan

Re: What is wrong with OO ?

[Paul Keister]

William Grosso <apuleius@ix.netcom.com> wrote in article
<32ebdcca.1653858@nntp.ix.netcom.com>...
: On Sun, 26 Jan 1997 16:09:42 +1100, gscase@tpgi.com.au (Sean Case)
: wrote:
: >
: >So, C++ must be easy to learn, or else there wouldn't be hundreds of
books
: >about it by people who don't understand it properly.
: >
: >Or, to put it another way, C++ looks easy to learn, but has hidden
pitfalls
: >that bedevil even those who write books on the subject.
Everything involving computers has hidden pitfalls.

: Or, to put it another way, lots of crappy books have been written on 
: C++ because people who don't know much about it have decided
: to demonstrate their ignorance (and make a quick buck or two). 
: 
: Why this reflects on C++ rather than the authors is pretty much a 
: mystery to me. 
C++ was designed so that it could be learned in stages, to that experienced
programmers (particularly C programmers) could use individual features of
the language as they are ready.  Unfortunatley, many people choose to write
books while they are in the beginning stages of learning C++.

For some of us, the love affair with C++ begins with the perception that
just by using member functions and inheritance in our procedural code,
things get clearer, and code gets easier to maintain.  Some people never
get past this stage(look at the Microsoft Foundation Classes, for
instance).  I my case, it took years for me to reach a level of
understanding where I was able to realize my ignorance.

I consider this to be a real strength of C++ and a key factor in its
overwhelming popularity.  But it does have a downside, which is that
beginner C++ programmers tend to be overconfident.

Writing a book with a title "Learn C++ in 29 Days" is the result of
calculating deception on the part of the author and/or publisher.  But when
someone buys the book, reads it in 29 days, and then has enough confidence
to consider themselves a C++ expert, you have to at least partly blame the
accessibility of the languges.

I don't think this is a bad thing, just a fact of life, and a natural
consequence of a language that is so woderfully accessible.

-- 
Paul Keister
        "opinions express are generally the
          exact opposite of my employer"
   http://www.crl.com/~diyall/husband

Re: What is wrong with OO ?

[Dann Corbit]

Following that line of reasoning:
There are thousands of books on elementary arithmetic.  Many times as many
as the number of C++ books.  That must mean that leaning elementary
arithmetic is only for Ph.D. candidates.  Certainly not for young children.

Your argument is NULL.

Try reading one of Steve Heller's books on C++.  They are designed so that
absolutely anyone can understand.  I am not saying that C++ is the easiest
thing on earth to learn.  Sometimes, there is difficulty associated with
learning (even elementary arithmetic has perils for those who have not yet
grasped all nuances).  Learning C++ is not so difficult that a capable high
school student cannot learn it.

Sean Case <gscase@tpgi.com.au> wrote in article
<AF1132469668D5B8@rd-ppp-072.tpgi.com.au>...
> In article <E413nz.9IA@research.att.com>,
> bs@research.att.com (Bjarne Stroustrup) wrote:
> 
> >I think that if C++ was as hard to understand and use as some people
claim,
> >it would have failed to become popular in the first place and would have
> >vanished under the continuous barrage of fair and unfair criticism -
despite
> >its (eventual) popularity.
> 
> and also
> 
> >I have often found myself wondering if the C++ wouldn't have been much
better
> >for all concered had there (just) been two dozen good C++ books instead
of
> >the 400+ books that mostly fail to teach the basic principles and mostly
> >lead students and programmers astray.
> 
> So, C++ must be easy to learn, or else there wouldn't be hundreds of
books
> about it by people who don't understand it properly.
> 
> Or, to put it another way, C++ looks easy to learn, but has hidden
pitfalls
> that bedevil even those who write books on the subject.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jeffries" == Ronald E Jeffries <jeffries@ic.net> writes:

jeffries> On 25 Jan 1997 02:07:04 +0000, piercarl@sabi.demon.co.uk (Piercarlo
jeffries> Grandi) wrote:

piercarl> Let's start with the nature of exceptions. The first point is
piercarl> that if a procedure implements a total function then it will
piercarl> never have an exception.

piercarl> Therefore exceptions arise only and only if a procedure
piercarl> implements a partial function, and arise only and only when
piercarl> the inputs to a procedure are outside its domain.

jeffries> Yes ... and then you go on to make the function more robust,
jeffries> which would be a good thing when it's practical.  But as you
jeffries> point out, the exceptions arise when the inputs are out of the
jeffries> range contemplated by the function as written.

jeffries> Exceptions, however, whether represented as objects or long
jeffries> jumps, are about handling the unexpected.

Not quite -- they are precisely about handling the *expected*, but
*undefined*. By definition you cannot handle the unexpected, I would
say.

[ ... ]

jeffries> In a project I'm presently working on, the input routines try
jeffries> to handle all the errors.  Then when the application definers
jeffries> decided what kind of notifications they wanted on input
jeffries> errors, we had to go in and edit the input routines and change
jeffries> them all around to get the job done.  Had they just thrown an
jeffries> exception, we could have fielded the exception where we wanted
jeffries> to, and filed our notifications and gone on.

Ah, but that's precisely a good example that shows that exception
handling (a terrible misnomer) is about dealing with the expected, but
undefined. It is expected that the ``user'' will do strange things, but
since it is as yet undefined what strange things will happen, one punts
to an handler define by a dynamic-context, and this is the very reasons
for having dynamically scoped identifiers.

Put another way exception handling is when the required precondition of
a procedure is weaker than that of the procedure one actually is in a
position to write. The difference is then filled in by calling
dynamic-context dependent ``handlers''.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> The obvious and correct solution is to make the name of the
piercarl> procedure dynamically scoped; then it can be redefined
piercarl> whenever this is needed.

bobduff> How about this: The exception-handler is a procedure that is
bobduff> passed to the procedure that detects the error.  So, in your
bobduff> sqrt example, the sqrt function would take a Float parameter,
bobduff> and a function to call in case the Float is negative.  This is
bobduff> essentially how Smalltalk does things.  If you allow defaults
bobduff> on parameters, then you can make the default handler be "print
bobduff> out a message and kill the program" or "enter the debugger" or
bobduff> whatever.  So callers only have to worry about it if they want
bobduff> to do something special on sqrt(negative).

bobduff> Is this not pretty much equivalent to your dynamic-scoping
bobduff> scheme?

It is indeed entirely equivalent for that is a (xxx-reduction it the
technical term, I don't remember offhand which greek letter stands for
xxx), a way to transform global (dynamically scoped) variables into
procedure parameters.

If one does not like global variables, dynamically scoped or not, one
can transform them into parameters to all procedures that access
them. But then for all their awfulness global variables, and even
dynamically scoped global variables, are useful, in the sense they are
merely convenient, for the xxx-reduction involves a bit more verbiage.

With non-too-clever implementations adding defaulted extra arguments can
also result in distinctly inferior code, because it involves passing an
extra argument for each potential ``exception'' one wants to handle.

Consider for example floating division: it would require at least three
extra ``implicit'' arguments/parameters (overflow, underflow, illegal
divisor).

bobduff> And it has the advantage that the relevant information is in
bobduff> the specification of the procedure that wants to "raise" the
bobduff> exception.

This is not a big advantage; one can achieve the same effect by
requiring, as some languages do, a procedure/module to ``import''
explicitly any global (or fluid) variables it will make use of.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

[ ... ]

bobduff> What you say above is the whole point of exceptions -- one
bobduff> piece of code detects an error, and a different piece of code
bobduff> decides what to do about it.  And Mr. Grandi's scheme is just
bobduff> as good as the C++/Ada scheme, in this regard.  (I'm not sure
bobduff> why Mr. Grandi thinks his scheme is so vastly superior,
bobduff> though.)

Actually, it's not *my* scheme, it has been known for thirty years or
so; and then it is not quite "vastly superior", it is just the right
thing to do; my point is that:

  piercarl> So, basically *everything* is wrong (and clumsily so) with
  piercarl> the ``C++'' exception-as-object system:

  piercarl> * the name of the exception class should be that of a
  piercarl>   dynamically scoped procedure.

  piercarl> * an exception object is really just a clumsy and silly way of
  piercarl>   specifying an argument list to that dynamically scoped
  piercarl>   procedure.

  piercarl> * non local control transfers are then mandatory.

These things are wrong because they involve a clumsy and limited
mechanism. Dynamically scoped identifiers are usuful for a number of
cases where actions must depend on the program context; dynamically
scoped variables, not just procedures, are very useful too. Non local
control transfers are also very useful in their own right.

Now, ``exception handling'' presents as an ad hoc, and often pretty
ungainly mechanism, a particular, and restrictive, combination of the
fundamental concepts of dynamic coping and non-local control transfers.

It is much better to provide the two things separatley, for this allows
for example ``exception handling'' _without_ forcing control transfers,
and control transfers without necessarily involving dynamically scoped
identifiers. And then runtime parametrization via dynamically scoped
variables...

But really the biggest problem of the mechanism is that it presents as
something complicated and special, to the point of requiring its own
control structure, chapter in the book, papers, and so on, what is an
entirely simple thing, as long as one presents it as: dynamic scope
+optional control transfer.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "bobduff" == Robert A Duff <bobduff@world.std.com> writes:

bobduff> In article <yf3lo9iqzhz.fsf@sabi.demon.co.uk>,
bobduff> Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:

piercarl> The obvious and correct solution is to make the name of the
piercarl> procedure dynamically scoped; then it can be redefined
piercarl> whenever this is needed.

bobduff> How about this: The exception-handler is a procedure that is
bobduff> passed to the procedure that detects the error.  So, in your
bobduff> sqrt example, the sqrt function would take a Float parameter,
bobduff> and a function to call in case the Float is negative.  This is
bobduff> essentially how Smalltalk does things.  If you allow defaults
bobduff> on parameters, then you can make the default handler be "print
bobduff> out a message and kill the program" or "enter the debugger" or
bobduff> whatever.  So callers only have to worry about it if they want
bobduff> to do something special on sqrt(negative).

bobduff> Is this not pretty much equivalent to your dynamic-scoping
bobduff> scheme?

It is indeed entirely equivalent for that is a (xxx-reduction it the
technical term, I don't remember offhand which greek letter stands for
xxx), a way to transform global (dynamically scoped) variables into
procedure parameters.

If one does not like global variables, dynamically scoped or not, one
can transform them into parameters to all procedures that access
them. But then for all their awfulness global variables, and even
dynamically scoped global variables, are useful, in the sense they are
merely convenient, for the xxx-reduction involves a bit more verbiage.

With non-too-clever implementations adding defaulted extra arguments can
also result in distinctly inferior code, because it involves passing an
extra argument for each potential ``exception'' one wants to handle.

Consider for example floating division: it would require at least three
extra ``implicit'' arguments/parameters (overflow, underflow, illegal
divisor).

bobduff> And it has the advantage that the relevant information is in
bobduff> the specification of the procedure that wants to "raise" the
bobduff> exception.

This is not a big advantage; one can achieve the same effect by
requiring, as some languages do, a procedure/module to ``import''
explicitly any global (or fluid) variables it will make use of.

Re: OO, C++, and something much better!

[matthew mclellan]

Nick Leaton (nickle@calfp.co.uk) wrote:
: Roy Phillips wrote:
: > ... More problematical is
: > the
: > accidental substitution, for example of an operation with same name but
: > an
: > entirely differant meaning (for example, the terms 'interest' (financial
: > domain) and 'interest' (marketing domain)) - blame the English language
: > if
: > you will, but without semantic specification (i.e., Eiffel assertions)
: > the
: > whole thing is a can of worms.
: > 

: If we take two classes, car and array. We have an array of cars and car
: is comparable. We can then have a sort implemented in array and sort
: cars. But if we wish to sort cars by size or price, then it becomes a
: little more difficult. You have two meanings to comparable for a car.
: Personally, I'm not sure of the best way to approach this problem but I
: suspect it would involve a sorter class, with price_sorter and
: size_sorter classes derived from the base class sorter.
: -- 

: Nick

What about deriving car_array from array, and overriding the sort method?

Matt
Raytheon E-Systems

--The opinion(s) expressed above are mine, and not at all related to Raytheon
	E-Systems

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <yf3wwsxqw1z.fsf@sabi.demon.co.uk>,
Piercarlo Grandi <piercarl@sabi.demon.co.uk> wrote:
>Actually, it's not *my* scheme, it has been known for thirty years or

Yes, I realize you didn't invent it.  ;-)

>...Dynamically scoped identifiers are usuful for a number of
>cases where actions must depend on the program context; dynamically
>scoped variables, not just procedures, are very useful too. Non local
>control transfers are also very useful in their own right.

OK, I'll buy that much.

But how do you write an ``exception handler'' that catches a whole class
of related exceptions.  (E.g. division by zero might raise
"Divide_Error", and the caller can choose to handle "Divide_Error" or
"Arithmetic_Error" (which includes Divide_Error), or "Any_Exception", or
whatever.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[John W. Sarkela]

Piercarlo Grandi wrote:
[...]
> But really the biggest problem of the mechanism is that it presents as
> something complicated and special, to the point of requiring its own
> control structure, chapter in the book, papers, and so on, what is an
> entirely simple thing, as long as one presents it as: dynamic scope
> +optional control transfer.
I would advance the argument that the nature of the most appropriate
exception mechanism will vary as one adopts procedural, functional or
object oriented points of view. 

As an example of why I think objects modeling exceptions are right, I
would use the point of view first expressed to me by Bertrand Meyer,
programming by contract. Using the exception mechanism with which I
am most familiar, Visual Smalltalk's.

In human interaction, a contract is a document that describes a promise
of service to a client. A contract has three important qualities.
  1. It is observable by client and supplier.
  2. It is verifiable by client and supplier.
  3. It is enforcable by client or supplier.
When either the client or supplier detects that the terms of the
contract
have been violated, the situation is sent into arbitration for
resolution.

In my programs exactly the same holds true. When assertions about the
state
of execution have been violated, I create an instance of an exception
that
models as carefully as possible all of the information about the
observed
violation of specification. Thus, from an object modeling perspective,
the
exception object serves as the court of arbitration for disputes between
clients
and servers.  Handlers may be set associated with method activation
records.
Each handler serves as a local arbitrator for the signaled exception. If 
recovery is not possible, the dispute may be passed to the next higher
authority.
If none are found, default rules may be handled by the exception object
itself.

I have found this model of exceptions and their handling to be both
intuitive
and effective. The fact that non-local control transfers occur is not
really
a problem conceptually, because the control unwinds the chain of
activations
that led to the exceptional situation in the first place.

This is a rational, structured, normal handling of exceptions in an
object
model. If I were using a functional language, then total functions would
be a more appropriate point of view. However, for an object oriented
language
exceptions as objects provide a rich implementation mechanism for
supporting
the design notion of programming by contract.

John Sarkela
jsarkela@enfish.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[John (Max) Skaller]

On Sat, 25 Jan 1997 20:52:41 GMT, bobduff@world.std.com (Robert A
Duff) wrote:

>I'm not sure why Mr. Grandi thinks his scheme is so
>vastly superior, though.

	The reasons are plain enough: 

	First, the scheme permits retry, C++ style exceptions do not.

	Second, the scheme does not require any special
	constructions. No exception handling constructions.

	It is implemented using dynamically scoped functions,
	which are useful for other things.

	Summary: the scheme subsumes the C++ scheme
	because it can do everything the C++ scheme can do,
	with no more complexity, using other facilities --
	which are also useful in other contexts.

This would be totally convincing were it true: a language
should not introduce new special constructions when
a library component or technique would suffice.

In the example of a dynamically scoped function, there
is a direct correspondence between the "throw"
function and the "catch" function. (They're
both called the same name).

Question: What is the functional equivalent to the ability
of C++ to provide "matching"?

Re: What is wrong with OO ?

[Damon Feldman]

In article <rmartin-2701971103140001@pool10-006.wwa.com>, rmartin@oma.com (Robert C. Martin) wrote:
>In article <5bub0e$jfc@uni.library.ucla.edu>, jmartin@cs.ucla.edu (Jay
>Martin) wrote:
>
>> Since C
>> programmers are notorously ignorant of computer language design, the
>> audience is not too discerning. 
>
>This is a an unworthy, biased, and biggotted statement.  The only common
>attribute shared by the class of people called "C programmers" is that they
>write programs in C. 

While technichally true, I hope this doesn't mean that I have to stop 
insulting COBOL programmers when I see them on the street :-).

Perhaps the original poster meant to say that programmers who *advocate C
as a superior language* are ignorant of language design.  This would have
some logic behind it.

Damon

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Lawrence G. Mayka]

piercarl@sabi.demon.co.uk (Piercarlo Grandi) wrote:

>It is much better to provide the two things separatley, for this allows
>for example ``exception handling'' _without_ forcing control transfers,
>and control transfers without necessarily involving dynamically scoped
>identifiers. And then runtime parametrization via dynamically scoped
>variables...

Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp.  As
you may know, Common Lisp has long had both nonlocal control transfers
(THROW and CATCH--perhaps Bjarne even borrowed his keywords from
Lisp!) and dynamically scoped variables (as an option, along with the
default behavior of lexical scoping).  Indeed, some implementations of
ANSI Common Lisp exception handling do indeed employ these earlier
constructs.  Just as you suggest, dynamically scoped functions are
easily simulated via dynamically scoped variables whose values are
function objects, or via syntax extension (the Common Lisp
macroization system).

But what your scheme lacks is a classification or "matching"
mechanism.  Common Lisp was well-prepared to provide this because,
even before the standardization of CLOS, it offered the
single-inheritance capability of DEFSTRUCT and the type-testing
operator TYPEP; and so the Pittman Condition System was implementable
entirely on top of 1985-vintage Common Lisp constructs, yet easily
extendible to CLOS later.

One other very useful element both your scheme and that of C++ lacks
is that of closures as handlers.  Very often, an exception handler is
more comfortably and easily written as a lexically scoped function
that manipulates the variables of an outer function.  Again, Common
Lisp already had full-power lexical closures by 1985, whereas C++
still doesn't.

You may ask, if a language such as Common Lisp already has all the
necessary base capabilities, why provide the "syntactic sugar" of
exception handling constructs?  To clarify, standardize, and perhaps
optimize conventional usages.  Since Common Lisp supports syntax
extension (a powerful macroization system), programmers would probably
be writing such syntactic encapsulations anyway; we may as well
standardize them to enhance portability of programs, skills,
knowledge, etc.


Lawrence G. Mayka
lgmayka@sprynet.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert Dewar]

Lawrence said

"Ironically, though, your first posting in this thread was a response
to =my= posting, pointing out to Mr. Stroustrup that his design for
exception handling was implemented years earlier in Common Lisp."

It is just conceivably possible that Mr Stroustrup is indeed familiar
with Common Lisp and quite a few other languages :-) :-) :-)

(is three smileys enough to make it quite clear to people that an element
of sarcasm is intended :-)

If you really think that Common Lisp invented the idea of exceptions, then
you need to do some more history reading yourself!

Really, everyone should realize that language design does not happen in
a vacuum. Of course good ideas are borrowed from one language to another.
For example, many of the most important contributions that Algol-68 has
been made are in the form of ideas exported to other languages (e.g.
serial elaboration of declarations and the notion of subunits -- copied
from A68 into Ada). 

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <5d93d3$nhs$1@goanna.cs.rmit.edu.au>,
Richard A. O'Keefe <ok@goanna.cs.rmit.edu.au> wrote:
>ka@socrates.hr.lucent.com (Kenneth Almquist) writes:
>>Dynamic scoping is not a particularly good candidate for inclusion in
>>a language because the programmer can implement it by hand (at least in
>>C++ and Ada) and with good program design it should be rarely used.

But it is *always* used (in C++ and Ada) when you raise exceptions.
I admit that it is rarely needed in any other contexts.

>>...  The
>>same goes for nonlocal gotos; these can be simulated using Ada/C++ style
>>exceptions and with good program design they should be rarely used.

This seems like abstraction inversion, to me.  It makes more sense to me
to say that exceptions are implemented in terms of non-local gotos,
rather than the other way 'round.

I don't understand why gotos are considered evil, whereas exceptions are
OK.  Raising an exception has at least as bad an effect on readability
as a goto -- it's like a goto, but you can't tell (statically) where
it's going to.  Nonetheless, exceptions are a Good Thing (whether they
are done like Ada or like Piercarlo Grandi wants).

>Without wanting to argue either for or against dynamic scoping (some of
>my favourite languages have it and some haven't), the claim that "the
>programmer can implement it by hand" is true only in the sense that the
>programmer can implement most control structures using "if ... goto".
>You can in this sense implement almost _anything_ by hand, but you'd be
>mad to, and you wouldn't put up with a language designer using that
>excuse to omit while loops from the language.

Well, in Smalltalk, while loops are not exactly part of the core
language -- they're part of the predefined library.  And I think that's
a pretty elegant way to do it.

>In fact, the programmer can _not_ implement dynamic scoping easily by
>hand in Ada and thanks to the arcane scope rules of C++ (from time to
>time I reread the draft C++ standard trying to find out what the scope
>rules _are_, does _anyone_ know?) it is even less true there.
>
>There are a number of points about dynamic scoping:
>(a) it dilutes the "ownership" of a name.
>    For this reason I don't think it would be appropriate for Ada.
>(b) dynamically scoped variables are automatically unwound whenever
>    a contour rebinding them is exited for whatever reason.
>(c) binding and unbinding dynamically scoped variables is expected
>    to be CHEAP.
>Simulating dynamically scoped variables in Ada or C++ would seem to require
>- introducing a *visible* shadow variable to hold the outer value
>- setting up an exception handler to unwind and resignal
>- remembering to unwind at _every_ return point.
>This is a heavy burden on the programmer, worse in my view than having
>to use "if ... goto .." instead of "while".  It is also likely to be
>seriously less efficient than a reasonable mechanism implemented by the
>compiler.

The above can simulated in Ada using controlled types.  It's possible to
implement controlled types efficiently, but it's not easy in the general
case, and I don't know of any Ada compilers that do so.

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Patrick Doyle]

In article <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org>,
Vassili Bykov <vbykov@cam.org> wrote:
>
>Control constructs cannot *in principle* be a part of the standard library.
>(Unless you take Lisp or Scheme and consider macros as part of the
>library--which, strictly speaking, they are not).

  Why is that?

-- 
--
Patrick Doyle
doylep@ecf.utoronto.ca

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jmartin" == Jay Martin <jmartin@cs.ucla.edu> writes:

jmartin> piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes:

piercarl> Well, yes and no. Not quite. It can be kludged, and I have
piercarl> provided one such kludge, but adding to a language is easy but
piercarl> non trivial. Since it is needed regardless of whether a
piercarl> language provides it or not, it's better to have it done
piercarl> cleanly and efficiently rather than as a kludge.

piercarl> This is actually a general principle of system/language
piercarl> design; there are a number of features which are essential,
piercarl> and cannot simply be omitted; omitting them from the
piercarl> primitives of the languages will simply mena that the
piercarl> implementation burden shifts on the programmer. My two
piercarl> favourite examples are spooling for operating systems and
piercarl> generators for programming languages. There are OSes that
piercarl> don't have spooling, and then it must be done by the user, by
piercarl> multitasking her/imself; there are languages that don't have
piercarl> generators, and then they must be simulated by the programmer,
piercarl> usually via global variables or ``control blocks''. In either
piercarl> case it is a waste. Dynamic scoping is another good example.

jmartin> It seems to me you are assuming that dynamic scoping is necessary and
jmartin> that a programmer will have to simulate it.  It seems more prudent to
jmartin> me to recognize the limitations and paradigm of your tool and just
jmartin> implement it in the tedious and boring "normal" way.

Ahhh, but what I have been arguing is merely the obvious: runtime
customization of imlementations is a fact of life, whether one like sit
or not, and dynamically scoped identifiers are the most
direct/obvious/``simplest'' way to do it, e.g. environment variables in
UNIX and similar facilities in most other systems/languages.

It is well true that once can always perform a reduction from a program
with statically or dynamically scoped global/fluid variables to one that
does not have them, only parameters and local variables (and the latter
can further be transformed into parameters):

jmartin> Which in this instance is by passing parameters

but this does not necessarily mean that it is desirable... In effect it
is not very desirable, as long as the global/fluid variables left in teh
program are clearly encapsulated.

jmartin> or having different functions.

This is in the general case unfeasible (there can be any number of
procedures that one would want to do)...

jmartin> [ ... strong preference for the bondage&discipline school of
jmartin> programmign language design :-) ... ]

jmartin> When you are in a room filled criminally insane programmers,
jmartin> straightjackets nstart sounding like a cool idea.

I must confess that this approach actually strikes a chord with me,
except that I'd rather have a BFG-9000 than a set of straitjackets :-).

But then on balance, emotions set aside, I tend to prefer tools that can
be used nicely by the non criminally insane (the merely insane probably)
programmers to do nifty things, than those designed for damage
limitation. Perhaps I am an incurable optimist.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<5def36$rjd@mulga.cs.mu.OZ.AU>...
> "Vassili Bykov" <vbykov@cam.org> writes:
> > [...]
> >Control constructs cannot *in principle* be a part of the standard
library.
> 
> Sure they can.  Consider tcl, for example.

Oops, sorry I jumped it--in the post I replied to, Kenneth Almquist was
talking about Ada and C++ so I assumed "regular" languages with
applicative-order evaluation.  In these, they cannot because functions
always evaluate arguments.  For control constructs you would either need
lazy as in Haskell or syntactially transparent delayed as in Smalltalk
evaluation.  (Or... hmm... weird? as in Tcl. :-)

> >(Unless you take Lisp or Scheme and consider macros as part of the
> >library--which, strictly speaking, they are not).
> 
> Why aren't they?  What *in principle* reason is there why they can't be?

Because macros are AST (or token stream, in lesser languages)
transformation rules known to the compiler. Libraries are collections of
machine (or virtual machine) code blocks to be called by the application
program.  In other words, macros extend the compiler while library routines
extend the apllication program.  That's the "strictly speaking" reason I
meant.  

I didn't mean to be dense--I said that only because if we extend the
meaning of "standard library" to include standard macros always known to
the compiler then what is the difference between "part of the library" and
"part of the language"?

--Vassili

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Bill Gooch]

Vassili Bykov wrote:
> 
> ....
> I didn't mean to be dense--I said that only because if we extend the
> meaning of "standard library" to include standard macros always known to
> the compiler then what is the difference between "part of the library" and
> "part of the language"?

Why should there be such a difference in practice, 
regardless of the nature of the extension?

-- 
William D. Gooch             bill@iconcomp.com
Icon Computing               http://www.iconcomp.com     
Texas liaison for the International Programmers Guild 
For IPG info, see http://www.ipgnet.com/ipghome.htm

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Bill Gooch <bill@iconcomp.com> wrote:
> Vassili Bykov wrote:
> > I didn't mean to be dense--I said that only because if we extend the
> > meaning of "standard library" to include standard macros always known
to
> > the compiler then what is the difference between "part of the library"
and
> > "part of the language"?
> 
> Why should there be such a difference in practice, 
> regardless of the nature of the extension?

I don't say there should be.  I was referring to the part of the original
Fergus Henderson's <fjh@murlibobo.cs.mu.OZ.AU> message:

> Actually I'd be quite happy with a language in which while loops
> were part of the standard library, rather than part of the language.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Robert A Duff]

In article <01bc14ab$3ce476e0$752d54c7@vbykov.hip.cam.org>,
Vassili Bykov <vbykov@cam.org> wrote:
>Control constructs cannot *in principle* be a part of the standard library.

Control constructs *are* part of the standard library in Smalltalk.  And
it's an elegant way to do things.  I'm not sure what you mean by "*in
principle*" in this case.

Probably (I suspect) the whileTrue:do: thing (or whatever it's called)
in Smalltalk is implemented as a "built in" thing in most
implementations, but that's not semantically necessary.  If Smalltalk
had a goto primitive, one could write the while loop primitive in
Smalltalk.  (Actually, I guess you can do it via recursion, if you're
willing to count on tail recursion elimination.)  In any case, the fact
that it's "built in" to the compiler does not imply that it's "built in"
to the semantics -- I mean, a C compiler is well within its rights to
"build in" the printf function (i.e. special case it in some way that
might get better efficiency).

>(Unless you take Lisp or Scheme and consider macros as part of the
>library--which, strictly speaking, they are not).

No, they're not macros, they're "normal" messages/methods (that is,
procedure calls), with "blocks" as parameters.  (I'm not sure why macros
are considered out of bounds here, but in any case, macros aren't needed
in this case.)

- Bob

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Jay Martin]

pcg@aber.ac.uk (Piercarlo Grandi) writes:

>>>> "jmartin" == Jay Martin <jmartin@cs.ucla.edu> writes:

>Ahhh, but what I have been arguing is merely the obvious: runtime
>customization of imlementations is a fact of life, whether one like sit
>or not, and dynamically scoped identifiers are the most
>direct/obvious/``simplest'' way to do it, e.g. environment variables in
>UNIX and similar facilities in most other systems/languages.

Yeah but sometimes you have to go that extra mile for good software.

>jmartin> Which in this instance is by passing parameters

>but this does not necessarily mean that it is desirable... In effect it
>is not very desirable, as long as the global/fluid variables left in teh
>program are clearly encapsulated.

I basically always pass data and almost never use variables from a
larger scope (globals). Doesn't seem much of burden to me. Explicit
data flow seems clearer and to not do so is conceptually using
"side-effects".  Ick!

>jmartin> or having different functions.

>This is in the general case unfeasible (there can be any number of
>procedures that one would want to do)...

But in specific cases it works fine.  Generality can have many downsides.
  

Jay

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Fergus Henderson]

"Vassili Bykov" <vbykov@cam.org> writes:

>I didn't mean to be dense--I said that only because if we extend the
>meaning of "standard library" to include standard macros always known to
>the compiler then what is the difference between "part of the library" and
>"part of the language"?

The difference is that things that are part of the library are things
that a user can program user-defined alternatives.  For example,
in C, printf() is part of the standard library, and you can write a
my_printf() function that does similar things to printf() (and
is perhaps implemented as a layer on top of printf()).  On the
other hand, it's not possible to do the equivalent for Pascal's
write statement or for C's for loops, because these are part of
the language proper, not the standard library.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "fjh" == Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> writes:

[ ... ]

fjh> The difference is that things that are part of the library are things
fjh> that a user can program user-defined alternatives.  For example,
fjh> in C, printf() is part of the standard library, and you can write a
fjh> my_printf() function that does similar things to printf() (and
fjh> is perhaps implemented as a layer on top of printf()).  On the
fjh> other hand, it's not possible to do the equivalent for Pascal's
fjh> write statement or for C's for loops, because these are part of
fjh> the language proper, not the standard library.

Well, even if 'printf' were syntactically a statement and not a
procedure call, you could still write your 'my_printf' as a procedure;
similarly that 'if then else' is not a procedure call in ``Pascal'' does
not forbid you from writing a procedure like
'myif(condition,thenPart,elsePart)'.

The real reason why/why not is rather different from being alanguage
primitive or not; it is whether one has the reflective abilities to
implement one's own verion of 'printf' or 'myif'.

In ``C'' one has the reflective facilities for writing one's own
'printf' (such facilities are '#include <stdarg>', which allow a
procedure to ``reflect'' on its parameter list), but not for writing
control structures (except for some very limited ability using
preprocessor macros). Pascal does not offer reflective
abilities/primitives for parameter lists or control structures.

There are languages that offer user-visible primitives that allow
building ad-hoc control structures, by way of ``reflection''; usually
such facilities, as a bit of overkill, are based on that extremely
powerful reflective ability, the one to reflect on program state via
continuations/closures, and the associated one, the ability to reflect
on program fragments; for example Scheme and Smalltalk-80 allow
definitions of control structures using either/both reflection on
continuation/closures and code fragments. Neither are avalable in ``C''
or ``Pascal'', and thus control abstraction is not possible; the issue
is not thus quite related to having some reserved syntax or not.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "fjh" == Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> writes:

[ ... ]

fjh> The difference is that things that are part of the library are things
fjh> that a user can program user-defined alternatives.  For example,
fjh> in C, printf() is part of the standard library, and you can write a
fjh> my_printf() function that does similar things to printf() (and
fjh> is perhaps implemented as a layer on top of printf()).  On the
fjh> other hand, it's not possible to do the equivalent for Pascal's
fjh> write statement or for C's for loops, because these are part of
fjh> the language proper, not the standard library.

Well, even if 'printf' were syntactically a statement and not a
procedure call, you could still write your 'my_printf' as a procedure;
similarly that 'if then else' is not a procedure call in ``Pascal'' does
not forbid you from writing a procedure like
'myif(condition,thenPart,elsePart)'.

The real reason why/why not is rather different from being alanguage
primitive or not; it is whether one has the reflective abilities to
implement one's own verion of 'printf' or 'myif'.

In ``C'' one has the reflective facilities for writing one's own
'printf' (such facilities are '#include <stdarg>', which allow a
procedure to ``reflect'' on its parameter list), but not for writing
control structures (except for some very limited ability using
preprocessor macros). Pascal does not offer reflective
abilities/primitives for parameter lists or control structures.

There are languages that offer user-visible primitives that allow
building ad-hoc control structures, by way of reflection; usually such
facilities, as a bit of overkill, are based on that extremely powerful
reflective ability, the one to reflect on program state via
continuations/closures, and the associated one, the ability to reflect
on program fragments; for example Scheme and Smalltalk-80 allow
definitions of control structures using either/both reflection on
continuation/closures and code fragments. Neither are avalable in ``C''
or ``Pascal'', and thus control abstraction is not possible.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Fergus Henderson]

ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes:

>I wrote:
>>>In fact, the programmer can _not_ implement dynamic scoping easily by
>>>hand in Ada and thanks to the arcane scope rules of C++ (from time to
>>>time I reread the draft C++ standard trying to find out what the scope
>>>rules _are_, does _anyone_ know?) it is even less true there.
>
>fjh@murlibobo.cs.mu.OZ.AU (Fergus Henderson) replied fliply:
>>To answer your parenthetical question, the scope rules are defined in
>>sections 3.3 [basic.scope] and 3.4 [basic.lookup] of the draft.
>
>Get real!

OK, that _was_ a bit flip.  You're right that the scope rules of C++
can be rather arcane.

>fjh proposes the following sketch of implementing a dynamically
>scoped variable in C++:
>
>>	#include "dynamic_scope.h"
>>	
>>	dynamically_scoped<int> x;
>
>>	void foo() {
>>		rebind<x> local_x;	// or something like that
>>	}
>
>Close, but not quite.  (This approach is also applicable in Ada 95.)
>
>What's wrong with it?  x has the wrong type.

You can give `x' an implicit conversion to type "reference to int".

	operator int & ();

Now, due to C++'s arcane overloading rules ;-), this is not
exactly the same in all circumstances, but it usually does
the trick.  Sometimes you may have to insert a few additional
explicit conversions.

(My compiler seems to think that you need an assignment operator
as well.  Maybe it's right.)

>In languages that have them, dynamically scoped variables follow different
>_scope_ rules from other variables, but there is nothing special about
>their _contents_.  It would be necessary to do something like
>
>	int x;
>
>	void foo() {
>	    rebind< &x > preserved_x;
>	    ...
>	}

You could do that too, and it would work fine in the case of `int'.
However, for other types that has some disadvantages.
It won't work if type of `x' doesn't allow copying.
Even if `x' can be copied, you will most likely have to do a deep copy,
which may be slow.  That's why I went for the approach with
the implicit conversion-to-reference instead.

>An "implementation" of
>dynamically scoped variables which depends on giving them the wrong
>type (your approach) _does_ impose a heavy burden on the programmer,
>because then every reference that would have been a reference to x
>has to become x.contents() or whatever you want to call it.

No, that's not correct, because you can use an implicit conversion.

>>>It is also likely to be
>>>seriously less efficient than a reasonable mechanism implemented by the
>>>compiler.
>
>>I'm not convinced.
>
>Why not.  Do you actually know any C++ compilers which make your approach
>run as fast as a good Lisp system (Harlequin, Franz, CMUCL)?  The obvious
>mechanism is essentially a Prolog-style trail.

Well, with the implementation I was thinking of, block entry and block
exit are likely to quite cheap.  The main cost of my C++ implementation
is that you have an extra indirection for each access to the variable.
But I think it will be at least competitive.

	template <class T> class dynamically_scoped;

	template <class T, dynamically_scoped<T> & ds_var> class rebind;

	template <class T>
	class dynamically_scoped {
		template <dynamically_scoped<T> & ds_var>
		friend class rebind<T, ds_var>;
		T* current_var;
		T original_var;
	public:
		dynamically_scoped() {
			current_var = &original_var;
		}
		dynamically_scoped<T>& operator = (const T &val) {
			*current_var = val;
			return *this;
		}
		operator T& () {
			return *current_var;
		}
	};

	template <class T, dynamically_scoped<T> & ds_var>
	class rebind {
		T new_var;
		T* prev_var;
	public:
		rebind() {
			prev_var = ds_var.current_var;
			ds_var.current_var = &new_var;
		}
		~rebind() {
			ds_var.current_var = prev_var;
		}
	private:
		// prevent copying
		rebind(const rebind<T, ds_var>&);
		void operator =(const rebind<T, ds_var>&);
	};

If you're willing to assume that the variable can be cheaply copied,
you can do better.  Here's an alternate implementation that has
performance characteristics that are more similar to your suggested
implementation:

	template <class T> class dynamically_scoped;

	template <class T, dynamically_scoped<T> & ds_var> class rebind;

	template <class T>
	class dynamically_scoped {
		template <dynamically_scoped<T> & ds_var>
		friend class rebind<T, ds_var>;

		T current_value;
	public:
		dynamically_scoped<T>& operator = (const T & x) {
			current_value = x;
			return *this;
		}
		operator T& () {
			return current_value;
		}
	};

	template <class T, dynamically_scoped<T> & ds_var>
	class rebind {
		T old_value;
	public:
		rebind() {
			old_value = ds_var.current_value;
		}
		~rebind() {
			ds_var.current_value = old_value;
		}
	private:
		// prevent copying
		rebind(const rebind<T, ds_var>&);
		void operator =(const rebind<T, ds_var>&);
	};

>Block entry:
>	for each dynamic variable x
>	    push contents of x onto Trail
>	push block descriptor onto Trail
>
>Block exit:
>	discard block descriptor from Trail
>	for each dynamic variable x in reverse order
>	    pop contents of x from Trail

With the second implementation above, block entry and exit are
in fact slightly cheaper:

  Block entry:
	for each dynamic variable x
	   copy (not push) contents of x onto stack

  Block exit:
	for each dynamic variable x
	   copy (not push) contents of x from stack

I tried a simple test of dynamically_scoped<int>.  My compiler (SGI
C++) generated one instruction to put the address of x in a register,
and then a load/store pair for block entry and a load/store pair for
block exit.

By storing the trail on the stack, you save having to increment the
trail pointer (the stack pointer increment is usually free, since you
normally have to increment it anyway).  You also reduce the danger
of cache collisions, although that's probably not a noticable effect.
Furthermore, unlike say Prolog, you pay the cost of trailing and
untrailing only when you're actually using it (you don't have
any untrail loops).  The downside is that you can't get tail recursion
optimization.

Most modern Unix C++ implementations use separate code address tables for
exception handling, so there's no need to push any descriptors.
(PC implementations are another matter, though -- they do normally
push and pop stuff.  I think that's mostly Microsoft's fault.)

>There are three things to be said about this:
>
>(1) it is hard to see how to do _substantially_ better than this.

Yes, but as shown above you can do slightly better, and in any case all
you really need is to not do substantially worse.

>(2) the exception unwinder uses block descriptors, it is hard to
>    see how such a _global_ mechanism can be efficiently simulated
>    by _local_ classes.

Well, the local C++ classes are making use of the underlying C++
exception handling mechanism, which could use a global block descriptor
stack or separate code address tables or some other global mechanism.

>(3) Lisp systems enforce certain _global_ restrictions on the use
>    of dynamic binding.  fjh's mechanism can simulate to some degree
>    what Lisp _allows_ but not what it _forbids_.

Could you be more specific about the restrictions that Lisp systems
enforce?

You can enforce quite a bit in C++.

>None of this should be taken as endorsing the addition of dynamic binding
>to any specific language.

Yes, and the fact that you *can* implement dynamically scoped variables
in C++ does not mean that you necessarily *should* ;-)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: What is wrong with OO ?

[Charles A. Jolley]

> Well, who am I to judge.. but in my view C++ is basically C with the 
> capability to add functions to structs. Before I tried C++, I would
> bundle pointers to functions in my C-structs to fake some kind of
> OO-like bundling of similar functions ;)   C++ take this a major
> step further by actually bundling data and functions together
> in a struct. But that is what classes are in C++: just enhanced
> structs!

C++ actually does not bundle code with the structs. If a member function
is not virtual, the compiler will just binds a obj.foo() reference to its
obj::foo() counterpart.  On the other hand, if a member function is
virtual, then function pointers, like you mentioned above, are used. 
Anyway, just a minor detail; they're still just glorified structs. ;)

-Charles

-Charles Jolley
cjolley@oz.sunflower.org
-------------------------------
       HACS Design Group
 "...there is a better way..."
-------------------------------

Re: What is wrong with OO ?

[richard]

In <01bc0269$3fd55b20$ca61e426@DCorbit.solutionsiq.com>, "Dann Corbit" <dcorbit@solutionsiq.com> writes:

>I remember hearing similar arguments about PL/1 many years ago.  The line
>of reasoning went something like this, "It is such a complex language, that
>the average programmer can never become proficient in it."  This is, of
>course, pure bologna.  With an advanced language you can be proficient
>right away.  You don't **have** to use the advanced features.  Start with
>the simple things and work forward.  Classes, for instance, are simple. 
>There are some advanced features of classes like whether a member should be
>virtual or pure virtual to create an abstract class.  But you don't need to
>know that to learn the language and actively use it as a productive tool.

I doubt that a lot of people know everything about C++, even when they
have been using it for years. Most programmers don't use a lot of 
features of a language simply because they don't *need* them. What
is interesting for one leaves someone else totally cold.

>And as to why virtual/non-virtual (IMO):
>Something that is virtual can be replaced and/or shared.  If you need these
>capabilities, then make it virtual.  A pure virtual member will cause a
>class to be abstract.  This is valuable if you have a class that is really
>not able to exist as a useful entity until it has been specialized by a
>class that inherits from it (in other words, you don't want to create a
>stand-alone instance of the abstract class).
>

Virtual functions are also a kind of documentation. When declaring a 
function virtual, the programmer is more or less saying "go ahead,
override this function if you like."

Greetz,

RS

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Robert A Duff <bobduff@world.std.com> wrote in article
<E59AsK.5LC@world.std.com>...
> Control constructs *are* part of the standard library in Smalltalk.  And
> it's an elegant way to do things.  I'm not sure what you mean by "*in
> principle*" in this case.
> >(Unless you take Lisp or Scheme and consider macros as part of the
> >library--which, strictly speaking, they are not).
> No, they're not macros, they're "normal" messages/methods (that is,
> procedure calls), with "blocks" as parameters.  (I'm not sure why macros
> are considered out of bounds here, but in any case, macros aren't needed
> in this case.)

Sorry, but the post I replied to discussed Ada and C. Your Smalltalk points
are correct but Smalltalk is unique (again :-).  Unlike most other
"mainstream" languages it provides delayed evaluation ("blocks")--something
without which you *cannot* build control constructs for languages with
applicative-order evaluation, while unlike Scheme and CL's closures the
syntax of blocks is extremely brief. This is why you can build control
constructs as functions without the need for syntactic sugar for usability.

If you disagree with the first statement, try to write "while as a
function" in C or similar language. If you disagree with the second,
imagine a bare-bones Scheme-like system with only "lambda", "define" and
"if": it is *all* you need to have any control construct and write any
program, but it will be unreadable without syntactic abstraction a macro
system gives. (Macros are out of bounds because they extend the compiler,
not the program.)

--Vassili

Re: What is wrong with OO ?

[richard]

In <E3uK9F.CzG@research.att.com>, bs@research.att.com (Bjarne Stroustrup) writes:

>
>Why is any of this relevant now? Why do I bother with this debate on
>"innovation?" Because some of what is said related directly to what C++
>is and should be, and that again affects where it is reasonable to use
>it and how it is best used. If you misunderstand some of the fundamentals
>of a language, the code you write in it is going to be suboptimal in several
>ways.
>	

Well, who am I to judge.. but in my view C++ is basically C with the 
capability to add functions to structs. Before I tried C++, I would
bundle pointers to functions in my C-structs to fake some kind of
OO-like bundling of similar functions ;)   C++ take this a major
step further by actually bundling data and functions together
in a struct. But that is what classes are in C++: just enhanced
structs!

I find that many of the OO-capabilities of C++ are just "crammed in"
to overcome the static nature of the language. C++ is by far not 
elegant in this respect. I get the idea that a lot of features 
have been braught in on the fly ("hey, multiple inhertiance
would be neat. And while we're at it, let's try templates too").

That C++ still works as a OO-language is mostly due to the strengths of
the language C itself... it appears to still work even under the
weirdest circumstances. In that respect Stroustup made an excellent
chouce by using C as a base ;)

Greetz,

RS

Re: What is wrong with OO ?

[Nick Leaton]

richard@highrise.nl wrote:
> 
> Virtual functions are also a kind of documentation. When declaring a
> function virtual, the programmer is more or less saying "go ahead,
> override this function if you like."
> 

The decision to make a function virtual assumes a knowledge of what
users of your class are going to do. It akin to predicting the future.
One of the problems with C++ is this very point. Should you, as a
designer of a class restrict what someone else does with your class?
If you provide the class to someone else without source code, and they
find a bug. One solution to fixing the bug is to produce a new class
that inherits the original, and redefines the offending routine. However
your decision about declaring or not declaring the routine virtual in
the first place affects what can be done.

-- 

Nick

Re: What is wrong with OO ?

[Robert Dewar]

RS says

<<I doubt that a lot of people know everything about C++, even when they
have been using it for years. Most programmers don't use a lot of
features of a language simply because they don't *need* them. What
is interesting for one leaves someone else totally cold.>>

Indeed, and in practice it seems that a lot of "C++" programmers know
little more than the C subset with a very minimum of additional features.
However, I think this is probably best ascribed to ignorance rather than
careful consideration of what people find interesting!

Re: What is wrong with OO ?

[Vlastimil Adamovsky]

richard@highrise.nl wrote:

>................................. but in my view C++ is basically C with the 
>capability to add functions to structs. Before I tried C++, I would
>bundle pointers to functions in my C-structs to fake some kind of
>OO-like bundling of similar functions ;)   C++ take this a major
>step further by actually bundling data and functions together
>in a struct. But that is what classes are in C++: just enhanced
>structs!

Whow! Then you really don't need C++. Use C instead. 
There is nothing keeping you from using member functions in C structures.
It is completely legal.

>I find that many of the OO-capabilities of C++ are just "crammed in"
>to overcome the static nature of the language. C++ is by far not 
>elegant in this respect. I get the idea that a lot of features 
>have been braught in on the fly ("hey, multiple inhertiance
>would be neat. And while we're at it, let's try templates too").

Multiple inheritance is great. Templates are very useful in generic programming.

>That C++ still works as a OO-language is mostly due to the strengths of
>the language C itself... it appears to still work even under the
>weirdest circumstances. In that respect Stroustup made an excellent
>chouce by using C as a base ;)

It was a smart choice.











 Vlastimil Adamovsky
 ** C++ and Smalltalk consultant **
 * http://www.stepweb.com *

Re: Worse is better, was: Language marketing question

[Bob Haugen]

Piercarlo Grandi wrote:

> Richard Gabriel has written a classic "Worse is Better" paper on all
> this, which discusses some of the issues (even if I really disagree with
> some of the analysis and most importantly with the recommendations).

I recently read and am currently thinking about that same paper, and 
so would be interested in your disagreements.

Bob Haugen
Nexgen Software

Re: Worse is better, was: Language marketing question

[Donald M. MacQueen]

Bob Haugen wrote:
> 
> Piercarlo Grandi wrote:
> 
> > Richard Gabriel has written a classic "Worse is Better" paper on all
> > this, which discusses some of the issues (even if I really disagree with
> > some of the analysis and most importantly with the recommendations).
> 
> I recently read and am currently thinking about that same paper, and
> so would be interested in your disagreements.
> 
> Bob Haugen
> Nexgen Software




Is this paper available on the Web?

I'd like to read it too.

Thanks in advance.



Donald

Re: What is wrong with OO ?

[Robert Dewar]

Charles said

<<C++ actually does not bundle code with the structs. If a member function
is not virtual, the compiler will just binds a obj.foo() reference to its
obj::foo() counterpart.  On the other hand, if a member function is
virtual, then function pointers, like you mentioned above, are used.
Anyway, just a minor detail; they're still just glorified structs. ;)>>

YOu should better say "typical C++ implementations" rather than C++, I see
nothing in the draft standard that would support your claim that this is
implied by the language definition.

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Vassili Bykov]

Fergus Henderson <fjh@murlibobo.cs.mu.OZ.AU> wrote:
> ...   On the
> other hand, it's not possible to do the equivalent for Pascal's
> write statement or for C's for loops, because these are part of
> the language proper, not the standard library.

Of course it's not possible.  So we came to what it started with: it is in
principle impossible to have, for example, "for" loop in the standard
library instead of the language proper in a C/Pascal/Ada/Java-like language
even if it were up to us to move it there, because these languages lack the
necessary expressive facilities.  It is possible in Smalltalk, CL, or
Scheme--even Tcl weird as it is.
[But I'm not going into a second round on that, SICP explains it all]

Re: Worse is better, was: Language marketing question

[Lee Willis]

Donald M. MacQueen wrote:
> Bob Haugen wrote:
> > Piercarlo Grandi wrote:
> > > Richard Gabriel has written a classic "Worse is Better" paper on all
> > > this, which discusses some of the issues (even if I really disagree with
> > > some of the analysis and most importantly with the recommendations).

> Is this paper available on the Web?

http://rembrandt.erols.com/mon/SoftwareEngineering/WorseIsBetter.html

-- 
Lee Willis	MultiGen Inc. 550 S Winchester Blvd. Suite 500
		San Jose, CA 95128 		(408) 261-4100
"Sure, everyone knows [software] reusability is wonderful for the 
consumer side of the reuse transaction.  But what makes it wonderful 
for the producers?"  -- Brad Cox, _Superdistribution_

Re: C++ Class

[William Ying]

Loc Minh Phan Van wrote:
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.

Two solutions:
1)	Make the base class as Abstract Base Class (or Absolute Base Class in
some books) by setting a virtual function to be zero.  It is well
documented in any C++ books.
2)	Put the base class constructors in protected field.

- Bill -

Re: C++ Class

[Aaron J Margosis]

Make it an abstract class, using pure virtual functions.


Loc Minh Phan Van wrote:
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.

-- Aaron

---------------------------------
Aaron J Margosis
Work e-mail:  margosis@lccinc.com
Work phone:  703-516-6727
Personal:  Aaron_Margosis@compuserve.com

Re: Exceptions as objects (was Re: What is wrong with OO ?)

[Piercarlo Grandi]

>>> "jsarkela" == John W Sarkela <jsarkela@enfish.com> writes:

[ ... much omitted ... ]

jsarkela> My experience suggests that my designs have higher degrees of
jsarkela> reusability if I do indeed consider that objects may express
jsarkela> free will. You may consider this fuzzy thinking, yet I tend to
jsarkela> create more concise collaborations with better factoring of
jsarkela> responsibility if I do think of my objects as expressing an
jsarkela> individual will and as a locus of responsibility.

Well, ain't you lucky? :-)

[ ... much omitted ... ]

Re: C++ Class

[Ron Smith]

Please watch your crossposting.  I don't know why this is in any of the
newsgroups except comp.lang.c++.

I didn't bring my asbesteos underwear so please don't flame me for
pointing this out.

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Re: C++ Class

[John Kapson [C]]

In article <33018394.1718@scf.usc.edu>, Loc Minh Phan Van <locphan@scf.usc.edu> writes:
> Hi,
> 	Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class. 
> 
> 	If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Shame, shame, shame.  If you want me to do your homework,
you'll have to pay my hourly rate.  8-)

John

Re: C++ Class

[Vlastimil Adamovsky]

Keith P. Boruff wrote:
> 
> Loc Minh Phan Van wrote:
> >
> > Hi,
> >         Is there anyway that we can Define a class that can not be instantiated
> > in any way by the user (that is, you can not have objects of that type),
> > but it can be used as a base class.
> >
> 
> Read about polymorphism and virtual functions.
> 

Read about "Abstract classes" and pure virtual functions.

Vlastimil Adamovsky


       The contents of this message express only the sender's opinion.
       This message does not necessarily reflect the policy or views of
       my employer, Merck & Co., Inc.  All responsibility for the statements
       made in this Usenet posting resides solely and completely with the
       sender.

Re: C++ Class

[Jason Shankel]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

In C++, you're talking about an abstract base class.
An abstract class in C++ is a class which has at least one
pure virtual function, which must be overridden by a child class.
Pure virtual functions are designated by the "=0" idiom.
Abstract base classes cannot be instantiated:


class IFoo
{
	public:
		virtual void Method() = 0; //Pure virtual function
};

class CFoo : public IFoo
{
	public:
		virtual void Method(){}; //Overridden
};

void main()
{
	IFoo *object;

	object = new IFoo(); //ERROR, cannot instantiate abstract class
	object = new CFoo(); //Legal
};

C++ Class

[Loc Minh Phan Van]

Hi,
	Is there anyway that we can Define a class that can not be instantiated
in any way by the user (that is, you can not have objects of that type),
but it can be used as a base class. 

	If so please give me a little example.

Thanks

Fr, Loc Phan

Re: C++ Class

[Keith P. Boruff]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

Read about polymorphism and virtual functions. 
 
--------------------------------------------------------
Keith P. Boruff			Email:
West Babylon			kboruff@village.ios.com
Long Island, NY			boruffk@sunysuffolk.edu

Re: C++ Class

[Kevin J. Hopps]

Loc Minh Phan Van wrote:
> 
> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.
> 
> Thanks
> 
> Fr, Loc Phan

If a class has a "pure virtual function" it cannot be instantiated
directly, but only as a base class of a derivative that implements the
function.  For example:

class Cloneable
{
public:
	virtual Cloneable* clone() = 0;
};

class Thing : public Cloneable
{
public:
	virtual Thing* clone();
};

int main()
{
	Cloneable c;	// error
	Thing t;	// ok
	return 0;
}
-- 
Kevin J. Hopps, Imation          kjhopps@imation.com

My opinions are my own.  I speak neither for Imation nor 3M.



Opinions expressed herein are my own and may not represent those of my employer.

Re: C++ Class

[Kent Tong]

Loc Minh Phan Van <locphan@scf.usc.edu> wrote:

>Hi,
>	Is there anyway that we can Define a class that can not be instantiated
>in any way by the user (that is, you can not have objects of that type),
>but it can be used as a base class. 
>
>	If so please give me a little example.

deferred class Foo
feature
   IWillNeverCrossPostAgain 
   is 
      deferred 
   end;   


---
Kent Tong
v3 is out!!!
Freeman Installer ==> http://www.netnet.net/users/freeman/

Re: C++ Class

[Paul Kenneth Egell-Johnsen]

Loc Minh Phan Van wrote:

> Hi,
>         Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class.
> 
>         If so please give me a little example.

That would be an abstract base class, with pure virtual members.

class base
{
	virtual method() = 0; // this is not defined in the base,
                              // derived objects must define this.
                              // Don't think a user can instanciate
                              // this, take a look in the faq.
}

Paul K Egell-Johnsen

mailto:paulken4@afrodite.hibu.no
http://afrodite.hibu.no:8001/paulken4/

Re: C++ Class

[Lee, Shih Hao]

Loc Minh Phan Van <locphan@scf.usc.edu> wrote in article
<33018394.1718@scf.usc.edu>...
> Hi,
> 	Is there anyway that we can Define a class that can not be instantiated
> in any way by the user (that is, you can not have objects of that type),
> but it can be used as a base class. 
> 

Declare the constructor of that class to be protected.

class B {
protected:
	B() { /*...*/}
};

class D : public B {
public:
	D() : B() { /*...*/}
};

main()
{
	D d;		// OK!
	B b;		// Error!
}

tony
-- 
class Signature { static char *name, *belief, *URL, *eMail; };
char *Signature::name = "Lee, Shih Hao (Anthony Lee)";
char *Signature::belief = "Long live of Borland C++/OWL";
char *Signature::URL = "http://necta.nec.com.tw/~tony";
char *Signature::eMail = "mailto:tony@necta.nec.com.tw";

Re: language marketing question, was Re: What is wrong with OO ?

[Robert Dewar]

John said

<<Hmm.  Its more likely that the majority of people who do doctorates stay in
academia, rather than joining the corporate rat-race.  The latter offers
better money.>>

Why guess at something like this and, not surprisingly guess wrong. It is
certainly NOT the case that the majority of people who do doctorates stay
in academia!

Re: What is wrong with OO ?

[Piercarlo Grandi]

>>> "cjolley" == Charles A Jolley <cjolley@oz.sunflower.org> writes:

>> Well, who am I to judge.. but in my view C++ is basically C with the 
>> capability to add functions to structs. Before I tried C++, I would
>> bundle pointers to functions in my C-structs to fake some kind of
>> OO-like bundling of similar functions ;)   C++ take this a major
>> step further by actually bundling data and functions together
>> in a struct. But that is what classes are in C++: just enhanced
>> structs!

cjolley> C++ actually does not bundle code with the structs. If a member
cjolley> function is not virtual, the compiler will just binds a
cjolley> obj.foo() reference to its obj::foo() counterpart.  On the
cjolley> other hand, if a member function is virtual, then function
cjolley> pointers, like you mentioned above, are used.  Anyway, just a
cjolley> minor detail; they're still just glorified structs. ;)

But this is an implementation detail, and even in the implementation
vtables of function pointers are not part of any instance of any
'struct'.

In ``C++'' in no way data and functions are bundled together; the only
bundling is of function declarations/definitions with data
declarations/definitions. There is an immense amount of difference
between:

  struct complex
  {
    float re,im;
    struct complex (*add)(struct complex,struct complex);
    ....
  };

  struct complex c = { .... };
  c = (*c.add)(c,c);

which is reminiscent of prototype systems and:

  class complex
  {
    float re,im;
  public:
    complex add(complex);
    ....
  };

  complex complex::add(complex b) { ... };

  complex c(....);
  c = c.add(c);

which isn't.

The difference is that in ``C++'' a 'class'/'struct' definition also
doubles up as a module, which contains the definition of a single
'struct' and of a bunch of related functions. In fact a ``C++'' 'class'
can be used as a mere module if it does not contains any data member
definitions. The above ``C++'' example should really be read as:

  class complex
  {
    struct complex { float re,im; };
  public:
    complex add(complex,complex);
    ....
  };

  complex::complex complex::add(complex::complex a,b) { ... };

  complex::complex c(....);
  c = complex::add(c,c);

If ``C++'' were based on the latter syntax scheme, admittedly more
verbose, fewer people would get the wrong impression that there is
anything magic/special about the affix syntax and the other syntactic
shortcuts. Too bad.

Naturally the same observation applies to the other languages with
similar syntax, like ``Smalltalk'' and ``Eiffel''; in all of these the
affix syntax and the syntactic conflation of the type definition with
that of the module can result in confusion, which is made worse in the
case of ``Smalltalk'' by the use of actor-like terms... In Ada 95 the
more verbose but clearer syntax is required, but then the compiler is
not requried to support or enforce the OO paradigm, and allows more than
one type definition in a module regardless (also in ``C++'', but only if
one uses the more verbose syntax).

Re: What is wrong with OO ?

[Sam Inala]

Robert Dewar <dewar@merv.cs.nyu.edu> wrote in article
<dewar.855671030@merv>...
> Charles said
> <<C++ actually does not bundle code with the structs. If a member
function
> is not virtual, the compiler will just binds a obj.foo() reference to its
> obj::foo() counterpart.  On the other hand, if a member function is
> virtual, then function pointers, like you mentioned above, are used.
> Anyway, just a minor detail; they're still just glorified structs. ;)>>
> 
> YOu should better say "typical C++ implementations" rather than C++, I
see
> nothing in the draft standard that would support your claim that this is
> implied by the language definition.

Just for clarification: even typical C++ implementations differ from
structs
containing function pointers. Consider the following:

#include <stdio.h>

struct One {
   int x;
};

struct Two {
   int x;
   void foo() {}
};

struct Three {
   int x;
   virtual void foo() {}
};

struct Four {
   int x;
   virtual void foo() {}
   virtual void bar() {}
};

int
main() {
   printf( "sizes = %d %d %d %d\n", sizeof( One ), sizeof( Two ),
	sizeof( Three ), sizeof( Four ) );
   return 0;
}

Output from gcc:
sizes = 4 4 8 8

With an implementation of class Four like this:

struct Four {
	int x;
	void (*foo)();
	void (*bar)();
};

...we would expect the sizeof( Four ) to be 12. Instead, it most
likely contains a single pointer to a table of function pointers,
which are shared by all the instances of the class:

struct Four {
	void* vtbl;
	int x;
};

<return type> (*Four::function[ cMethods ])(...);

I only mention this because I perceive people thinking
that object instances carry around their own virtual 
function tables.

Re: What is wrong with OO ?

[Robert Dewar]

Sam said

<<...we would expect the sizeof( Four ) to be 12. Instead, it most
likely contains a single pointer to a table of function pointers,
which are shared by all the instances of the class:>>

I don't know who "we" is here, but I can't see anyone expecting this,
your "instead" is the obvious implementation, and it would surprise
me (though certainly not be invalid) if a C++ implementation did
anything else!

Re: What is wrong with OO ?

[Nick Leaton]

> Nick Leaton wrote:
> >
> > richard@highrise.nl wrote:
> > >
> > > Virtual functions are also a kind of documentation. When declaring a
> > > function virtual, the programmer is more or less saying "go ahead,
> > > override this function if you like."
> >
> > The decision to make a function virtual assumes a knowledge of what
> > users of your class are going to do. It akin to predicting the future.
> 
> No. If it make sense to override, make it virtual; if it doesn't,
> don't make it virtual.

I think you might have missed the start of the thread. If you buy third
party libraries, you don't always get source. With no source, you cannot
make the function virtual.

-- 

Nick

Re: What is wrong with OO ?

[Nick Leaton]

Valentin Bonnard wrote:
> 
> Nick Leaton wrote:
> >
> > richard@highrise.nl wrote:
> > >
> > > Virtual functions are also a kind of documentation. When declaring a
> > > function virtual, the programmer is more or less saying "go ahead,
> > > override this function if you like."
> >
> > The decision to make a function virtual assumes a knowledge of what
> > users of your class are going to do. It akin to predicting the future.
> 
> No. If it make sense to override, make it virtual; if it doesn't,
> don't make it virtual.

If you can forsee the future!

> > One of the problems with C++ is this very point. Should you, as a
> > designer of a class restrict what someone else does with your class?
> 
> Yes; even the fact that you have private members restrict what
> can be done with your class; does it mean that you should
> only use public data members (ie expose all your implementation
> details) ?

We are only talking about classes that inherit, not classes that
use. Why shouldn't a class that inherits another get access to 
implementation details?

> > If you provide the class to someone else without source code, and they
> > find a bug. One solution to fixing the bug is to produce a new class
> > that inherits the original, and redefines the offending routine. However
> > your decision about declaring or not declaring the routine virtual in
> > the first place affects what can be done.
> 
> You don't inherit from a class to fix it in C++ (nor to reuse it);
> you specialize it. You don't patch a class like you apply a diff
> file to a system to patch it !

OK, Microsoft release a duff library with a duff class. You
have no source. Will Microsoft give you the source? No. You
have to inherit and overide. It is ugly, it is not ideal, but 
you have no choice.

> [For Mac programmers: overriding != SetTrapAddress]
> 
> One must never forget that inheritance is not the only way to
> use a class; composition is often the only sensible way.
> 
> If there is a bug in one member function in a class, then if
> you don't have the source code it's difficult to be sure
> that the cause of this bug (or a similar bug) is not in
> another function.
> 
> Even if you are sure that you only need to correct one
> function, public [normal] inherintance is not the way to go.
> 
> You might use private inheritance and redefine the buggy
> function:
> 
> class BuggyClass {
> public:
>     void BuggyFunction (); // need not to be virtual
>     void OtherFunction ();
> };
> 
> class CorrectedClass : private BuggyClass {
> public:
>     void BuggyFunction ();
>     using OtherFunction;
> };
> 
> void CorrectedClass::BuggyFunction ()
> {
>     // corrected function
> }

It won't work. A user that has a pointer to a BuggyClass, which
is an instance of CorrectedClass. The user calls ptr->BuggyFunction()
The buggy code will be run, not the CorrectedClass::BuggyFunction.
However if BuggyFunction is declared as virtual, it will work.

> With private inheritance it's not possible (except for
> CorrectedClass members) to convert a CorrectedClass to
> a BuggyClass; it means that only CorrectedClass know that
> CorrectedClass IS-A BuggyClass.
> 
> You can also use composition by reimplementing all the
> functions of BuggyClass; all these implementation just
> call the corresponding function in BuggyClass; only
> BuggyFunction is really rewritten.

This won't work. The corrected class will not inherit BuggyClass,
and so cannot be reffered to using a pointer to its base class.

> And anyway I feel that's a very special case. You
> should ask the BuggyClass writer to correct its class.

Agreed. But you have to be realistic. Lets say Microsoft release some
buggy code. Nothing suprising there. How long are you prepared to
wait for them to fix the code?


> Valentin Bonnard
> mailto:bonnardv@pratique.fr
> http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)

-- 

Nick

Re: What is wrong with OO ?

[Fergus Henderson]

Nick Leaton <nickle@calfp.co.uk> writes:

>Valentin Bonnard wrote:
>> 
>> Nick Leaton wrote:
>> >
>> > richard@highrise.nl wrote:
>> > >
>> > > Virtual functions are also a kind of documentation. When declaring a
>> > > function virtual, the programmer is more or less saying "go ahead,
>> > > override this function if you like."
>> >
>> > The decision to make a function virtual assumes a knowledge of what
>> > users of your class are going to do. It akin to predicting the future.
>> 
>> No. If it make sense to override, make it virtual; if it doesn't,
>> don't make it virtual.
>
>If you can forsee the future!

It's not about forseeing the future, it's about programming by contract
and making appropriate design decisions.

>We are only talking about classes that inherit, not classes that
>use. Why shouldn't a class that inherits another get access to 
>implementation details?

Because those implementation details may change!

>OK, Microsoft release a duff library with a duff class. You
>have no source. Will Microsoft give you the source? No. You
>have to inherit and overide. It is ugly, it is not ideal, but 
>you have no choice.

That is a perfect example of why you should *not* do this,
because if you do, then Microsoft will screw you when they
release the next version.  In the next version, they will
have declared what you thought was a bug to be a feature,
and they will have lots of code that depends on it.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: C++ Class [ not a good answer ]

[Luis Espinal]

> Read about polymorphism and virtual functions.
> 

This is a better answer to the original question.

Lock Minh, what you need is a class that has at least one pure virtual 
function in it. That way, nobody can instantiate an object from it and
still use it as a base class.
.ie.

class MyBase
{
	MyBase(){...}
	virtual ~MyBase(){ ... }
	virtual void SomeFunction() = 0; // a pure virtual function.
};

// you still need to implement the pure virtual func.
void MyBase::SomeFunction(){}

class AChild : public MyBase
{
	... here goes the constructors, destructors, etc.
	// you need to implement the pure virtual function
	// defined in MyBase; otherwise, you won't be 
	// able to instantiate a AChild object either.
	virtual void SomeFunction();
};

void AChild::SomeFunction()
{
// some code in here.
}

AChild someChild; // ok...

MyBase someBase; // eeek! can't compile.
		 // can't instantiate a class with 
		 // a pure virtual function in it.

Hope it helps.

Luis Espinal

p.s. cryptic answers don't help.
-- 
Luis++ lespin03@solix.fiu.edu
What does not kill us, makes us stronger...
What does not break us, makes us...
That which does not break, must bend...

Re: C++ Class [ not a good answer ]

[Tom Plunket]

On Mon, 03 Mar 1997 13:42:16 -0500, Luis Espinal
<lespin03@solix.fiu.edu> wrote:

> Lock Minh, what you need is a class that has at least one pure virtual 
> function in it. That way, nobody can instantiate an object from it and
> still use it as a base class.
> .ie.
> 
> class MyBase
> {
> 	MyBase(){...}
> 	virtual ~MyBase(){ ... }
> 	virtual void SomeFunction() = 0; // a pure virtual function.
> };
> 
> // you still need to implement the pure virtual func.
> void MyBase::SomeFunction(){}

Can't you just create a pure-virtual class, that doesn't
have pure-virtual member functions (if indeed you don't want
that)?  I thought that that was what class ios did.
Something along the lines of:

class CSomeVirtual
{
    CSomeVirtual();
    ~CSomeVirtual();

    MemberFunction();
    AnotherMemberFunc();
} = 0;

???

Then you're forced to derive from it, but everything is
implemented, too.

-Tom