copy ctor question

[WW]

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.

 

[Ron Natalie]

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]

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]

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?

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

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

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.

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]

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]

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]

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.

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?

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.

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]

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/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_120.html
http://pcroot.cern.ch/TaligentDocs/TaligentOnline/DocumentRoot/1.0/Docs/books/WM/WM_123.html

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]

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]

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]

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

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]

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]

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.

 

[jeffc]

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]

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]

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]

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?

 

[WW]

Gary Labowitz wrote:
[SNIP]

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

 

[jeffc]

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?