It says in the comparison page that D doesn't have multiple inheritance. This is
one of the most usefull and timesaving thing in the way I program C++. All the
other stuff about D sound very good, and if the multiple inheritance would be a
reality in D, I might consider using it for my apps.
Otherwise I have to congratulate you on your courage on making your own
language. I like this kind of attitude, that when something isn't perfect and
you can't change it, create the perfect thing on your own!

> It says in the comparison page that D doesn't have multiple inheritance.

It does not

> This is one of the most usefull and timesaving thing in the way I program
C++.

It depends what you use it for. Multiple inheritance of implementation is evil, and has fallen very much out of favour with the C++ community over the last decade. D does not, and will not, support that.

However, modern template practices have revived the use for MI, in so far as being able to apply tag inheritance to existing types via bolt-in templates. D doesn't properly support this at the moment, though I have no doubt that it will.

>All the
> other stuff about D sound very good, and if the multiple inheritance would
be a
> reality in D, I might consider using it for my apps.

You should consider it anyway, as there are some really superb modules in the standard library. ;)

> Otherwise I have to congratulate you on your courage on making your own language. I like this kind of attitude, that when something isn't perfect
and
> you can't change it, create the perfect thing on your own!

Congratulations are mainly due Walter, but pretty much everyone on this NG has helped in one way or another.

Hopefully you'll stick around!

Cheers

Matthew

satelliittipupu wrote:

>It says in the comparison page that D doesn't have multiple inheritance. This is
>one of the most usefull and timesaving thing in the way I program C++. All the
>other stuff about D sound very good, and if the multiple inheritance would be a
>reality in D, I might consider using it for my apps.
>Otherwise I have to congratulate you on your courage on making your own
>language. I like this kind of attitude, that when something isn't perfect and
>you can't change it, create the perfect thing on your own!
>
>
>  
>
Please provide an example where you need MI.
How many C++ programs do you know use MI?

D does provide a form of MI though the use of interfaces.

IMHO MI causes more problems then it solves.

-- 
-Anderson: http://badmama.com.au/~anderson/

Heh. Please provide an example where MI causes problems.
:)

Zed wrote:

>Heh. Please provide an example where MI causes problems.
>:)
>  
>
I'll give a quote from: "concepts of programming languages" (5th ed), Robert W. Sebesta. p. 466-467.

"Because multiple inheritance is sometimes very useful, why would a language designer not include it?  The reasons fall into two categories: complexity and efficiency. The additional complexity is illustrated by several problems. One obvious problem is name collisions. For example, if a sub class named C inherits from both class A and class B and both B and both A and B include an inheritable variable named sum, how can C refer to the two different sums?" ... (the obvious answer is namespacing) ... "A variation of this occurs if both A and B are derived form a common parent, Z, in which case it is called diamond inheritance".  ...

"The question of efficiency may be more perceived then in real. In C++, for example supporting multiple inheritance requires just one extra additional operation for each dynamically bound method call (Stroustrup, 1994, p. 270). Although this is required even if the program does not use multiple inheritance, it is a small additional cost".

At the risk of copying to much form this chapter "single and multiple inheritance", I'll summarise the rest.
- MI can lead to complex programs
- MI can hinders maintenance.
- Benefits not worth the effort.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson wrote:

> Zed wrote:
>
>> Heh. Please provide an example where MI causes problems.
>> :)
>
> I'll give a quote from: "concepts of programming languages" (5th ed), Robert W. Sebesta. p. 466-467.
>
> "Because multiple inheritance is sometimes very useful, why would a language designer not include it?  The reasons fall into two categories: complexity and efficiency. The additional complexity is illustrated by several problems. One obvious problem is name collisions. For example, if a sub class named C inherits from both class A and class B and both B and both A and B include an inheritable variable named sum, how can C refer to the two different sums?" ... (the obvious answer is namespacing but that has its own set of problems) ... "A variation of this occurs if both A and B are derived form a common parent, Z, in which case it is called diamond inheritance".  ...
>
> "The question of efficiency may be more perceived then in real. In C++, for example supporting multiple inheritance requires just one extra additional operation for each dynamically bound method call (Stroustrup, 1994, p. 270). Although this is required even if the program does not use multiple inheritance, it is a small additional cost".
>
> At the risk of copying to much form this chapter "single and multiple inheritance", I'll summarise the rest.
> - MI can lead to complex programs
> - MI can hinders maintenance.
> - Benefits not worth the effort.
>
That should be:  Benefits may not worth the effort.

This is all very opinionative stuff, where there is no right answer, only good ones -> and the book hints at that.

-- 
-Anderson: http://badmama.com.au/~anderson/

Matthew wrote:

>However, modern template practices have revived the use for MI, in so far as
>being able to apply tag inheritance to existing types via bolt-in templates.
>D doesn't properly support this at the moment, though I have no doubt that
>it will.
>  
>
What is tag inheritance?
What are bolt-in templates?

Just out of interest could you give an example?

-- 
-Anderson: http://badmama.com.au/~anderson/

> Matthew wrote:
> 
> >However, modern template practices have revived the use for MI, in so far as being able to apply tag inheritance to existing types via bolt-in templates. D doesn't properly support this at the moment, though I have no doubt that it will.
> > 
> >
> What is tag inheritance?

    template< typename S
            , typename T = sequence_range_traits<S, is_const<S>::value>
            >
    class sequence_range
      : public iterable_range_tag // <== ** this is the tag **
    {
    public:
      . . .

The tag identifies the range type, which is used in the range algorithms for selecting the most efficient algorithms.

The tags look like the following:

    struct simple_range_tag
    {};

    struct iterable_range_tag
      : public simple_range_tag
    {};

    struct noninterruptible_range_tag
    {};


[This is an extract from the STLSoft implementation of the Range concept, which I'm working on with John Torjo. Ranges will also likely feature large in DTL, although at the moment I've only got so far as doing the basic list, map, queue, set, stack and vector class implementations, and exchanging vague ponderings with big-W. As soon as he gets back from SDWest I expect to see a rapid movement

> What are bolt-in templates?

From [Wils04]:



Definition: Bolt-ins

Bolt-ins are template classes with the following characteristics:

1. They derive, usually publicly, from their primary parameterising type.

2. They accommodate the polymorphic nature of their primary parameterising type. Usually they also adhere to the nature, but this is not always the case, and they may define virtual methods of their own, in addition to overriding those defined by the primary parameterising type.

3. They may increase the footprint of the primary parameterising type by the definition of member variables, virtual functions and additional inheritance from non-empty types.



> 
> Just out of interest could you give an example?

Classic examples are to be found in ATL, whereby several separate template classes may provide bolt-in behaviour, i.e. CComObject<>, CComObjectStack<>, etc.


A (really stupid) simple example (in C++):

class NumSequence
{
public:
  void PresentCalculation(ostream &os, int maxValue)
  {
    vector<int> things(this->CalcThings(maxValue));

    copy(things.begin(), things.end(), ostream_iterator<int>(os));
  }

protected:
  virtual vector<int> CalcThings(int maxValue) = 0;
};

template<typename S>
class FibonacciSequence
{
protected:
  virtual vector<int> CalcThings(int maxValue)
  {
    . . . calculate a Fibonacci sequence up to maxValue, and return in vector<int>
  }
};

template<typename S>
class PrimeSequence
{
protected:
  virtual vector<int> CalcThings(int maxValue)
  {
    . . . calculate a prime number sequence up to maxValue, and return in vector<int>
  }
};


int main()
{
  FibonacciSequence<NumSequence> ps().PresentCalculation(cout);
  PrimeSequence<NumSequence> ps().PresentCalculation(cout);
  return 0;
}

I'll leave it to all your great minds to figure out the amazing real-world benefits of this technique, rather than just my weak example.

In [Wils04], the sections in the Bolt-ins chapter are:

    22.1 Adding Functionality
    22.2 Skin Selection
    22.3 Non-virtual Overriding
    22.4 Leveraging Scope
    22.5 Simulated Compile-time Polymorphism
    22.6 Parameterised Polymorphic Packaging.

And if you want to know any more than that, you'll have to buy it (probably available around Sept/Oct). :)

Zed wrote:
> Heh. Please provide an example where MI causes problems.
> :)

* Class constructors
* Inheriting the same base class twice, throuth two children

I tried once to learn the rules that goven "virtual" base classes, and was quickly convinced that MI had opened up a very difficult can of worms.

Even if the complexity is managable through use of coding standards, the language (and thus the compiler) still has to support the most evil uses of MI.  It's better, IMHO, to just drop it altogether and end up with a simpler, more reliable compiler.

I believe that D should support more of MI than it currently does, but only so far as tag classes and mixins.

The propagation of contructor arguments up diamond inheritance hierarchies is a hideous wart, and should not be even attempted for D.

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:c3d1ri$1kmc$1@digitaldaemon.com...
> Zed wrote:
> > Heh. Please provide an example where MI causes problems.
> > :)
>
> * Class constructors
> * Inheriting the same base class twice, throuth two children
>
> I tried once to learn the rules that goven "virtual" base classes, and was quickly convinced that MI had opened up a very difficult can of worms.
>
> Even if the complexity is managable through use of coding standards, the language (and thus the compiler) still has to support the most evil uses of MI.  It's better, IMHO, to just drop it altogether and end up with a simpler, more reliable compiler.
>