questions from strategies and tactics C++

[puzzlecracker]

I have recently decided to go over the questions in the classical book
by Murray and few of them admittedly befuddled me.

page 140:

1. Under what circumstances should a smart compiler be able to use
static binding for a virtual function call? (is it when base class
pointer refers to base class object?)

2.Does it ever make sense to declare an inline virtual function? Under
what circumstances (is in it a contradiction unless it relates to my
answer to above question)?

3. Under what circumstances might be very costly to make a large
function virtual?

 

[Alf P. Steinbach]

* puzzlecracker:

I have recently decided to go over the questions in the classical book
by Murray and few of them admittedly befuddled me.

page 140:

1. Under what circumstances should a smart compiler be able to use
static binding for a virtual function call? (is it when base class
pointer refers to base class object?)

When the compiler can determine which function will be executed. A dumb
compiler can do that for

A o;
o.f();

A smart compiler can do it also for a range of other cases.

The time spent in analysis go quickly up, however.

2.Does it ever make sense to declare an inline virtual function?
Yes.


Under
what circumstances (is in it a contradiction unless it relates to my
answer to above question)?

Any circumstances, it's mostly a personal preference. Circumstances
where it isn't a good idea: when the project/firm's coding guidelines
say otherwise. No technical reasons.

3. Under what circumstances might be very costly to make a large
function virtual?

The direct (relative) cost of virtualness has nothing to do with the size of
a function but with the execution time and frequency of calls. So this one
has me befuddled, too. I'm guessing that the authors earlier have given
some inane advice like "prefentially don't make small functions virtual",
and here are trying to make the earlier advice seem sort of rational.

 

[Alipha]

#include <iostream>

class Base {
public:
Base(const Base &) { std::cout << "copy is made" << std::endl; }
virtual ~Base() {}
virtual void foo() { std::cout << "Base" << std::endl; }
};

class Derived : public Base {
public:
virtual void foo() { std::cout << "Derived" << std::endl; }
};

void f(Base *p, Base obj, Base &ref) {
p->foo();
obj.foo();
ref.foo();
}

int main() {
Derived d;
f(&d, d, d);
return 0;
}

f accepts a pointer, an object, and a reference to Base. However, one
of these guarentees that Base::foo is called eventhough d, a Derived
object, is passed, and so the compiler can optimize it. perhaps this
example program will help you answer things correctly.

 

[puzzlecracker]

2.Does it ever make sense to declare an inline virtual function?

Yes.

I don't think a compiler can inline a virtual function (unless it is an
object -not a pointer to- or a pointer to a class instance of the same
class (A a=new A; a.foo() ), so declaring it as inline doesn't make
sense from efficiency point of view (much less from aesthetic one) -
the function simply won't be inlined. aka. static vs. dynamic
binding... .

On the same note: can you have or inline a virtual template *member*
function?

 

[Alf P. Steinbach]

* puzzlecracker:

[responding to my posting but referring to another posting, and not
stating who he's quoting etc. -- fixed:]
* Alf P. Steinbach:

* puzzlecracker:

Yes.

Your quoting and article references are inconsistent; please sharpen up.

I don't think a compiler can inline a virtual function (unless it is an
object -not a pointer to- or a pointer to a class instance of the same
class (A a=new A; a.foo() ), so declaring it as inline doesn't make
sense from efficiency point of view (much less from aesthetic one) -
the function simply won't be inlined. aka. static vs. dynamic
binding... .

Sorry, that's incorrect: a compiler can and will inline a virtual function
in the same way as other functions, when it knows which function will be
executed.

Also note that the keyword 'inline', or placing a member function definition
inside the class definition, has very little to do with execution efficiency
or machine-code level inlining.

You should not rely on 'inline' as an optimization feature; that's not what
it's for.

On the same note: can you have or inline a virtual template *member*
function?

In C++ you cannot templatize a virtual function.

That's because a template function defines an infinite set of potential
functions, and dealing with the unknown set was and largely still is beyond
the compiler/linker technology C++ rests on in practice.

 

[puzzlecracker]

In C++ you cannot templatize a virtual function.

That's because a template function defines an infinite set of potential

functions, and dealing with the unknown set was and largely still is
beyond
the compiler/linker technology C++ rests on in practice.





will (or should) a compiler complain or ignore the virtual aspects
(not vtable to be created if this the only v-function defined) if it
see virtual templ. mem. function?

 

[Alf P. Steinbach]

* puzzlecracker:

In C++ you cannot templatize a virtual function.

That's because a template function defines an infinite set of potential

functions, and dealing with the unknown set was and largely still is
beyond
the compiler/linker technology C++ rests on in practice.





will (or should) a compiler complain or ignore the virtual aspects
(not vtable to be created if this the only v-function defined) if it
see virtual templ. mem. function?

Could you please fix your quoting? It's really not acceptable. One easy
way is to download a news client such as (if you're running Windows) Forté
Free Agent, set up an account with a free news-server provider, and voilà.

To repeat myself: in C++ you cannot templatize a virtual function.