For example, you only get a virtual function pointer in a class if the class actually has any virtual functions in it.

Christophe de Dinechin wrote in message <3B7C90A8.DF87D385@earthlink.net>...
> 9/ Object oriented gradualism
>
>I just have no idea what you mean by that :-)
>
>
>Christophe
>

Christophe de Dinechin wrote in message <3B7C8E79.109F4270@earthlink.net>...
>There was one
>major difference between Ada and C++: implicit instantiation. In Ada or
>Eiffel, you have to explicitly instantiate everything. This basically makes
>the STL impossible to implement.


I like the explicit instantiation. Since there is an STL workalike for Ada, which I haven't looked at, somebody must have dealt with this problem.

Walter wrote:
> Christophe de Dinechin wrote in message <3B7C8E79.109F4270@earthlink.net>...
> 
>...
> 
> I like the explicit instantiation. Since there is an STL workalike for Ada,
> which I haven't looked at, somebody must have dealt with this problem.
> 
But in an earlier thread it was claimed that STL for Ada was 10 times as large as the equivalent STL for C++.  So the dealing with it may not have been easy.

"Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B851445.6010005@earthlink.net...
> Walter wrote:
> > Christophe de Dinechin wrote in message
<3B7C8E79.109F4270@earthlink.net>...
> >
> >...
> >
> > I like the explicit instantiation. Since there is an STL workalike for
Ada,
> > which I haven't looked at, somebody must have dealt with this problem.
> >
> But in an earlier thread it was claimed that STL for Ada was 10 times as large as the equivalent STL for C++.  So the dealing with it may not have been easy.

Large in source or large in object?

Walter wrote:
> 
> "Charles Hixson" <charleshixsn@earthlink.net> wrote in message news:3B851445.6010005@earthlink.net...
> > But in an earlier thread it was claimed that STL for Ada was 10 times as large as the equivalent STL for C++.  So the dealing with it may not have been easy.
> 
> Large in source or large in object?

Source.

"Rational ships a C++ version of The Booch Components that was
originally designed for and implemented in Ada by Grady Booch. ...
The Ada version is 125,000 non-commented source lines compared
to the C++ version's 10,000 lines -- inheritance combined with
templates can be a very powerful mechanism for organizing
libraries without loss of performance or clarity."

   -Stroustrup in D&EoC++, citing Booch's _Object Oriented
Analysis and Design with Applications, 2nd edition"

-RB

Russell Bornschlegel wrote:
> 
> Walter wrote:
> 
>>"Charles Hixson" <charleshixsn@earthlink.net> wrote in message
>>news:3B851445.6010005@earthlink.net...
>>
>>>But in an earlier thread it was claimed that STL for Ada was 10 times as
>>>large as the equivalent STL for C++.  So the dealing with it may not
>>>have been easy.
>>>
>>Large in source or large in object?
>>
> 
> Source.
> 
> "Rational ships a C++ version of The Booch Components that was originally designed for and implemented in Ada by Grady Booch. ... The Ada version is 125,000 non-commented source lines compared
> to the C++ version's 10,000 lines -- inheritance combined with templates can be a very powerful mechanism for organizing libraries without loss of performance or clarity."
> 
>    -Stroustrup in D&EoC++, citing Booch's _Object Oriented Analysis and Design with Applications, 2nd edition"
> 
> -RB
> 

But I think that Eiffel generics give an equivalent amount of compression.  And they are certainly easier to learn and to use.
Thus:
Tree[L->Comparable]   -- L is an arbitrary choice,
                      -- Comparable is a class defined elsewhere
...                   -- every time this class is instantiated, it
                      -- must have a class that implements Comparable
feature
  root      :  TreeNode[L];  -- all class references are pointers
  sentinal  :  TreeNode[L];  -- or handles, no pointer notation
...                          -- needed(or even available);
end;

If you want to specify a non-handle/pointer class, you define it in the class type as an "expanded" class.  If you want an abstract class, you define it in the class type as a "deferred" class.

Then when you want to create an instance of a Tree, you say something like:
    thisTree  :  Tree[String];
and the tree will be ordered in the same way that String is ordered.

Sometimes I find this a bit confining, but it is easy to learn, and seems to do the job.  Since everything is done via a reference, sizes are known at compile time.  (Expanded classes are special here, of course, but they also have special limitations that allow them to be handled easily.)

OTOH, for basic stuff, and for tricky stuff, the class library implementors all fall back into C.  Not that bad an idea, but it means that C interoperability should have been a higher priority on the language designer's list of features.  As it was, this is always tacked on later.  And shows it.

Charles Hixson wrote in message <3B856897.6050907@earthlink.net>...
>OTOH, for basic stuff, and for tricky stuff, the class library implementors all fall back into C.  Not that bad an idea, but it means that C interoperability should have been a higher priority on the language designer's list of features.  As it was, this is always tacked on later.  And shows it.


This sounds like a serious problem with Eiffel.

Walter wrote:
> Charles Hixson wrote in message <3B856897.6050907@earthlink.net>...
> 
>>OTOH, for basic stuff, and for tricky stuff, the class library
>>implementors all fall back into C.  Not that bad an idea, but it means
>>that C interoperability should have been a higher priority on the
>>language designer's list of features.  As it was, this is always tacked
>>on later.  And shows it.
> 
> This sounds like a serious problem with Eiffel.
> 
This is a problem.  As to serious... well, that sort of depends on what you're doing.  Also, this is implementation specific (i.e., not a part of the language specifications), so it's quite possible that some implementations have done it better than the ones that I'm more familiar with.  And usually one doesn't need to go there.  But it is a problem. And sometimes it can be serious (though not grave, just exceptionally irritating, and requiring lots of extra care to get everything just right).

Making it a separate tool means people won't use it. -Walter

The HTML thing is an experiment. I think some really cool editors can be built using it.

Christophe de Dinechin wrote in message <3B7C9A6E.718B32AF@earthlink.net>...
>34/ HTML compilation
>
>Ah, I see, you discarded the C preprocessor to replace it with an HTML preprocessor. So #include is being replaced with <A REF="http://....">. That's a clever trick.
>
>Seriously, I think this is a cute idea, but it has nothing to do with D. It is really a preprocessor that extracts source from HTML files, and that ought to be a separate tool...
>
>
>
>Christophe
>

Christophe de Dinechin wrote in message <3B7C9971.8294C753@earthlink.net>...
> To Walter: that's largely
>because it makes the control flow much more complex, everything now connects to the finally, and the compiler must really take multiple exit pathes into consideration.


It's actually not that bad in practice. Remember that C++ has "finally" clauses too, it's just that they are hidden (implicitly generated by the compiler). The compiler builds finally clauses for each stack allocated object that has a destructor.

I never much liked the hidden bloat generated by that. It's a major reason why D has no stack allocated class objects, and "finally" clauses are explicit.