🚀 go-pugleaf

Hi,

Rich Hickey (hickeyr@ibm.net) wrote:
[Explanation of the proposal removed]

: class B{
: public:
:    virtual int foo()const=0;
:    //...
: };

: explicit class D:public B{
: public:
:   int foo()const{return data;}
:   //...
: private:
:   int data;
: };

: void fred(const D &d)
:    {
:    d.foo();  //as if d.D::foo(); - inlined
:    }

: void ethel(const B &b)
:   {
:   b.foo();	//even if b is a D, virtual function call (as always)
:   }


: It cannot be otherwise accomplished in the language, i.e. it requires an extension.

I think it is easy to accomplish the thing you want to do in the language:

  class E: public B {
  public:
    int foo_inline() const { return data; }
    int foo() const        { foo_inline(); }
  private:
    int data;
  };

  void foo(E const &e)
  {
    e.foo_inline(); // inline. Note that you know exactly the type of 'e'
    e.foo();        // virtual as ever
  }

Although I agree with you that your proposal is nicer to use, your
claim that it cannot be implemented in the language is wrong...
However, it would be nice to have a simple possibility to close a class
for further derivation (I know that it is possible using a friend and a
virutal base class but I think that this could even impose some runtime
penalty due to the representation of virtual bases).
--
dietmar.kuehl@uni-konstanz.de
http://www.informatik.uni-konstanz.de/~kuehl
I am a realistic optimist - that's why I appear to be slightly pessimistic

[ To submit articles: Try just posting with your newsreader.
		      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Rich Hickey writes:

> Proposal: Reconcile Inheritance and Inlining
> --------------------------------------------
> Rich Hickey
> rich@rcs-hq.mhs.compuserve.com

> -----------------------------------------------------------------------
> I propose that the explicit keyword be allowed as a qualifier of a class 
> definition, such qualification taking the form of:

> explicit class X{
>   //the definition of X
>   };

> and that such qualification has the following meaning:

> For any class X defined as explicit -

> X cannot be derived from.

> Any calls to member functions of X, even through pointers or references 
> to X, be called with the 'normal' function mechanism, i.e.  not the 
> virtual function mechanism, as if the call took the form of 
> x-> X::function().  That is to say, all calls on X's are in the explicit 
> scope of X.  (Language lawyers please refine)

The 'normal' function mechanism can be used for any method not
declared as virtual. The only exception I can think of is when a base
class declares a virtual function you do not want to reimplement, but
you also do not want to pay for the cost of virtual invocations:

class Base {
public:
  virtual void foo();
};

inline void Base::foo() {}

class Derived : public Base {};

main() {
  Derived X;
  X.foo();
}

You can allow foo's code to be inlined by changing the declaration of
Derived to:

class Derived : public Base {
public:
  inline void foo() { Base::foo(); }
};

Since Derived::foo is not virtual, in can be inlined, as well as
Base::foo could, since it is given a scope specifier. Although this
requires some more lines of code, no changes in the standard are
required.
-- 
Alexandre Oliva
oliva@dcc.unicamp.br
Universidade Estadual de Campinas, S~ao Paulo, Brasil

[ To submit articles: Try just posting with your newsreader.
		      If that fails, use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In message <4gkscd$8rl@news.BelWue.DE> - 
kuehl@uzwil.informatik.uni-konstanz.de (Dietmar Kuehl) writes:
:>
:>Hi,
:>
:>Rich Hickey (hickeyr@ibm.net) wrote:
:>[Explanation of the proposal removed]
:>
:>: class B{
:>: public:
:>:    virtual int foo()const=0;
:>:    //...
:>: };
:>
:>: explicit class D:public B{
:>: public:
:>:   int foo()const{return data;}
:>:   //...
:>: private:
:>:   int data;
:>: };
:>
:>: void fred(const D &d)
:>:    {
:>:    d.foo();  //as if d.D::foo(); - inlined
:>:    }
:>
:>: void ethel(const B &b)
:>:   {
:>:   b.foo();	//even if b is a D, virtual function call (as always)
:>:   }
:>
:>
:>: It cannot be otherwise accomplished in the language, i.e. it requires an extension.
:>
:>I think it is easy to accomplish the thing you want to do in the language:
:>
:>  class E: public B {
:>  public:
:>    int foo_inline() const { return data; }
:>    int foo() const        { foo_inline(); }
:>  private:
:>    int data;
:>  };
:>
:>  void foo(E const &e)
:>  {
:>    e.foo_inline(); // inline. Note that you know exactly the type of 'e'
:>    e.foo();        // virtual as ever
:>  }
:>
:>Although I agree with you that your proposal is nicer to use, your
:>claim that it cannot be implemented in the language is wrong...

What your are suggesting does not accomplish the same thing, i.e. it does 
not, in the language, accomplish an inline call to a virtual function called 
via a reference or pointer.

void fred(const D &d)
   {
   d.foo();  //as if d.D::foo(); - inlined
   }

I want to avoid wrapper classes, duplicate functions etc. The technique you 
are suggesting has always been available yet has seen little use (that I am 
aware of). It is much more than a matter of transparency or convenience. 
Developers may not consider your solution viable for a number of 
possible reasons.

Some of the differences are:

Double the number of functions in the concrete class, with the accompanying 
confusion and maintenance headaches.

An inability to easily change code that uses the base to use the derived, or 
vice-versa, due to the different names.

Thus, in spite of your technique having been available to them, most 
developers still consider hierarchy vs. inlining as an either-or choice.

Rich
---
[ To submit articles: Try just posting with your newsreader.  If that fails,
                      use mailto:std-c++@ncar.ucar.edu
  FAQ:    http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
  Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]