inline virtual functions

[siddhu]

Dear experts,

A virtual function has to have an address. So if an inline virtual
function is actually inlined then in that case what does address of
this function signify? How does compiler know at compile time about
the actual object a pointer points to so that it can paste the correct
inline function in the place of function call if the function is
getting inlined?

 

[Victor Bazarov]

Dear experts,

A virtual function has to have an address.

Really? Why?

So if an inline virtual
function is actually inlined then in that case what does address of
this function signify?

If a function is inlined, the compiler is still free to create a body
of it _if_ it needs to take the address.

How does compiler know at compile time about
the actual object a pointer points to so that it can paste the correct
inline function in the place of function call if the function is
getting inlined?

It doesn't. The whole point of polymorphism is that the type of the
actual object is unknown until the run time.

V

 

[siddhu]

Really? Why?


If a function is inlined, the compiler is still free to create a body
of it _if_ it needs to take the address.


It doesn't. The whole point of polymorphism is that the type of the
actual object is unknown until the run time.

Without knowing the exact type how can a compiler expand the function
at function call?

 

[Stuart Redmann]

Without knowing the exact type how can a compiler expand the function
at function call?

If the compiler doesn't know which function will be used, it cannot expand it.
As the inline keyword doesn't _require_ the compiler to expand functions (the
inline keyword is only a _suggestion_ that the method should be expanded), the
compiler is free to simply call the function.

BTW, inline and virtual don't go together. As I recall, compilers may even issue
a warning if you try to inline virtual methods.

Regards,
Stuart

 

[Alf P. Steinbach]

* Stuart Redmann:

BTW, inline and virtual don't go together. As I recall, compilers may
even issue a warning if you try to inline virtual methods.

'inline' and 'virtual' are very compatible. A compiler that issues any
diagnostic on the combination is trash, probably pre-standard. Use
decent compilers.

 

[gpuchtel]

Dear experts,

A virtual function has to have an address. So if an inline virtual
function is actually inlined then in that case what does address of
this function signify? How does compiler know at compile time about
the actual object a pointer points to so that it can paste the correct
inline function in the place of function call if the function is
getting inlined?

http://www.devx.com/tips/Tip/13815

 

[James Kanze]

Really? Why?

For the same reason every function has to have an address. You
can take its address with the & operator.

Beyond that, of course, the compiler might want the address for
some internal house keeping. In the case of a virtual function,
this is in fact very likely. (But of course, that's the
compiler's problem, not yours.)

Note that the standard guarantees that all instances of the
address of the function compare equal, even when they are taken
in different compilation units.

If a function is inlined, the compiler is still free to create a body
of it _if_ it needs to take the address.

It doesn't. The whole point of polymorphism is that the type of the
actual object is unknown until the run time.

And of course, just because you say "inline" doesn't mean that
the compiler has to generate the function inline (and vice
versa). In the case of a virtual function called through a
pointer or a reference, there's a very, very good chance that
the compiler won't inline it (although I've heard of some that
do, in some special cases).

 

[James Kanze]

* Stuart Redmann:

'inline' and 'virtual' are very compatible. A compiler that issues any
diagnostic on the combination is trash, probably pre-standard. Use
decent compilers.

I'll go even further, and say that there are two cases where I
regularly inline virtual functions, and I've never seen a
warning about it.

The first is the virtual destructor of an "interface", e.g.:

class Interface
{
public:
virtual ~Interface() {}
// Only pure virtual functions...
} ;

Since the destructor is the only function which has an
"implementation", it seems a shame to have to create a source
file just for it. (And of course, the destructor never will be
called virtually, since instances of the class can't exist.)

The second is when the concrete instance of an interface is
created by a factory function, with a different function for
each type. In such cases, the simplest solution is to define
the derived class in the factory function, and C++ requires all
functions in a local class to be defined in the class
definition, which means that they are "inline"; in this case, of
course, the function will never, ever actually be inlined.

 

[gpuchtel]

The first is the virtual destructor of an "interface", e.g.:

class Interface
{
public:
virtual ~Interface() {}
// Only pure virtual functions...
} ;

Since the destructor is the only function which has an
"implementation", it seems a shame to have to create a source
file just for it. (And of course, the destructor never will be
called virtually, since instances of the class can't exist.)

Actually, an instance of the 'Interface' class does exist, it's just
that it cannot be instantiated explicitly; however, the compiler will
create it. Furthermore, the destructor of the abstract (Interface)
class 'is' called, which is why an implementation was needed in first
place. For example:

class Interface {
public:
virtual ~Interface() = 0 {
std::cout << "virtual ~Interface()" << std::endl;
}
};

class Concrete : public Interface {
public:
~Concrete() {
std::cout << "virtual ~Concrete()" << std::endl;
}
};

void SomeFunction()
{
Concrete* concrete = new Concrete();
delete concrete;
}

....renders the following output:

"virtual ~Concrete()"
"virtual ~Interface()"

 

[James Kanze]

Actually, an instance of the 'Interface' class does exist,

When I speak of an instance, I'm using the usual meaning: an
object with type Interface. Obviously, the derived classes will
have a sub-object of type Interface, and during construction and
destruction, there will be a moment when the dynamic type of the
object is Interface (but with the above destructor, and the
compiler provided constructors, there's no way a program can
actually see this) but there can be no fully constructed object
of type Interface.

it's just that it cannot be instantiated explicitly;

Or implicitly.

however, the compiler will create it.
When?

Furthermore, the destructor of the abstract (Interface)
class 'is' called,

But it's never called "virtually". Whenever the compiler calls
it, it knows exactly that destructor is being called. (That's
why you can declare it pure virtual.) At least read what you
are responding to.