Inline destructors and construtors
abhiji...@gmail.com
destructors gets called automatically which means for every object
when it is about to get out of scope OR when we call delete etc. and
hence it should be a function.
Also why we need inline constructors ?
Victor Bazarov
Nobody *needs* inline anything, really. It's just something that can
bring some benefits from time to time. And that's why modern compilers
actually do not necessarily follow the 'inline' (explicit or implicit)
specifiers. They inline or don't inline functions as they see fit.
Do you at all understand the concept of "inlining" a function? What
book on C++ are you currently reading?
V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask
abhiji...@gmail.com
When I say no need of inline, I'm saying.... its guranteed to be a
function call...
Hope you are getting this...
Making a virtual function inline is of NO use(even thousgh it does
nothing a empty body) as the function pointer is needed and hence it
WILL be a function istead of macro definition....
so my question was is it really necessary to have destructors declared
as inline as its of no use, as it will be anyway a function....
Alf P. Steinbach
> Making a virtual function inline is of NO use(even thousgh it does
> nothing a empty body) as the function pointer is needed and hence it
> WILL be a function istead of macro definition....
Some of your terminology seems to be garbled. I take it you mean that an
'inline' virtual routine will not be called virtually. Well, that's incorrect: a
virtual routine is always called virtually or, with respect to possible
optimizations, *as if* it had been called virtually.
'inline' does not affect that.
> so my question was is it really necessary to have destructors declared
Nothing is strictly "necessary".
It is a question of ethics (should we let all the "unnecessary" people continue
to use up resources, or just kill 'em?), convenience and economics.
E.g., most current C++ compilers require templates to be available in source
code form.
> as inline as its of no use, as it will be anyway a function....
Sorry, that's incorrect.
The guaranteed effect of 'inline', or equivalently for a member routine,
defining a member routine in the class definition, is to allow this definition
to occur in more than one compilation unit.
Additionally, by having the source code available (i.e. the source code is
available "inline" in e.g. a header file), this allows some optimizations such
as machine code inlining without using costly global program optimization.
Cheers & hth.,
- Alf
James Kanze
<abhijith....@gmail.com> wrote:
> What is the use of declaring inline destructors ?
> destructors gets called automatically which means for every
> object when it is about to get out of scope OR when we call
> delete etc. and hence it should be a function.
It is a function. The same reasons for inlining it apply that
apply for any function.
In practice, the only time I inline a destructor is in an
interface. Or when the profiler says I should.
> Also why we need inline constructors ?
For the same reason we need any inline function. Current
optimization technology isn't sufficient (at least in most
compilers).
In the case of special member functions (constructors,
destructors and the assignment operator), another reason for
inlining them in the case of interfaces may be to avoid needing
an implementation file. A call-back interface, for example,
will usually not have any implementation. It still requires a
user defined destructor, however, since the compiler provided
one won't be virtual. And in some cases, you might want to make
the constructor or the destructor protected. In such cases, it
seems silly to have to create a source file just for the empty
destructor, and I'll write:
class MyInterface
{
public:
virtual MyInterface() {}
// ...
} ;
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> * abhijith....@gmail.com:
> > Making a virtual function inline is of NO use(even thousgh
> > it does nothing a empty body) as the function pointer is
> > needed and hence it WILL be a function istead of macro
> > definition....
> Some of your terminology seems to be garbled. I take it you
> mean that an 'inline' virtual routine will not be called
> virtually. Well, that's incorrect: a virtual routine is always
> called virtually or, with respect to possible optimizations,
> *as if* it had been called virtually.
> 'inline' does not affect that.
Inline (by definition in the standard) has NO effect on the
semantics of a function. On the other hand, a virtual function
will not be called virtually if there is an explicit qualifier,
e.g. MyClass::f().
More generally, I'm not sure what "to be called virtually"
means. I've never seen the expression in any serious technical
literature, and the "native English" meaning would be that the
function isn't called "really", only virtually. But that
doesn't make sense here, and as you say, his terminology is
rather garbled, so I'm supposing, as you apparently did, that he
means that the dynamic type of the object will determine the
actual function called, rather than the static type. In which
case, of course: if a virtual function is called without an
explicit qualifier, the function called is always determined
according to the dynamic type of the object. The only
exceptions (maybe) are the compiler generated calls to the
constructors and destructors of base classes, from the
constructor or destructor of the derived class.
Of course, how the compiler decides which function to call is
its business, as long as it calls the right one. Most compilers
use the vptr/vtbl mechanism to call a virtual function, when
they don't know what the actual most derived type will be, and
use exactly the same mechanism they use to call a non-virtual
function if they do know. (I know you know this, but somehow, I
have the impression that the original poster doesn't.) And most
compilers cannot "inline" a function if they don't know which
function is actually going to be called (although I've heard of
at least one compiler that can do this, in certain special
cases).
> > so my question was is it really necessary to have
> > destructors declared
> Nothing is strictly "necessary".
It depends. If you want the destructor of the base class to be
virtual, it's necessary to declare it; the compiler generated
default won't be virtual.
It's actually an interesting example, since if the base class is
abstract, the "virtual" destructor will never be called via the
virtual function mechanism (since this will always resolve to
the destructor of the most derived class); it will, however, be
called directly (as if qualified) by the destructors of the
derived classes.
> > as inline as its of no use, as it will be anyway a
> > function....
> Sorry, that's incorrect.
The second part isn't. In C++, an inline function is a
function.
> The guaranteed effect of 'inline', or equivalently for a
> member routine, defining a member routine in the class
> definition, is to allow this definition to occur in more than
> one compilation unit.
And to require this definition to be present in all compilation
units which use the function.
> Additionally, by having the source code available (i.e. the
> source code is available "inline" in e.g. a header file), this
> allows some optimizations such as machine code inlining
> without using costly global program optimization.
There's also a clear statement in the standard concerning
intent. A compiler should make a greater effort to generate the
code inline (suppressing the function call) if the function is
declared inline. From a QoI point of view, it's pretty much
like register: the compiler should respect it unless it can
actually do a better job at optimizing. The only difference
being that this is the case for register, for almost all
compilers, and it is not the case for inline, except for a very
few compilers (but the number is probably growing).
Alf P. Steinbach
>
> I'm not sure what "to be called virtually"
> means. I've never seen the expression in any serious technical
> literature
Ah, terminology!
Always fun!
Well, the *international C++ standard* ISO/IEC 14882 uses the term "virtual
call" in two places.
The C++ standard is, IMHO, "serious technical literature"... ;-)
The original Smalltalk view is very clear on the effect of a virtual call. When
there is a source code call of a method with signature M on an object O, and the
method M is virtual in the statically known type of O, the execution effect is
as if a search for M starts in the most derived class of O's dynamic type. The
search for M goes upward all available base class chains, in any order, until an
M definition is found (the order doesn't matter because C++ guarantees that
there will be only one M reachable in this way, although higher up there may be
more). The found M is called with a pointer to O as the 'this' pointer.
Cheers, & hth.,
- Alf
PS: Yeah, I know you know what a virtual call is, even if you disagree with the
standard's terminology (as do I for some other terms). The explanation above is
for the benefit of other readers -- not all are aware of the Smalltalk view.
Jorgen Grahn
...
> When I say no need of inline, I'm saying.... its guranteed to be a
> function call...
> Hope you are getting this...
By "function call", you mean the assembly code actually jumps to some
shared code, passing parameters on the stack or in registers, and so
on.
> Making a virtual function inline is of NO use(even thousgh it does
> nothing a empty body) as the function pointer is needed and hence it
> WILL be a function istead of macro definition....
>
> so my question was is it really necessary to have destructors declared
> as inline as its of no use, as it will be anyway a function....
One more point the others missed: there is no requirement for
destructors to be virtual (even though I have seen old 1990s style
guides which forced them to be). I am not a big fan of run-time
polymorphism, so mine are typically not virtual. (Well, typically I
have no explicitly defined destructors.)
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se> R'lyeh wgah'nagl fhtagn!
James Kanze
> * James Kanze:
> > I'm not sure what "to be called virtually" means. I've
> > never seen the expression in any serious technical
> > literature
> Ah, terminology!
> Always fun!
Isn't it:-).
> Well, the *international C++ standard* ISO/IEC 14882 uses the
> term "virtual call" in two places.
Interesting. Does it define it, or just use it? (If the
latter, I would consider this a defect.)
> The C++ standard is, IMHO, "serious technical literature"... ;-)
Obviously, I haven't memorized it completely:-). The full
explination of what happens when you call a function, if the
function happens to be virtual (in the static type) speaks of
resolution against the dynamic type, which is fairly precise.
For some strange reason, I supposed that they would be
consistent in their use of terminology:-).
> The original Smalltalk view is very clear on the effect of a
> virtual call. When there is a source code call of a method
> with signature M on an object O, and the method M is virtual
> in the statically known type of O, the execution effect is as
> if a search for M starts in the most derived class of O's
> dynamic type. The search for M goes upward all available base
> class chains, in any order, until an M definition is found
> (the order doesn't matter because C++ guarantees that there
> will be only one M reachable in this way, although higher up
> there may be more). The found M is called with a pointer to O
> as the 'this' pointer.
I'm a bit confused about this. First you speak of Smalltalk,
then C++. In Smalltalk, IIRC, there can't be any ambiguity
because Smalltalk doesn't support multiple inheritance. And
IIRC (admittedly, a very big if), all functions in Smalltalk are
virtual. (Actually, IIRC, Smalltalk doesn't have functions,
only methods. And you can't call a method; you send a message
to an object. But I've never actually used Smalltalk, so none
of this is fixed in my mind like it is for C++.)
> PS: Yeah, I know you know what a virtual call is, even if you
> disagree with the standard's terminology (as do I for some
> other terms). The explanation above is for the benefit of
> other readers -- not all are aware of the Smalltalk view.
To tell the truth, I'm not that familiar with it either.
--
James Kanze
Alf P. Steinbach
You should be confused, but not because of the presence of two language views.
Rather, you should be confused because in the above I forgot to add the
necessary qualifications, i.e., because above is wrong...
Namely, there should be noted that that a base class B (and so on recursively in
that tree) is only searched if M is virtual in B.
Argh.
The price of being precise.
> In Smalltalk, IIRC, there can't be any ambiguity
> because Smalltalk doesn't support multiple inheritance. And
> IIRC (admittedly, a very big if), all functions in Smalltalk are
> virtual. (Actually, IIRC, Smalltalk doesn't have functions,
> only methods. And you can't call a method; you send a message
> to an object. But I've never actually used Smalltalk, so none
> of this is fixed in my mind like it is for C++.)
Uhm, mixture. "no ambiguity": right, but with reference to what? "all virtual":
right, even down to basic arithmetic primitives. "methods not functions": bull,
terminology. "can't call method": bull. "send message": just a conceptual view.
>> PS: Yeah, I know you know what a virtual call is, even if you
>> disagree with the standard's terminology (as do I for some
>> other terms). The explanation above is for the benefit of
>> other readers -- not all are aware of the Smalltalk view.
>
> To tell the truth, I'm not that familiar with it either.
In that case, I recommend the old Smalltalk-80 series of books by Goldberg &
Robson, and especially the short & sweet introduction (just a few paras) in the
first one. Although the book 2 or 3 story of HP's (or was it Tectronix?) efforts
to implement a bitmapped display on a vector terminal is hilarious. As far as I
know only 3 books were published, although 4 were planned.
It's interesting to note that some GUI features described there have still not
full support in Windows...