Rich Hickey (hickeyr@ibm.net) wrote:
| sj@aracnet.com (Scott Johnson) wrote:
| >>Rich Hickey (hickeyr@ibm.net) wrote:
| >>
| >>> 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.
|
| >OTOH, I'm not so sure I like overloading of "explicit".  Currently, it
| >means something completely different than what you propose.  Your use will
| >not clash, of course, with the current use of explicit--disallowing
| >implicit use of a cast member function--but it reminds me of the abuse
| >heaped upon the keyword "static".
|
| True it is another overloading, but not confusing IMO. Another keyword
| makes the proposal all the more doomed. (BTW I like 'leaf' and use it
| when describing these 'end-of-the-line' classes)

Well, if overloading "explicit" is bad, and creating a new keyword is out,
then the only option that you have left is to re-cycle one of the unused C++
keywords :

 class goto X {} ;  // X is a leaf class

(-:

JdeBP (who wrote a goto statement in C++ this morning).
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

One possible syntax for indicating special global class properties,
would be to use special names as psuedo base classes. For example
a class that could not be derived from could be declared as:

class XXX : explicit { ...

other possible pseudo bases could include:


class XX : 0 { ... // class is abstract

class XX : struct { ... // class can use C style initializers

class XX : class { ... // class uses C++ style initialization only
--
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, MSSG MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 708 840 3942      Deparment Fax: 1 708 840 3785
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[Moderator's note: this thread seems to have drifted somewhat from it's
original topic.  Please keep follow-ups relevant to the topic of C++
standardization.  -fjh.]

Rich Paul <linguist@cyberspy.com> wrote in article
<320B6219.72CA@cyberspy.com>...
> Library authors don't nessisarily like being required to distribute a
> portion of their source ( inlines, etc ) in human-readable form (header
> file).  It would be much nicer to be able to distribute only
> declarations
> in the headers, and definitions in binary form, with inlines merged
> appropriately from the (.o/.obj) or (.a/.lib) files.

Why stop with compiling only inlines and templates? Why not include the
*header* in precompiled format in the library as well, with sufficient
preprocessor information to allow conditional compilation? This would help
keep secret (and prevent abuse of) things like implementation details and
private members...helping to avoid even intentional abuse of encapsulation.

In an integrated environment, the editor would be able to extract and
display header information only on a need-to-know basis. I've personally
never agreed with the "open source code" philosophy; I'm all for compiler
support for keeping trade secrets secret.

Who knows, this might even help the binary-interface situation.
--
Bradd W. Szonye (bradds@ix.netcom.com)
http://www.netcom.com/~bradds/nutty.html
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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 article <3208E120.2BA@cyberspy.com>,
Rich Paul  <linguist@cyberspy.com> wrote:
>Scott Johnson wrote:
>> Of course, the problem could be solved without ANY new keywords or
>> language extensions if we had smarter compilers/linkers...the complier
>> could figure out on its own if a virtual function was ever overridden, and
>> inline calls to virtual functions as appropriate if not....
>
>Some day, we'll get rid of the 1950's linker, and be happier people for
>it.
>
>Why can't inline functions be put into objs and then pasted into place
>by the linker?
>
>Why can't template code be put into objs and then fixed up ( instanced )
>by the linker?
>
>Why can't virtual calls be changed to non-virtual calls by the linker?

Because linkers know nothing about inline functions, templates, virtual
functions, or any other features of the language.  They deal strictly with
object code; and care not a whi whether the object code was originally
written in C, C++, Objective C, FORTRAN, assembly, or whatever else.


MAYBE what we need, to help solve the current problem while maintaining
compabitility with object-level linkers, is an intermediate linker which
takes some sort of C++-specifica immediate code, is charged with resolving
inter-module dependencies that the compiler cannot resolve, and produces
object code which can be fed to the object-level linker.  Would probably
increase compile times, but would allow for more optimization
opportunities, as well as lots of other goodies.


Scott




>
>--
>#include <legalbs/standarddisclaimer>
>Rich Paul                |  If you like what I say, tell my
>C++, OOD, OOA, OOP,      |  employer, but if you don't,
>OOPs, I forgot one ...   |  don't blame them.  ;->
>---
>[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]

>[ your news-reader.  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                             ]



--
/--------------------------------------------------------------------------\
|Scott Johnson -- Professional (sometimes) SW Engineer and all-purpose Geek|
|I don't speak for nobody but myself, which everyone else is thankful for  |
\--------------------------------------------------------------------------/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Valentin Bonnard wrote:

> Because (normal) inlining occur before compilation (I mean code
> generation). The compiler could, however, generate bytecode, link the
> program (remove virtual and add inline), and *after* compile the bytecode
> to generate EXE code. (No OBJ code would be used.)

Well, it's not the compiler, though that generates the final
binary(EXE).
It's the linker.  If the linker was able to do sophistocated fix-ups
like
insert inline/template functions, then there would be an added plus.

That would be that we could distribute libraries that contained ALL of
the code for a class, including the inline / template functions.

Library authors don't nessisarily like being required to distribute a
portion of their source ( inlines, etc ) in human-readable form (header
file).  It would be much nicer to be able to distribute only
declarations
in the headers, and definitions in binary form, with inlines merged
appropriately from the (.o/.obj) or (.a/.lib) files.

This would also cut down dramaticly on compilation times of headers with
extensive template use.  These have to be parsed/interpreted every time
they are included.  With a smarter linker, the code could be moved to
the
source files instead of being included in headers.

There has always been a great reluctance in this group to discuss
anything which would require a smart linker, which I only partially
understand.  It seems that the words "That would require a mod to the
linker" are enough to bring any suggestion for improvment to the
language to a halt.

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say, tell my
C++, OOD, OOA, OOP,      |  employer, but if you don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Rich Paul wrote:
>
> Scott Johnson wrote:
> > Of course, the problem could be solved without ANY new keywords or
> > language extensions if we had smarter compilers/linkers...the complier
> > could figure out on its own if a virtual function was ever overridden, and
> > inline calls to virtual functions as appropriate if not....
>
> Some day, we'll get rid of the 1950's linker, and be happier people for
> it.

Would a better linker make you happy? Or would it then be something
else?

Besides, if you aren't profiling to find performance bottlenecks, how
do you know that elminating virtual calls at link-time would improve
performance (of a certain program) by much? It's not like the linker
is going to remove *all* virtual calls.   :-)

> Why can't inline functions be put into objs and then pasted into place
> by the linker?

Then the linker would be the compiler (or else inlined functions
wouldn't
be inlined to maximal efficiency). There's nothing keeping a vendor from
implementing this feature, however.

> Why can't template code be put into objs and then fixed up ( instanced )
> by the linker?

It can be, and from what I understand, CFront does (did) something like
this.

> Why can't virtual calls be changed to non-virtual calls by the linker?

They can, and I bet some linkers do this already.

If it's an optimization issue, then the only result the user of the
compiler sees is faster, smaller code output. Their code will still
work on other compilers. However, if their code depends on non-standard
features (extensions) of a particular compiler, then their code won't
compile without modification. If the standard required many "advanced"
features that were costly to implement, I imagine the language wouldn't
do so well, meaning either there would be fewer compilers, or more
non-conforming compilers.

--
Chelly Green | mailto:chelly@eden.com | http://www.eden.com/~chelly
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

sj@aracnet.com (Scott Johnson) wrote:

>>> Rich Hickey
>>> hickeyr@ibm.net
>>
>>> -----------------------------------------------------------------------
>>> 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)

>Thus allowing the call to be inlined in this instance?  I like this idea.

>OTOH, I'm not so sure I like overloading of "explicit".  Currently, it
>means something completely different than what you propose.  Your use will
>not clash, of course, with the current use of explicit--disallowing
>implicit use of a cast member function--but it reminds me of the abuse
>heaped upon the keyword "static".

True it is another overloading, but not confusing IMO. Another keyword
makes the proposal all the more doomed. (BTW I like 'leaf' and use it
when describing these 'end-of-the-line' classes)

>Of course, the problem could be solved without ANY new keywords or
>language extensions if we had smarter compilers/linkers...the complier
>could figure out on its own if a virtual function was ever overridden, and
>inline calls to virtual functions as appropriate if not....

Yes and no. The optimization could be achieved, however I feel a
language feature is necessary here since the lack of this particular
optimization has direct effects on _design_ - i.e. people are
currently reluctant to use inheritance-based polymorphic designs since
they lose inlining.

Even if certain compilers/environments were to start supporting the
optimization library designers would still be reluctant to rely on the
optimization being present on all platforms.

I think the proposal remedies a fundamental wart of C++, evidenced by
the current flow of hype surrounding 'flat' libraries, the primary
benefit touted for which is efficiency. People are opting out of, and
in some cases deriding, hierarchical designs due to efficiency
concerns. So long OO?

C++ can and should support efficient OO. The proposal makes that
possible.

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

In article <320BC098.7665@eden.com> Chelly Green <chelly@eden.com>
writes:

|> Rich Paul wrote:
|> >
|> > Scott Johnson wrote:
|> > > Of course, the problem could be solved without ANY new keywords or
|> > > language extensions if we had smarter compilers/linkers...the complier
|> > > could figure out on its own if a virtual function was ever overridden, and
|> > > inline calls to virtual functions as appropriate if not....
|> >
|> > Some day, we'll get rid of the 1950's linker, and be happier people for
|> > it.

|> Would a better linker make you happy? Or would it then be something
|> else?

I agree with Rich Paul.  There are a number of restrictions in C++ whose
only justification is to allow linking with the standard Unix linker.
When C++ was getting started, these restrictions may have been
justified, but I really cannot see the need of them now.

|> Besides, if you aren't profiling to find performance bottlenecks, how
|> do you know that elminating virtual calls at link-time would improve
|> performance (of a certain program) by much? It's not like the linker
|> is going to remove *all* virtual calls.   :-)

That wasn't the point.  Actually, I'm not sure that an improved linker
will bring that much here.  From what I've seen, the real improvement
from inlining doesn't come from the lack of a function call, virtual or
other.  It comes from the added optimization possibilities that the
compiler gets by processing the function "in context".

|> > Why can't inline functions be put into objs and then pasted into place
|> > by the linker?

|> Then the linker would be the compiler (or else inlined functions
|> wouldn't
|> be inlined to maximal efficiency). There's nothing keeping a vendor from
|> implementing this feature, however.

The linker already is the compiler, in certain implementations.  CFront,
for example, instantiates templates at link time.

I think, however, that the real point is that the formel distinction
linker/compiler may be outdated (and it is certainly not mandated by the
standard).   Note that for the best optimization, you have to run the
code over typical data *before* optimizing; to run the code, you have to
link it.  And a number of compilers offer incremental linking; an
existing binary is patched with the changes, rather than regenerating a
new one.  And what is the role of the linker in the "fix and continue"
debuggers?

|> > Why can't template code be put into objs and then fixed up ( instanced )
|> > by the linker?

|> It can be, and from what I understand, CFront does (did) something like
|> this.

Not really.  Cfront still required the source code for the templates to
be visible.  What Cfront did do was link time instantiation of
templates; it did a link (or a pseudo-link), and used the unresolved
externals to determine which instantiations were needed.

|> > Why can't virtual calls be changed to non-virtual calls by the linker?

|> They can, and I bet some linkers do this already.

I doubt it, for the simple reason that it isn't worth it, unless you can
then get the compiler's optimizer to rework the resulting inline
functions.

|> If it's an optimization issue, then the only result the user of the
|> compiler sees is faster, smaller code output. Their code will still
|> work on other compilers. However, if their code depends on non-standard
|> features (extensions) of a particular compiler, then their code won't
|> compile without modification. If the standard required many "advanced"
|> features that were costly to implement, I imagine the language wouldn't
|> do so well, meaning either there would be fewer compilers, or more
|> non-conforming compilers.

Well, templates are certainly an "advanced" feature which is costly to
implement.  I think your remarks are relevant to the beginning days of
C++, but I think that the language has passed that stage now.  It's no
longer a question of whether C++ will survive, but whether it will leave
any place for other worthy languages.
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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                             ]

Scott Johnson wrote:
> Of course, the problem could be solved without ANY new keywords or
> language extensions if we had smarter compilers/linkers...the complier
> could figure out on its own if a virtual function was ever overridden, and
> inline calls to virtual functions as appropriate if not....

Some day, we'll get rid of the 1950's linker, and be happier people for
it.

Why can't inline functions be put into objs and then pasted into place
by the linker?

Why can't template code be put into objs and then fixed up ( instanced )
by the linker?

Why can't virtual calls be changed to non-virtual calls by the linker?

--
#include <legalbs/standarddisclaimer>
Rich Paul                |  If you like what I say, tell my
C++, OOD, OOA, OOP,      |  employer, but if you don't,
OOPs, I forgot one ...   |  don't blame them.  ;->
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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 article <3208E120.2BA@cyberspy.com> Rich Paul <linguist@cyberspy.com>
writes:

|> Scott Johnson wrote:
|> > Of course, the problem could be solved without ANY new keywords or
|> > language extensions if we had smarter compilers/linkers...the complier
|> > could figure out on its own if a virtual function was ever overridden, and
|> > inline calls to virtual functions as appropriate if not....

|> Some day, we'll get rid of the 1950's linker, and be happier people for
|> it.

|> Why can't inline functions be put into objs and then pasted into place
|> by the linker?

|> Why can't template code be put into objs and then fixed up ( instanced )
|> by the linker?

|> Why can't virtual calls be changed to non-virtual calls by the linker?

Why do you need to mangle names to get type safe linking?  (FWIW, I used
a linker in 1979 that did typesafe linking without mangling names.  Of
course, it wasn't under Unix:-).  I had the occasion to use the same
linker in 1990.  The vendor had added C to the languages supported, and
seriously weakened the type safety.)

(FWIW, I agree 100% with Scott Johnson's comments.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  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 article <or4tsgfvgl.fsf@grande.dcc.unicamp.br>,
Alexandre Oliva <oliva@grande.dcc.unicamp.br> wrote:
>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)

Thus allowing the call to be inlined in this instance?  I like this idea.

OTOH, I'm not so sure I like overloading of "explicit".  Currently, it
means something completely different than what you propose.  Your use will
not clash, of course, with the current use of explicit--disallowing
implicit use of a cast member function--but it reminds me of the abuse
heaped upon the keyword "static".

Perhaps another keyword, such as "leaf", might be better?  It might be
even possible to declare an individual member function "leaf", indicating
that it can no longer be overriden (and turn off the virtual mechanism for
that class and its subclasses.)

Of course, the problem could be solved without ANY new keywords or
language extensions if we had smarter compilers/linkers...the complier
could figure out on its own if a virtual function was ever overridden, and
inline calls to virtual functions as appropriate if not....

If you REALLY want to get ugly, a compiler could even inline calls to
virtual functions based on the BASE class b sticking a switch on the
vtable pointer into the code, and inlining each poosible virtual function
in the case blocks... :)  (No, that ain't a serious suggestion).


>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(); }
>};

Eh?  I believe "once virtual, always virtual" applies.  The definition of
Derived MUST know the definition for Base.  (in other words,

class Base;
class Derived: public Base {
...
};

shouldn't work.)  And once a member of Base is declared virtual, all
members of Derived with the same name are also virtual.


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

But it IS virtual....whether you want it to be or not.  :)

Scott
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/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
]