«

My class in a header file, contains inline virtual destructor.
Is this Ok? Can it cause any problems?

class base
{
public:
base() { }
virtual ~base { std::cout<<"Inside virtual destructor\n"; }

// Other members
};

"qazmlp" <> wrote in message
news: om...
> My class in a header file, contains inline virtual destructor.
> Is this Ok? Can it cause any problems?
>
> class base
> {
> public:
> base() { }
> virtual ~base { std::cout<<"Inside virtual destructor\n"; }
>
> // Other members
> };

It's fine, in fact its common. Why shouldn't it be OK?

john

qazmlp wrote:
> My class in a header file, contains inline virtual destructor.
> Is this Ok? Can it cause any problems?
>
> class base
> {
> public:
> base() { }
> virtual ~base { std::cout<<"Inside virtual destructor\n"; }
>
> // Other members
> };
If you declare a function as inline it doesn't mean that the compiler
*has* to inline that code - which usually wouldn't work with virtual
functions - you just 'suggest' that he *could* inline it. So it's all
right with that...

qazmlp wrote:
> My class in a header file, contains inline virtual destructor.
> Is this Ok? Can it cause any problems?

It can't. What excactly makes you to worry about it?

--
Best regards,
Andrey Tarasevich

"John Harrison" <> wrote in message
news:c1caf7$1gg5ad$...
>
> "qazmlp" <> wrote in message
> news: om...
> > My class in a header file, contains inline virtual destructor.
> > Is this Ok? Can it cause any problems?
> >
> > class base
> > {
> > public:
> > base() { }
> > virtual ~base { std::cout<<"Inside virtual destructor\n"; }
> >
> > // Other members
> > };
>
> It's fine, in fact its common. Why shouldn't it be OK?

Because it's "inline" and it's also "virtual". You don't see why that might
be contradictory and confusing?

jeffc wrote:
>> > My class in a header file, contains inline virtual destructor.
>> > Is this Ok? Can it cause any problems?
>> >
>> > class base
>> > {
>> > public:
>> > base() { }
>> > virtual ~base { std::cout<<"Inside virtual destructor\n"; }
>> >
>> > // Other members
>> > };
>>
>> It's fine, in fact its common. Why shouldn't it be OK?
>
> Because it's "inline" and it's also "virtual". You don't see why that might
> be contradictory and confusing?
> ...

It shouldn't be contradictory and/or confusing to a person who fully
understands the meaning of these qualifiers in C++.

--
Best regards,
Andrey Tarasevich

"jeffc" <> wrote
> > > My class in a header file, contains inline virtual destructor.
> > > Is this Ok? Can it cause any problems?
> > >
> > > class base
> > > {
> > > public:
> > > base() { }
> > > virtual ~base { std::cout<<"Inside virtual destructor\n"; }
> > >
> > > // Other members
> > > };
> >
> > It's fine, in fact its common. Why shouldn't it be OK?
>
> Because it's "inline" and it's also "virtual". You don't see why that might
> be contradictory and confusing?

Virtual functions can be inlined. The compiler can determine by context whether
to inline the code or do a polymorphic call. For example, if you invoke a
virtual method directly on an object (not a reference or a pointer), the
compiler MAY choose to inline the code, since there's no ambiguity. Or it can
make a direct (non-vtable) call to the out-of-line function. If you're calling
the same virtual function through a pointer or a reference, the compiler must
then select the appropriate function through the vtable. This implies that you
may (and probably will) have both an out-of-line and inline implementations of
your function if (a) it's inlineable, and (b) you call it directly at some
point.

A detail to remember: when you invoke a method from within the object, it's
invoked through the 'this' pointer, which means that unless you qualify it, you
always get a polymorphic call.

Claudio Puviani

"Andrey Tarasevich" <> wrote in message
news:...
> jeffc wrote:
> >> > My class in a header file, contains inline virtual destructor.
> >> > Is this Ok? Can it cause any problems?
> >> >
> >> > class base
> >> > {
> >> > public:
> >> > base() { }
> >> > virtual ~base { std::cout<<"Inside virtual destructor\n"; }
> >> >
> >> > // Other members
> >> > };
> >>
> >> It's fine, in fact its common. Why shouldn't it be OK?
> >
> > Because it's "inline" and it's also "virtual". You don't see why that
might
> > be contradictory and confusing?
> > ...
>
> It shouldn't be contradictory and/or confusing to a person who fully
> understands the meaning of these qualifiers in C++.
>

It seems to be a very common misunderstanding that the meaning of the
keyword inline has something to do with inlining function calls (easy to see
how that misunderstanding would occur). However the only meaning that the
C++ standard gives to inline functions is as an exception to the one
definition rule, thereby allowing inline functions to usefully appear in
header files.

In any case there are cases where a virtual function is called via a
non-virtual mechanism, this is especially true of a destructor.

john

"Andrey Tarasevich" <> wrote in message
news:...
> >>
> >> It's fine, in fact its common. Why shouldn't it be OK?
> >
> > Because it's "inline" and it's also "virtual". You don't see why that
might
> > be contradictory and confusing?
> > ...
>
> It shouldn't be contradictory and/or confusing to a person who fully
> understands the meaning of these qualifiers in C++.

Use your head man - does the originator of this thread sound like someone
who "fully understands the meaning of these qualifiers in C++"?

"John Harrison" <> wrote:

> It seems to be a very common misunderstanding that the meaning of
the
> keyword inline has something to do with inlining function calls
(easy to see
> how that misunderstanding would occur). However the only meaning
that the
> C++ standard gives to inline functions is as an exception to the one
> definition rule, thereby allowing inline functions to usefully
appear in
> header files.

It does have 'something to do' with inlining function calls:

"The inline specifier indicates to the implementation that inline
substitution of the function body at the point of call is to be
preferred to the usual function call mechanism." (7.1.2)

Inlining is not required, as you know, but it's a bit of an
overstatement to say that 'inline' is completely unrelated to
inlining.

Jonathan