inline virtual functions.

[Dave Townsend]

Yo,

I had a job interview today, the interviewing asked me about
inline virtual functions, or what was my opinion on them.
Hm, I've seen mention of these babies in the reference material,
but I've never used one. ( I'm an experienced software developer
and have used C++ for more than 10 years)

Anybody found the use of one of these guys necessary or useful.
Curious minds need to know for the next curve ball question coming my
way....!

thanks, dave

 

[Victor Bazarov]

I had a job interview today, the interviewing asked me about
inline virtual functions, or what was my opinion on them.
Hm, I've seen mention of these babies in the reference material,
but I've never used one. ( I'm an experienced software developer
and have used C++ for more than 10 years)

Anybody found the use of one of these guys necessary or useful.
Curious minds need to know for the next curve ball question coming my
way....!

I am not sure I understand the reason for your puzzlement with those
functions. First of all, 'inline' is not a real attribute of
a function, but a mere suggestion. Second, any function that is
defined in the class definition is implicitly 'inline'. Third,
a virtuality of a function and its 'inline-ness' are two completely
orthogonal qualities, there is nothing special about them coexisting
just like 'const' and 'virtual' or 'const' and 'inline'.

So, I bet during your 10 years you have written something like

class Base {
public:
virtual ~Base() {} // does nothing -- no data
virtual void someFoo() = 0;
virtual void someBar() const = 0;
};

and suddenly you have the destructor for 'Base' defined as (gasp!)
inline and virtual. Ah, that's what "inline virtual" functions look
like! And I've been using those all the time without even knowing
that...

Come on, give yourself a break. Interviews (if you don't do them on
a regular basis) are stressful and some people can even forget the
multiplication table, let alone inline virtual functions.

Victor

 

[John Carson]

Yo,

I had a job interview today, the interviewing asked me about
inline virtual functions, or what was my opinion on them.
Hm, I've seen mention of these babies in the reference material,
but I've never used one. ( I'm an experienced software developer
and have used C++ for more than 10 years)

Anybody found the use of one of these guys necessary or useful.
Curious minds need to know for the next curve ball question coming my
way....!

thanks, dave

I think this was a trick question. Virtual function calls are only resolved
at runtime and cannot be inlined. The qualification to this statement is
that if a virtual function is called directly (i.e., using a class object
rather than a pointer or reference or else using the scope resolution
operator to fully specify the function concerned), then it is non-virtual
for the purposes of that call and can be inlined.

 

[Stephen Waits]

I had a job interview today, the interviewing asked me about
inline virtual functions, or what was my opinion on them.
Hm, I've seen mention of these babies in the reference material,
but I've never used one. ( I'm an experienced software developer
and have used C++ for more than 10 years)

Anybody found the use of one of these guys necessary or useful.
Curious minds need to know for the next curve ball question coming my
way....!

The compiler can't [always] know for certain which virtual will be
called.. therefore it cannot inline the function as it [often] must be
bound at runtime [via vtable lookup].

struct Base
{
virtual void Blah() { ; }
};

struct Sub: Base
{
/*virtual*/ void Blah() { ; }
};

void SomeFunc( Base* obj )
{
obj->Blah(); // impossible to know which function to inline here!
}


There are of course cases when the compiler can determine which function
needs to be called, and might therefore inline it. I don't know for
certain what the popular compilers do in this case. Once such case:

void OtherFunc()
{
Sub s;
s.Blah(); // always inlinable
}

So, while it shouldn't hurt anything, it probably also won't usually get
inlined.

Also remember that the inline function-specifier (implicit or explicit)
is only a recommendation.

See 7.1.2.

--Steve

 

[Risto Lankinen]

Also remember that the inline function-specifier (implicit or explicit)
is only a recommendation.

See 7.1.2.

However, inline has a second meaning as a linkage directive!

If you define a function in a header file (not a practice I would
recommend, but for the sake of argument), then only one file
in a multiple source file project may include that header, unless
the definition is tagged as inline. Failing to do that, ambiguities
in name resolution will emerge at link time.

- Risto -

 

[Uwe Schnitker]

I think this was a trick question. Virtual function calls are only resolved
at runtime and cannot be inlined. The qualification to this statement is
that if a virtual function is called directly (i.e., using a class object
rather than a pointer or reference or else using the scope resolution
operator to fully specify the function concerned), then it is non-virtual
for the purposes of that call and can be inlined.

Of course, this is not the typical way to call such a function. It smells of
either a questionable design or a performance hack.

There is one exception, though. There is one quite common use of this
mechanism: If the derived class version of a virtual function is supposed
to call the base class version. An example would be a print function where
each derived class adds print statements for its own data.

 

[Alf P. Steinbach]

I think this was a trick question. Virtual function calls are only resolved
at runtime and cannot be inlined. The qualification to this statement is
that if a virtual function is called directly (i.e., using a class object
rather than a pointer or reference or else using the scope resolution
operator to fully specify the function concerned), then it is non-virtual
for the purposes of that call and can be inlined.

The question was about inline virtual functions, not about inlining of virtual
function calls or of calls of virtual functions.

 

[John Carson]

The question was about inline virtual functions, not about inlining
of virtual function calls or of calls of virtual functions.

And why do you think that the interviewer bothered to single out inline
virtual functions as opposed to inline functions in general? The only reason
that I can think of is because the rules for inlining are different.

 

[Alf P. Steinbach]

And why do you think that the interviewer bothered to single out inline
virtual functions as opposed to inline functions in general? The only reason
that I can think of is because the rules for inlining are different.

It was an open question.

An open question can tell much.

 

[Michael D. Borghardt]

How about this.

<Foo.h>
Class Foo
{
public:
virtual void func() {}
}

<Bar.h>
#include "Foo.h"
class Bar : public Foo
{
public:
virtual void func();
}

<Bar.cpp>
void Bar::func()
{
}

<Main.cpp>

#include "Foo.h"
#include "Bar.h"

int main()
{
Foo f;
Bar b;

f.func(); // can be resolved at compile time.and is inlined
b.func(); // can be resolved at compile time and is outlined

Foo* fb = new Bar;
fb->func(); // resolved at runtime.

return 1;
}

 

[Andrey Tarasevich]

I think this was a trick question. Virtual function calls are only resolved
at runtime and cannot be inlined.

"Inline function" and "inlined function call" are two different and
relatively independent things in C++. The same applies to "virtual
function" and "virtual (dynamically resolved) function call".

The question specifically mentions "inline virtual functions" and make
no reference to function calls whatsoever. Formally, there's absolutely
nothing tricky about it.

 

[Andrey Tarasevich]

However, inline has a second meaning as a linkage directive!

If you define a function in a header file (not a practice I would
recommend, but for the sake of argument), then only one file
in a multiple source file project may include that header, unless
the definition is tagged as inline. Failing to do that, ambiguities
in name resolution will emerge at link time.
...

Exactly. The same can be said about 'virtual'. It also has several
second meanings only loosely related to dynamically resolving function
calls.

When answering such questions, it is very important to understand the
difference between the properties of functions and the properties of
concrete function calls. Unfortunately, in many cases these two got
mixed together, which can only lead to confusion.

 

[John Carson]

"Inline function" and "inlined function call" are two different and
relatively independent things in C++. The same applies to "virtual
function" and "virtual (dynamically resolved) function call".

The question specifically mentions "inline virtual functions" and make
no reference to function calls whatsoever. Formally, there's
absolutely nothing tricky about it.

We don't have the text of the interview question, just a paraphrase of it.
As I commented in response to Alf, I cannot think why the interviewer would
single out virtual functions for special mention unless (s)he was thinking
of the special inlining rules applicable to them.

 

[John Carson]

It was an open question.

But not open enough to permit a discussion of inlining?

 

[John Carson]

Exactly. The same can be said about 'virtual'. It also has several
second meanings only loosely related to dynamically resolving function
calls.

When answering such questions, it is very important to understand the
difference between the properties of functions and the properties of
concrete function calls.

I would consider the former to be the union of the latter (and of the syntax
for declaring and defining the functions).

 

[Alf P. Steinbach]

But not open enough to permit a discussion of inlining?

Oh, it is.

That too.

An open question can tell much.