Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Building C::B with GCC 4.1.0
Michael:
--- Quote from: thomas on February 09, 2006, 08:24:49 pm ---
--- Quote from: Michael on February 07, 2006, 06:19:23 pm ---I also got this advice from a C++ expert:
--- Quote ---If your constructor does nothing: better not to define it. You can define a dummy destructor - but if you do it, define it as virtual.
--- End quote ---
--- End quote ---
This is actually quite a bad advice in my opinion. An empty constructor does not help, but it does not harm either.
On the other hand, a virtual destructor does harm. Maybe "harm" is the wrong word, let's say "cost", but the general idea is the same. At the very least, this bears an unnecessary storage cost of one pointer in the vtable plus one pointer for every allocated object. The single vtable entry may be neglegible, but if you allocate and deallocate 5 million objects, then carrying around one unnecessary v-ptr for each object may make a difference (as may the two additional pointer dereferences to call a destructor that does nothing...).
As always, the significance depends on what you do, but I think carrying around a penalty that you absolutely don't need is not a good idea.
You could say it is like using x++; or ++x;, the difference (if any) is not terribly big... but then, here we do bother ;)
The one and only case in which you really need a virtual destructor is when all of the following three conditions are met:
1. you have one or more virtual functions
2. you allocate an object of a derived class
3. you free this object as a type of the base class
For convenience, and for safety, one usually defines a virtual class' destructor virtual, as it does not make much difference (you have to carry the v-ptr around anyway) and you don't have to worry about who might derive from and tamper with your class.
However, it makes no sense at all to make a destructor virtual in a non-virtual class just for the sake of doing it.
--- End quote ---
Thank you very much for your explanation about virtual destructor :). What you say is correct. It is also what all the C++ websites I have looked at say. Anyway, I think that I have probably not correctly understood the advice of that person, who IMHO is a C++ expert (he is involved in the C++ Standardization Process and I would be very surprised if he had gave me an uncorrect advice). I will ask him and post here his answer.
Sorry for the not so accurate advice :oops: and thank you Thomas for pointing that out :D.
Michael
thomas:
--- Quote from: Michael on February 09, 2006, 09:07:46 pm ---Anyway, I think that I have probably not correctly understood the advice of that person, who IMHO is a C++ expert
--- End quote ---
Maybe he said "if you add a dummy destructor to a virtual class, make it virtual"?
Michael:
--- Quote from: thomas on February 09, 2006, 09:26:59 pm ---
--- Quote from: Michael on February 09, 2006, 09:07:46 pm ---Anyway, I think that I have probably not correctly understood the advice of that person, who IMHO is a C++ expert
--- End quote ---
Maybe he said "if you add a dummy destructor to a virtual class, make it virtual"?
--- End quote ---
No. I have just copied and past his remark.
I have implemented a template PriorityQueue class, which made use of a multimap. But I did not derived my class from the STL multimap. My class was more a wrapper.
My constructor and destructor originally were defined as:
--- Code: ---template
<
typename A,
typename P,
typename Cmp=greater<P>
>
class PriorityQueue
{
public:
/*Default constructor*/
PriorityQueue(void);
/*Destructor*/
~PriorityQueue(void);
...
};
/*
Default constructor
*/
template
<
typename A,
typename P,
typename Cmp
>
PriorityQueue< A, P, Cmp >::PriorityQueue()
{
}
/*
Destructor
*/
template
<
typename A,
typename P,
typename Cmp
>
PriorityQueue< A, P, Cmp >::~PriorityQueue(void)
{
}
...
--- End code ---
When I asked him what he thought about my class he answered me:
--- Quote ---Minor remarks:
1. In the constructor and destructor:
PriorityQueue(void)
In C++ you dont need to write f(void), f() is the same.
2. If your constructor does nothing: better not to define it.
You can define a dummy destructor - but if you do it,
define it as virtual.
--- End quote ---
May be I have misunderstand something. Anyway, his explanation was not too much detailed.
Michael
[EDIT]: I can post my class, if you would like to look at it.
thomas:
I don't get the point with the virtual destructor, to me it seems wrong. But hey, don't bother, I am neither God nor Stroustrup, so I would not know :)
--- Quote from: Michael on February 09, 2006, 09:50:37 pm ---In C++ you dont need to write f(void), f() is the same.
--- End quote ---
Isn't that the infamous construct that Stroustrup called an abomination? :lol:
Michael:
--- Quote from: thomas on February 09, 2006, 10:07:39 pm ---
--- Quote from: Michael on February 09, 2006, 09:50:37 pm ---In C++ you dont need to write f(void), f() is the same.
--- End quote ---
Isn't that the infamous construct that Stroustrup called an abomination? :lol:
--- End quote ---
Stroustrup calls it an abomination, but Dennis and Doug too: :D:
--- Quote ---Bjarne Stroustrup said this in an interview with Dr. Dobbs Journal:
Dennis Ritchie and Doug McIlroy famously gave me courage to break with
ANSI C in the issue of the declaration of a function with an empty
argument list. To preserve compatibility with K&R C, I had invented the
int f(void);
notation for C with Classes. Initially, I retained the old meaning of
int f();
as "f()" can accept any arguments that happens to be compatible with
f()'s (unseen) definition". Dennis and Doug called the f(void) style
declaration an abomination, so in C++
int f();
now has the obviuos meaning: "f() takes no arguments." Unfortunately,
ANSI C adopted f(void) so I had to introduce f(void) into C++ for ANSI C
compatibility.
--- End quote ---
Na ja, f() or f(void)... :D
Michael
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version