copy ctor question

[scooter]

Given this class heirarchy

class Base{};

class A : public Base
{};

class B : public Base
{};

etc

How do I go about coding a copy ctor for the following class:

class SomeClass
{
std::vector<Base*> m_BasePointers;
};

when m_BasePointers contains pointers to child classes of Base?


thanks

[Attila Feher]

scooter wrote:

Given this class heirarchy

class Base{};

class A : public Base
{};

class B : public Base
{};

etc

How do I go about coding a copy ctor for the following class:

class SomeClass
{
std::vector<Base*> m_BasePointers;
};

when m_BasePointers contains pointers to child classes of Base?

Do you want to copy what Base* points to? Well, that is not very simple...
I mean it is, but forcing it work isn't (you cannot force people to write
correct code).

// I hope you have meant:
class Base{
virtual ~Base();
};

// Now let's add a clone function:
class Base{
virtual ~Base();
virtual Base *Clone() const {
return new Base(*this);
}
};
class A : public Base
{
virtual A *Clone() const{
return new A(*this);
}
};

class B : public Base
{
virtual B *Clone() const{
return new B(*this);
}
};

The trouble with that is that if someone forgets to write his clone in a
derived class you get slicing. :-(

Now all you need to do is to use Base::Clone() to copy the elements.

Some please add testing using the RTTI into the base class(es) to check if
*this is actually a Base when the function is called. If not, they assert
(abort).

--
Attila aka WW

[Unforgiven]

scooter wrote:

Given this class heirarchy

class Base{};

class A : public Base
{};

class B : public Base
{};

etc

How do I go about coding a copy ctor for the following class:

class SomeClass
{
std::vector<Base*> m_BasePointers;
};

when m_BasePointers contains pointers to child classes of Base?

I'm assuming you want the Base-derived objects to be copied in the process?
Because if just copying the pointer values is what you want the copy
constructor of std::vector should already do the trick.

Your best option (IMHO) is probably to give Base a 'clone' function, that
you implement in A and B to create new (equivalent) As and Bs, and use that
in the copy constructor of SomeClass:

<code>
class Base
{
public:
virtual Base* Clone() const = 0;
};

class A : public Base
{
public:
A(A &a) { /*copy const for A*/ }
virtual Base* Clone() const
{
/* Caller must delete pointer! */
return new A(*this);
}
};

/* Same for B as for A */
</code>

Writing the copy constructor should be easy then.

--
Unforgiven

A: Top Posting!
Q: What is the most annoying thing on Usenet?

[Ralf Schneeweiß]

> class B : public Base

{
virtual B *Clone() const{
return new B(*this);
}
};

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:
class B : public Base
{
public:
B( const B& b )
{
...
}

virtual B *Clone() const{
return new B(*this); // Here the copy-constructor is used.
}
};
Ralf
http://www.oop-trainer.de

[Ralf Schneeweiß]

The solution described by Attila Feher is the prototype pattern of the GoF.
The idea is to give a polymorphic (virtual) method, which can create a copy
of your polymorphic object. The problem is, that a constructor never can be
virtual.
You have to call it by its correct name, which ist the class name. Copying a
polymorphic object with the constructor would force you to find out the
object type
before you are copying. This is the reason for the virtual clone() method.
A good idea is to use the copy-constructor inside the clone() method.
Ralf

http://www.oop-trainer.de

[Attila Feher]

Ralf Schneeweiß wrote:

class B : public Base
{
virtual B *Clone() const{
return new B(*this);
}
};

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:

And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

--
Attila aka WW

[Attila Feher]

Ralf Schneeweiß wrote:

The solution described by Attila Feher is the prototype pattern of
the GoF. The idea is to give a polymorphic (virtual) method, which
can create a copy of your polymorphic object.
It is very similar, but the motivation is completely different. Therefore
it looks like the Prototype pattern, but it isn't. One reason for that is
that it is not used to provide copies of prototypes.
The problem is, that a constructor never can be virtual.
Which does not matter for use, since we use polymorphic behavior, so we do
not work with constructors directly.
You have to call it by its correct name,
which ist the class name.
Which does not apply here, since we do not know the class name.
Copying a polymorphic object with the constructor would
force you to find out the object type before you are copying.
This is the reason for the virtual clone()
method. A good idea is to use the copy-constructor inside the clone()
method.

It *is* using the copy constructor.

--
Attila aka WW

[Howard]

"Attila Feher" <at**********@lmf.ericsson.se> wrote in message
news:bl**********@newstree.wise.edt.ericsson.se...

Ralf Schneeweiß wrote:

The solution described by Attila Feher is the prototype pattern of
the GoF. The idea is to give a polymorphic (virtual) method, which
can create a copy of your polymorphic object.
It is very similar, but the motivation is completely different. Therefore
it looks like the Prototype pattern, but it isn't. One reason for that is
that it is not used to provide copies of prototypes.

The problem is, that a constructor never can be virtual.

Which does not matter for use, since we use polymorphic behavior, so we do
not work with constructors directly.

You have to call it by its correct name,
which ist the class name.

Which does not apply here, since we do not know the class name.

Copying a polymorphic object with the constructor would
force you to find out the object type before you are copying.
This is the reason for the virtual clone()
method. A good idea is to use the copy-constructor inside the clone()
method.

It *is* using the copy constructor.

--
Attila aka WW

I think you're misunderstanding Ralf's intention. If *I'm* understanding it
correctly, he's not disagreeing with you, but rather providing an
explanantion as to why yours is a good solution. At least, that's what I
got out of it. (The statement "the problem is..." isn't a complaint about
your solution, but an explanantion of the problem that *led* to the
solution.) Ralf, forgive me if I'm wrong, but that is what you meant, isn't
it?

(BTW, what's "GoF"???)

-Howard

[lilburne]

Attila Feher wrote:

Ralf Schneeweiß wrote:

class B : public Base
{
virtual B *Clone() const{
return new B(*this);
}
};

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:

And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

Keep the copy ctor, because you'll probably end up adding
data to the class, and at sometime you'll have a debugging
session where you'll want to know when the damn thing is
copy conbstructed.

Kick out the inlines though, virtual inlines are definitely
a mistake, and the rest are a waste of time, and only serve
to clutter your headers with implementation details.

[WW]

lilburne wrote:

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:

Again: it is not the Prototype pattern, it just happens to look like it.
The motivation of the Protoype pattern is completely different from the
motivation here. The things this code copies are not prototypes.
And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

Keep the copy ctor, because you'll probably end up adding
data to the class, and at sometime you'll have a debugging
session where you'll want to know when the damn thing is
copy conbstructed.

Big mistake. Huge mistake. Adding a copy constructor to a class having no
controlled resources is a mistake. It's copy constructor will be identical
to the one generated by the compiler - at best. However it introduces
maintenance risk and nightmare for no value.

If someone needs to know when a class is copied that person can look at the
language definition. Or make a small, 15 lines test program if unsure. BTW
copy constructors with side effects are rarely a good idea.
Kick out the inlines though, virtual inlines are definitely
a mistake, and the rest are a waste of time, and only serve
to clutter your headers with implementation details.

Have you looked at the language definition lately? I do not recall virtual
inlines being a mistake. And writing things inline in an untested example
code does not mean that they have to be written inline in real code
either...

BTW such a clone function is "final". So making it inline is not a mistake.
Although in this case adds not much, since such a function will only be
called via a pointer to (some) base. For this (by you unmentioned) reason
it makes sense not to make them inline. BTW I hope you did know that
virtual functions (if the dynamic type is known compile time) *can* be
inlined.

--
WW aka Attila

[Ralf Schneeweiß]

I think you're misunderstanding Ralf's intention. If *I'm* understanding it correctly, he's not disagreeing with you, but rather providing an
explanantion as to why yours is a good solution. At least, that's what I
got out of it. (The statement "the problem is..." isn't a complaint about
your solution, but an explanantion of the problem that *led* to the
solution.) Ralf, forgive me if I'm wrong, but that is what you meant, isn't it?

(BTW, what's "GoF"???)

-Howard

You are right. My English is not so good and possibly I am using
some words sometimes in a displaced manner.
Sorry for it.

Ralf

[jeffc]

"lilburne" <li******@godzilla.net> wrote in message
news:bl************@ID-203936.news.uni-berlin.de...

Kick out the inlines though, virtual inlines are definitely
a mistake...

Why do you say that?

[WW]

Howard wrote:

(BTW, what's "GoF"???)

The Gang og Four book:

http://hillside.net/patterns/DPBook/GOF.html

--
WW aka Attila

[WW]

WW wrote:

Howard wrote:

(BTW, what's "GoF"???)
The Gang og Four book:

The Gang of Four book:
http://hillside.net/patterns/DPBook/GOF.html

--
WW aka Attila

[lilburne]

WW wrote:

lilburne wrote:

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:

Again: it is not the Prototype pattern, it just happens to look like it.
The motivation of the Protoype pattern is completely different from the
motivation here. The things this code copies are not prototypes.

And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

Keep the copy ctor, because you'll probably end up adding
data to the class, and at sometime you'll have a debugging
session where you'll want to know when the damn thing is
copy conbstructed.

Big mistake. Huge mistake. Adding a copy constructor to a class having no
controlled resources is a mistake. It's copy constructor will be identical
to the one generated by the compiler - at best. However it introduces
maintenance risk and nightmare for no value.

Illustrate one!
If someone needs to know when a class is copied that person can look at the
language definition. Or make a small, 15 lines test program if unsure. BTW
copy constructors with side effects are rarely a good idea.
Only a putz doesn't know the circumstances of when the
language definition dictates that a copy constructor is
called. But that is different from discovering where a copy
ctor is being called from. You can't put a break point on a
complier generated method.

Kick out the inlines though, virtual inlines are definitely
a mistake, and the rest are a waste of time, and only serve
to clutter your headers with implementation details.

Have you looked at the language definition lately? I do not recall virtual
inlines being a mistake. And writing things inline in an untested example
code does not mean that they have to be written inline in real code
either...

The language definition also has gotos.
BTW such a clone function is "final". So making it inline is not a mistake.

How many versions of the method do you end up with?

Although in this case adds not much, since such a function will only be
called via a pointer to (some) base. For this (by you unmentioned) reason
it makes sense not to make them inline.
How many versions get injected into the object file?

BTW I hope you did know that
virtual functions (if the dynamic type is known compile time) *can* be
inlined.

Gosh you don't say. You mean that if one writes:

Derived d;
Base& b = d;
b.virtual_method();

the virtual method it might get inlined? Hot damn wonders
upon wonders, such a marvelous feature.

[WW]

lilburne wrote:

Big mistake. Huge mistake. Adding a copy constructor to a class
having no controlled resources is a mistake. It's copy constructor
will be identical to the one generated by the compiler - at best.
However it introduces maintenance risk and nightmare for no value.
Illustrate one!

If you ask me nicely.

If someone needs to know when a class is copied that person can look
at the language definition. Or make a small, 15 lines test program
if unsure. BTW copy constructors with side effects are rarely a
good idea.

Only a putz doesn't know the circumstances of when the
language definition dictates that a copy constructor is
called.

???
But that is different from discovering where a copy
ctor is being called from. You can't put a break point on a
complier generated method.

???

Have you looked at the language definition lately? I do not recall
virtual inlines being a mistake. And writing things inline in an
untested example code does not mean that they have to be written
inline in real code either...

The language definition also has gotos.

Yes. And they also have their use.

BTW such a clone function is "final". So making it inline is not a
mistake.

How many versions of the method do you end up with?

Versions???? Of Clone()? One per class.

Although in this case adds not much, since such a function will only
be called via a pointer to (some) base. For this (by you
unmentioned) reason it makes sense not to make them inline.

How many versions get injected into the object file?

None or one. Why do you care?

BTW I hope you did know that
virtual functions (if the dynamic type is known compile time) *can*
be inlined.

Gosh you don't say. You mean that if one writes:

Derived d;
Base& b = d;
b.virtual_method();

the virtual method it might get inlined? Hot damn wonders
upon wonders, such a marvelous feature.

It might. But this was not the case I was talking about.

--
WW aka Attila

[lilburne]

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bl************@ID-203936.news.uni-berlin.de...

Kick out the inlines though, virtual inlines are definitely
a mistake...

Why do you say that?

If the method is virtual then you will normally be calling
it via base some class, in other words you'll be using late
binding. In such cases the compiler can't inline the call
because it doesn't know which derived class version of the
method to inject. Therefore, it uses the virtual calling
mechanism so your virtual method is not inlined. Secondly
the compiler needs to have a method to call so it injects a
static version of the method into the object file created by
each source file that reads the header, you might also get a
copy of the classes vtable injected into the object file too.

Using inlines in general is a bit like writing:

if (expression) some_statement;

Try putting a break point on some_statement. Try puting a
break point on an inline method. You might be able to step
into one but you wont be able to break when the method is
called.

In some cases where a method is small and heavily used then
inline will give some performance benefit. But the cases
where that is so is pretty limited.

Then there is the obsfucation of the inline methods
cluttering up the class header files. When inlining is
heavily used the classes API becomes obscured, and when an
inline method is altered the world has to recompile.

[lilburne]

WW wrote:

lilburne wrote:

BTW such a clone function is "final". So making it inline is not a
mistake.

How many versions of the method do you end up with?

Versions???? Of Clone()? One per class.

LOL - such naivety.

[Rolf Magnus]

Howard wrote:

(BTW, what's "GoF"???)

It means "Gang of Four" and refers to the book "Design Patterns", which
was written by a "Gang of Four" authors Erich Gamma, Richard Helm,
Ralph Johnson and John Vlissides.

[WW]

lilburne wrote:

WW wrote:

lilburne wrote:

BTW such a clone function is "final". So making it inline is not a
mistake.

How many versions of the method do you end up with?

Versions???? Of Clone()? One per class.

LOL - such naivety.

Why is it so that all AOL born troll must use LOL when they run out of
arguments?

I am not naive. I use build systems as opposed to hoping to get a build
right. And yes. For my projects ODR seems not to be violated. And guess
what. It is not because of chanting or magic rules, such as: do not use
inlines. It probably has to do more with knowing what you are doing.

--
WW aka Attila

[WW]

lilburne wrote:

If the method is virtual then you will normally be calling
it via base some class, in other words you'll be using late
binding. In such cases the compiler can't inline the call
because it doesn't know which derived class version of the
method to inject. Therefore, it uses the virtual calling
mechanism so your virtual method is not inlined. Secondly
the compiler needs to have a method to call so it injects a
static version of the method into the object file created by
each source file that reads the header, you might also get a
copy of the classes vtable injected into the object file too.
Which might happen anyways, depending on the compiler you are using.
Using inlines in general is a bit like writing:

if (expression) some_statement;

Try putting a break point on some_statement. Try puting a
break point on an inline method. You might be able to step
into one but you wont be able to break when the method is
called.
Again: this is compiler/debugger dependent.
In some cases where a method is small and heavily used then
inline will give some performance benefit. But the cases
where that is so is pretty limited.
With you compiler, perhaps.0
Then there is the obsfucation of the inline methods
cluttering up the class header files.
For those who are unable to read C++, perhaps.
When inlining is
heavily used the classes API becomes obscured, and when an
inline method is altered the world has to recompile.

Yes. And when should a Clone method be altered? When the class name
changes.

If you hate inline, hate them. But starting a ranting when someone uses
inline notation in _example_ code is plain silly.

--
WW aka Attila

[Ron Natalie]

"lilburne" <li******@godzilla.net> wrote in message news:bl************@ID-203936.news.uni-berlin.de...

Big mistake. Huge mistake. Adding a copy constructor to a class having no
controlled resources is a mistake. It's copy constructor will be identical
to the one generated by the compiler - at best. However it introduces
maintenance risk and nightmare for no value.

Illustrate one!

In order to implement a copy constructor, you must inturn implement copy semantics
for each member and base class. The compiler generated copy constructor isn't
just empty like the default destructor. This means that everytime someone adds
an element they need to bash your copy constructor (and copy assignment operator).
Just more code to maintain, and totally unnecessary if the bases and members already
do proper copy semantics themselves. This is preferential, use strings rather than char*,
vector rather than managing the arrays yourself, etc.. then you don't have to worry about
destruction and copying semantics, nor initializing them.

[jeffc]

"lilburne" <li******@godzilla.net> wrote in message
news:bl************@ID-203936.news.uni-berlin.de...

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bl************@ID-203936.news.uni-berlin.de...

Kick out the inlines though, virtual inlines are definitely
a mistake...
Why do you say that?

If the method is virtual then you will normally be calling
it via base some class, in other words you'll be using late
binding. In such cases the compiler can't inline the call
because it doesn't know which derived class version of the
method to inject.

Your second statement is true, but your premise is false. In general you
can't say if you'll be using late binding or not. Virtual functions only
allow late binding in situations where you want it. It's quite feasible
that most code does not exploit late binding, even if the functions are
virtual for other situations. Virtual inline allows for both cases -
virtual when polymorphism is used, and efficiency when it is not.
Using inlines in general is a bit like writing:

if (expression) some_statement;

Try putting a break point on some_statement. Try puting a
break point on an inline method.
This is completely unrelated to virtual methods, true though it might be.
In some cases where a method is small and heavily used then
inline will give some performance benefit. But the cases
where that is so is pretty limited.
Again that is completely unrelated to virtual functions. That is merely an
inline function issue.
Then there is the obsfucation of the inline methods
cluttering up the class header files. When inlining is
heavily used the classes API becomes obscured, and when an
inline method is altered the world has to recompile.

That is not only a matter of opinion, but also a matter of style. Inline
functions don't have to go in the header files. Even if they do, they don't
have to go in the class definitions. Again, this is totally unrelated to
virtual functions.

[lilburne]

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bl************@ID-203936.news.uni-berlin.de...

Why do you say that?

If the method is virtual then you will normally be calling
it via base some class, in other words you'll be using late
binding. In such cases the compiler can't inline the call
because it doesn't know which derived class version of the
method to inject.

Your second statement is true, but your premise is false. In general you
can't say if you'll be using late binding or not. Virtual functions only
allow late binding in situations where you want it. It's quite feasible
that most code does not exploit late binding, even if the functions are
virtual for other situations. Virtual inline allows for both cases -
virtual when polymorphism is used, and efficiency when it is not.

What! You reckon that polymorphic systems are written and
the bulk of the execution involves calling virtual methods
on variables whose static type is known at compile time?

Why not use C?

Using inlines in general is a bit like writing:

if (expression) some_statement;

Try putting a break point on some_statement. Try puting a
break point on an inline method.

This is completely unrelated to virtual methods, true though it might be.

What part of 'Using inlines in general' was hard for you.

In some cases where a method is small and heavily used then
inline will give some performance benefit. But the cases
where that is so is pretty limited.

Again that is completely unrelated to virtual functions. That is merely an
inline function issue.

Didn't you say earlier:

"Virtual inline allows for both cases - virtual when
polymorphism is used, and efficiency when it is not."

you appear very confused.

Then there is the obsfucation of the inline methods
cluttering up the class header files. When inlining is
heavily used the classes API becomes obscured, and when an
inline method is altered the world has to recompile.

That is not only a matter of opinion, but also a matter of style. Inline
functions don't have to go in the header files. Even if they do, they don't
have to go in the class definitions. Again, this is totally unrelated to
virtual functions.

True, but where shall they can go? Obviously not in the
source file that would be daft, perhaps a ... inline file.
So now to avoid cluttering the header we have two places to
go look for code for the class, and doubled the number of
include directives and make dependencies.

[lilburne]

Ron Natalie wrote:

"lilburne" <li******@godzilla.net> wrote in message news:bl************@ID-203936.news.uni-berlin.de...

Big mistake. Huge mistake. Adding a copy constructor to a class having no
controlled resources is a mistake. It's copy constructor will be identical
to the one generated by the compiler - at best. However it introduces
maintenance risk and nightmare for no value.

Illustrate one!

In order to implement a copy constructor, you must inturn implement copy semantics
for each member and base class. The compiler generated copy constructor isn't
just empty like the default destructor. This means that everytime someone adds
an element they need to bash your copy constructor (and copy assignment operator).
Just more code to maintain, and totally unnecessary if the bases and members already
do proper copy semantics themselves. This is preferential, use strings rather than char*,
vector rather than managing the arrays yourself, etc.. then you don't have to worry about
destruction and copying semantics, nor initializing them.

Firstly you'll want to do some sanity checking on the
argument, some mutator on the class might have left you with
an empty string or vector, or some other violation of the
state invariant, you might as well catch it early.

Secondly you can't put a breakpoint on a compiler generated
method, and there *will* be times when you'll want to track
all ocassions where an object of your class is created. You
can't even #if the code out to see where the linker complains.

But this is all academic because you probably don't want
copy constructors for most classes anyway.

As an aside: WW's comment above that 'copy constructor will
be identical to the one generated by the compiler - at best'
isn't quite true. A profiling tool we use noticed that one
of the few compiler generated copy constructors in our
system was actually 7% slower than a hand rolled version,
*shrug*, you just never know where the bottlenecks are until
you go looking.

[lilburne]

WW wrote:

If you hate inline, hate them. But starting a ranting when someone uses
inline notation in _example_ code is plain silly.

"Kick out the inlines though, virtual inlines are
definitely a mistake, and the rest are a waste of time,
and only serve to clutter your headers with
implementation details."

is hardly a rant.

[jeffc]

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

If the method is virtual then you will normally be calling
it via base some class, in other words you'll be using late
binding. In such cases the compiler can't inline the call
because it doesn't know which derived class version of the
method to inject.
Your second statement is true, but your premise is false. In general you

can't say if you'll be using late binding or not. Virtual functions only allow late binding in situations where you want it. It's quite feasible
that most code does not exploit late binding, even if the functions are
virtual for other situations. Virtual inline allows for both cases -
virtual when polymorphism is used, and efficiency when it is not.

What! You reckon that polymorphic systems are written and
the bulk of the execution involves calling virtual methods
on variables whose static type is known at compile time?

Certainly some have been. But whether or not the "bulk" of or "most" of the
code is like that isn't the point. The point is that most applications mix
both.
class A;
class B : public A {};
A a; // I know I have an A
B b; // I know I have a B
void f(&A); // I don't care which I have
void f(&B); // I know I have a B

Virtual functions are only used in one of those cases.
Why not use C?
Because C doesn't support classes or inheritance, not to mention
polymorphism when I want to use it.

Using inlines in general is a bit like writing:

if (expression) some_statement;

Try putting a break point on some_statement. Try puting a
break point on an inline method.

This is completely unrelated to virtual methods, true though it might be.
What part of 'Using inlines in general' was hard for you.

What part of sticking to the subject of virtual inlines was hard for you?

In some cases where a method is small and heavily used then
inline will give some performance benefit. But the cases
where that is so is pretty limited.

Again that is completely unrelated to virtual functions. That is merely an

inline function issue.

Didn't you say earlier:

"Virtual inline allows for both cases - virtual when
polymorphism is used, and efficiency when it is not."

you appear very confused.

Only to you. The point is, and always has been, that virtual inline
functions make sense.

Then there is the obsfucation of the inline methods
cluttering up the class header files. When inlining is
heavily used the classes API becomes obscured, and when an
inline method is altered the world has to recompile.

That is not only a matter of opinion, but also a matter of style. Inline functions don't have to go in the header files. Even if they do, they don't have to go in the class definitions. Again, this is totally unrelated to virtual functions.

True, but where shall they can go? Obviously not in the
source file that would be daft, perhaps a ... inline file.
So now to avoid cluttering the header we have two places to
go look for code for the class, and doubled the number of
include directives and make dependencies.

Again, it's a matte of opinion and style. You don't like it, some people
do. But the relevant point is that it's not a reason to avoid VIRTUAL
inline functions per se.

[lilburne]

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

What! You reckon that polymorphic systems are written and
the bulk of the execution involves calling virtual methods
on variables whose static type is known at compile time?

Certainly some have been. But whether or not the "bulk" of or "most" of the
code is like that isn't the point. The point is that most applications mix
both.
class A;
class B : public A {};
A a; // I know I have an A
B b; // I know I have a B
void f(&A); // I don't care which I have
void f(&B); // I know I have a B

Virtual functions are only used in one of those cases.

The point of inlining is to gain some performance advantage,
and in order to do so you have to either make reading the
classes API more difficult by peppering it with
implementation details, or you have to contrive some other
scheme (seperate include file) to divorce the inline methods
from the class definition.

Is the complication worth the pain?
http://pcroot.cern.ch/TaligentDocs/T...WM/WM_120.html
http://pcroot.cern.ch/TaligentDocs/T...WM/WM_123.html

Didn't you say earlier:

"Virtual inline allows for both cases - virtual when
polymorphism is used, and efficiency when it is not."

you appear very confused.

Only to you. The point is, and always has been, that virtual inline
functions make sense.

They make sense syntactically but the compiler is only able
to inline them in special circumstances. So you have an
inline method with its associated pain, and even less chance
of the compiler being able to give you a performance boost,
then it might with a normal inline method.

Again, it's a matte of opinion and style. You don't like it, some people
do. But the relevant point is that it's not a reason to avoid VIRTUAL
inline functions per se.

Damn I never knew that where you put a brace could cause
such problems. Style indeed.

If you want a relevant point "Don't inline unless you can
show that the calling sequence is a bottleneck".

[jeffc]

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

Only to you. The point is, and always has been, that virtual inline
functions make sense.

They make sense syntactically but the compiler is only able
to inline them in special circumstances. So you have an
inline method with its associated pain, and even less chance
of the compiler being able to give you a performance boost,
then it might with a normal inline method.

It's not a question of "chance". When it is used polymorphically, it is not
inlined, and that is exactly what you want. You obviously have a distaste
for inline functions and have constantly steered this discussion toward
inline functions in general, which was never the issue. Regardless, you
said "virtual inlines are definitely a mistake", and you're wrong. They
make sense more than just syntactically. If inline functions make sense
(and of course they do), then virtual inline functions also make sense. If
you don't like them, then don't use them.

[lilburne]

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

Only to you. The point is, and always has been, that virtual inline
functions make sense.

They make sense syntactically but the compiler is only able
to inline them in special circumstances. So you have an
inline method with its associated pain, and even less chance
of the compiler being able to give you a performance boost,
then it might with a normal inline method.

It's not a question of "chance". When it is used polymorphically, it is not
inlined, and that is exactly what you want. You obviously have a distaste
for inline functions and have constantly steered this discussion toward
inline functions in general, which was never the issue. Regardless, you
said "virtual inlines are definitely a mistake", and you're wrong. They
make sense more than just syntactically. If inline functions make sense
(and of course they do), then virtual inline functions also make sense. If
you don't like them, then don't use them.

Foremost a virtual inline method is an inline method, though
it might not be compiled inline. So it is appropriate to
discuss the problems with using inline methods per se. They
aren't free, and I believe you acknowledge that. You can't
put a breakpoint on their call, you can't alter the methods
implementation without require all clients to recompile, you
can't change the internal data that the method uses
without requiring all clients to recompile. You pay this
price irrespective of whether the compiler is able to inline
the method or not (inline after all is only a hint). If the
method is compiled inlined you may suffer code bloat and
excessive paging. So you ought to be fairly sure that your
inlining is actually going to be cost effective. Now with
virtual inlines the situations where the compiler can inline
the method is restricted to those situations where it knows
the static type at compile time. That means the method from
which the call is being made has to have created the object.

You'll be hard pushed to provide a realistic example of
where a virtual inline demonstrates a measurable performance
gain, which can't be obtained by means other than using
inline. You can even choose what % performance gain you
think would be reasonable. Until then "virtual inlines are
definitely a mistake".

Note the Clone() example that started this off is a dreadful
example of an inline virtual, because if the compiler can
inline it, a simple copy construction could have been used.

[jeffc]

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

Foremost a virtual inline method is an inline method, though
it might not be compiled inline.
I disagree with this premise. It makes no sense to me. If it's not being
compiled inline, which feasibly could constitute every function in the
program, then how can it be "foremost" an inline method? (some would say,
BTW, that "inline method" is an oxymoron to begin with, but let's not go
down that road....)

<snipped irrelevant stuff that I won't disagree with>
Now with
virtual inlines the situations where the compiler can inline
the method is restricted to those situations where it knows
the static type at compile time. That means the method from
which the call is being made has to have created the object.

You'll be hard pushed to provide a realistic example of
where a virtual inline demonstrates a measurable performance
gain, which can't be obtained by means other than using
inline. You can even choose what % performance gain you
think would be reasonable. Until then "virtual inlines are
definitely a mistake".
You still don't seem to be acknowledging that point that when an inline
function is actually inlined by the compiler, then the performance gain is
what it is. If this performance gain is significant to you, then you should
use them. The whole point here is not whether inline functions are a
significant performance boost. The point is that virtual inlines have a
place. Correct me if I'm wrong, but your argument is "inlines are
definitely a mistake", not "virtual inlines are definitely a mistake."
There is no way you can convince me of a case where polymorphic and
non-polymorphic code is mixed in an application (very very common), and
inlines are desirable in that application, but virtual inlines are
"definitely a mistake". Since you can't convince me of such a case, your
argument is simply "inline functions are bad". If that is your argument,
then yes, for someone like you, obviously virtual inlines would be bad, as
well. But they are not a special case.
Note the Clone() example that started this off is a dreadful
example of an inline virtual, because if the compiler can
inline it, a simple copy construction could have been used.

Maybe so.

[lilburne]

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

Now with
virtual inlines the situations where the compiler can inline
the method is restricted to those situations where it knows
the static type at compile time. That means the method from
which the call is being made has to have created the object.

You'll be hard pushed to provide a realistic example of
where a virtual inline demonstrates a measurable performance
gain, which can't be obtained by means other than using
inline. You can even choose what % performance gain you
think would be reasonable. Until then "virtual inlines are
definitely a mistake".
There is no way you can convince me of a case where polymorphic and
non-polymorphic code is mixed in an application (very

very common), and inlines are desirable in that application, but virtual inlines are
"definitely a mistake". Since you can't convince me of such a case, your
argument is simply "inline functions are bad". If that is your argument,
then yes, for someone like you, obviously virtual inlines would be bad, as
well. But they are not a special case.

For a virtual inline method "NOT to be definitely a mistake"
we have to find a class with a polymorphic method which has
minimal code such that overhead of the call can be measured,
that it is called so often that this measure is significant
to the applications that use it, and also that those
significant calls are not made polymorphically. When you
find such a method I'll be the first to say that making it
inline was not a mistake.

Until then "virtual inlines are definitely a mistake".

[WW]

lilburne wrote:
[SNIP]

Foremost a virtual inline method is an inline method, though
it might not be compiled inline. So it is appropriate to
discuss the problems with using inline methods per se.

There are *no* methods in C++. Only member functions.

--
WW aka Attila

[WW]

lilburne wrote:

For a virtual inline method "NOT to be definitely a mistake" [SNIP]

There are *no* methods in C++. Only member functions.
Until then "virtual inlines are definitely a mistake".

No, they are not. Mistakes cause trouble. They don't.

--
WW aka Attila

[jeffc]

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

For a virtual inline method "NOT to be definitely a mistake"
we have to find a class with a polymorphic method which has
minimal code such that overhead of the call can be measured,
that it is called so often that this measure is significant
to the applications that use it, and also that those
significant calls are not made polymorphically. When you
find such a method I'll be the first to say that making it
inline was not a mistake.

Until then "virtual inlines are definitely a mistake".

It's very easy to find calls that are not made polymorphically. They exist
in virtually every OO application of any size. So that is not the problem.
The problem is in your criterium of performance. And that is an inline
issue, not a virtual inline issue. Your argument always boils down to the
same thing: performance. If you don't like inlines for this reason, that's
a valid opinion. If you don't understand that applications with polymorphic
functions also have plenty of non-polymorphic function behavior, then you're
wrong.

[lilburne]

WW wrote:

lilburne wrote:
[SNIP]

Foremost a virtual inline method is an inline method, though
it might not be compiled inline. So it is appropriate to
discuss the problems with using inline methods per se.

There are *no* methods in C++. Only member functions.

You don't say! Their is grammar and stelling errors in this
post. No doubt that forensic mind of yours will gain great
pleasure in pointing them out.

[lilburne]

jeffc wrote:

"lilburne" <li******@godzilla.net> wrote in message
news:bm************@ID-203936.news.uni-berlin.de...

For a virtual inline method "NOT to be definitely a mistake"
we have to find a class with a polymorphic method which has
minimal code such that overhead of the call can be measured,
that it is called so often that this measure is significant
to the applications that use it, and also that those
significant calls are not made polymorphically. When you
find such a method I'll be the first to say that making it
inline was not a mistake.

Until then "virtual inlines are definitely a mistake".

It's very easy to find calls that are not made polymorphically. They exist
in virtually every OO application of any size.

Oh well done! Being able to point out the obvious is
wonderous isn't it.
So that is not the problem.
The problem is in your criterium of performance. And that is an inline
issue, not a virtual inline issue.
You are confused again perhaps a question and answer session
will help

Q1: When is a virtual inline method not compiled inline?
A1: When it behaves virtually.

Q2: When is a virtual inline method compiled inline?
A2: When it doesn't behave virtually.

Your argument always boils down to the
same thing: performance.
Is there another reason to make something inline?
If you don't like inlines for this reason, that's
a valid opinion. If you don't understand that applications with polymorphic
functions also have plenty of non-polymorphic function behavior, then you're
wrong.

Unless you think that it is ok to gratuitously add keywords
to programs irrespective of the consequences this 'virtual
inline' method measurements will have shown that in one
function (F) at least the method is not called
polymorphically (see Q&A 2 above) and that calling the
method normally is a bottleneck. In other words F is a
significant part of the application. In such a case one
wonders why F has been written in a way that restricts its
usage to only one instance of a polymorphic type (see Q&A 1
above).

Whilst you suspect that there might be a case where a
'virtual inline' is needed you can't illustrate such a case.
Obviously you have never encountered one in your own experience.

[Gary Labowitz]

"WW" <wo***@freemail.hu> wrote in message
news:bm**********@phys-news1.kolumbus.fi...

lilburne wrote:
[SNIP]

Foremost a virtual inline method is an inline method, though
it might not be compiled inline. So it is appropriate to
discuss the problems with using inline methods per se.

There are *no* methods in C++. Only member functions.

What about us non-member functions?
--
Gary

[WW]

Gary Labowitz wrote:
[SNIP]

Foremost a virtual inline method is an inline method, though
it might not be compiled inline. So it is appropriate to
discuss the problems with using inline methods per se.

There are *no* methods in C++. Only member functions.

What about us non-member functions?

They are fine. And they are rarely called (falsely) methods. OTOH if you
take the OO meaning of method and the non-member operator functions of C++
which seem to be part of the classes interface (such as the stream insert
and extract operators, operator+ and the like) and we did use the word
method in C++ in its original OO meaning those should be methods as well.
That is one reason why method is a term which one should yuse when talking
about C++ code. It has no well-defined meaning in C++.

--
WW aka Attila

[jeffc]

"Gary Labowitz" <gl*******@comcast.net> wrote in message
news:7e********************@comcast.com...

"WW" <wo***@freemail.hu> wrote in message
news:bm**********@phys-news1.kolumbus.fi...

lilburne wrote:
[SNIP]

Foremost a virtual inline method is an inline method, though
it might not be compiled inline. So it is appropriate to
discuss the problems with using inline methods per se.

There are *no* methods in C++. Only member functions.

What about us non-member functions?

Why don't you killfile him and be done with it?