wx/include/wx/string.h:58: warning: type attributes are honored only at type definition
sdk/propgrid/include/wx/propgrid/propgrid.h:2352: warning: 'class wxPropertyContainerMethods' has virtual functions but non-virtual destructor
sdk\propgrid\src\propgrid\propgrid.cpp:6804: warning: comparison is always false due to limited range of data type
sdk/manager.h:81: error: extra qualification 'Manager::' on member 'GetConfigManager'
sdk/configmanager.h:195: error: extra qualification 'ConfigManager::' on member 'Write'
sdk/editormanager.h:127: error: extra qualification 'EditorManager::' on member 'GetTree'
sdk/managedthread.h:14: error: extra qualification 'ManagedThread::' on member 'ManagedThread'
sdk/managedthread.h:15: error: extra qualification 'ManagedThread::' on member 'ManagedThread'
sdk/xtra_classes.h:22: error: extra qualification 'wxSplitPanel::' on member 'wxSplitPanel'
sdk/xtra_classes.h:25: error: extra qualification 'wxSplitPanel::' on member 'wxSplitPanel'
sdk/xtra_classes.h:37: error: extra qualification 'wxSplitPanel::' on member 'RefreshSplitter'
sdk/xtra_classes.h:39: error: extra qualification 'wxSplitPanel::' on member 'wxSplitPanel'
wxPG_IMPLEMENT_PGMAN_METHOD_NORET1 (SetPropertyValue, const wxPoint&);
wxPG_IMPLEMENT_PGMAN_METHOD_NORET1 (SetPropertyValue, const wxSize&);
wxPG_IMPLEMENT_PGMAN_METHOD_NORET1 (SetPropertyValue, const wxArrayInt&);
/*wxPG_IMPLEMENT_PGMAN_METHOD_NORET1*/void SetPropertyValue(const wxPoint&);
/*wxPG_IMPLEMENT_PGMAN_METHOD_NORET1*/void SetPropertyValue(const wxSize&);
/*wxPG_IMPLEMENT_PGMAN_METHOD_NORET1*/void SetPropertyValue(const wxArrayInt&);
I hope your patch get accepted, die warnings die ;-)
The "extra qualification" errors are really evil, even more those introduced by the use of macros. I created a post about this issue in the developers forum when I uploaded that version of GCC but it got no attention (at least no about that specific issue).
I'm still waiting for the release of GCC 4.1.0 final, which seems to be pretty close, to provide binaries for it.
I will check your post.
You'ren't missing anything really. I just named the problem, why and where it happened, but the only interest shown there was how I got to compile GCC 4.1.0 SmileAnd I still have not managed to compile it... :(
Quote from: MichaelI will check your post.
I think that's not possible. When I said "developers forum" I meant "developers only forum". I wonder if I also named it in the public thread :P
You'ren't missing anything really. I just named the problem, why and where it happened, but the only interest shown there was how I got to compile GCC 4.1.0 :)
I also hope your patch be accepted. It seems to be a matter of just a few weeks for GCC 4.1.0 final to be released, and it'll be surely available for Linux users first making Code::Blocks difficult to build there.
Hello,
I have tried to compile C::B + contrib. plugins with GCC 4.1.0 (from Ceniza) and it worked quite well :D. I got a lot of warnings regarding wxWidgets (I think that Ceniza said already something about this). Especially of this type:
Best wishes,
Michael
C:\Programme\MinGW\include --> if MinGW is installed in C:\MinGW, then change it in C:\MinGW\include
C:\Programme\MinGW\include\c++\4.1.0 --> if MinGW is installed in C:\MinGW, it is not necessary
C:\Programme\MinGW\include\c++\4.1.0\mingw32 --> if MinGW is installed in C:\MinGW, it is not necessary
Quotesdk/propgrid/include/wx/propgrid/propgrid.h:2352: warning: 'class wxPropertyContainerMethods' has virtual functions but non-virtual destructor
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.
I also got this advice from a C++ expert:This is actually quite a bad advice in my opinion. An empty constructor does not help, but it does not harm either.QuoteIf your constructor does nothing: better not to define it. You can define a dummy destructor - but if you do it, define it as virtual.
I also got this advice from a C++ expert:This is actually quite a bad advice in my opinion. An empty constructor does not help, but it does not harm either.QuoteIf your constructor does nothing: better not to define it. You can define a dummy destructor - but if you do it, define it as virtual.
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.
Anyway, I think that I have probably not correctly understood the advice of that person, who IMHO is a C++ expertMaybe he said "if you add a dummy destructor to a virtual class, make it virtual"?
Anyway, I think that I have probably not correctly understood the advice of that person, who IMHO is a C++ expertMaybe he said "if you add a dummy destructor to a virtual class, make it virtual"?
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)
{
}
...
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.
In C++ you dont need to write f(void), f() is the same.Isn't that the infamous construct that Stroustrup called an abomination? :lol:
In C++ you dont need to write f(void), f() is the same.Isn't that the infamous construct that Stroustrup called an abomination? :lol:
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.
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 :)
If you have a pure class, which has no virtual function, and you will likely _not_ to derive from this class: there is no reason to define a virtual destructor. You may still define a non-virtual destructor if you have to do some clean-up on the end of the object lifetime.
However if you create a class which is part of a class hierarchy, and you intend to derive other classes from this class, and even more if you plan to use this hierarchy in polymorphic way (i.e. calling virtual functions, etc...) it is a good design choice to create a virtual destructor, even if you have nothing to clean-up in the base class.
#include <stdio.h>
class Integer {int a;};
class VirtualFoo{public: virtual ~VirtualFoo(){};};
class VirtualInteger
{
int a;
public:
virtual void Empty(){};
};
class MultiVirtualInteger: public VirtualFoo, public VirtualInteger {};
int main()
{
int a;
Integer b;
VirtualInteger c;
MultiVirtualInteger ow;
Integer d[50000];
Integer e[50000];
VirtualInteger f[50000];
MultiVirtualInteger this_hurts[50000];
printf("int:\t\t\t %d\n", sizeof(a));
printf("Integer:\t\t %d\n", sizeof(b));
printf("VirtualInteger:\t\t %d\n", sizeof(c));
printf("MultiVirtualInteger:\t %d\n\n", sizeof(ow));
printf("int[]:\t\t\t %d\n", sizeof(d));
printf("Integer[]:\t\t %d\n", sizeof(e));
printf("VirtualInteger[]:\t %d\n", sizeof(f));
printf("MultiVirtualInteger[]:\t %d\n", sizeof(this_hurts));
return 0;
}int: 4
Integer: 4
VirtualInteger: 8
MultiVirtualInteger: 12
int[]: 200000
Integer[]: 200000
VirtualInteger[]: 400000
MultiVirtualInteger[]: 600000
Press any key to continue.I am curious to know what all the books written by C++ Experts that I have bought, will say about it
QuoteI am curious to know what all the books written by C++ Experts that I have bought, will say about itCheck out Scot Meyers and Herb Sutters their books ...
I have always appreciated C++ multiple-inheritance (especially when programming with Java Very Happy). Anyway, it has a cost as you correctly demonstrate.Multiple inheritance is really no bad thing, that's not what I wanted to demonstrate :lol:
QuoteI have always appreciated C++ multiple-inheritance (especially when programming with Java Very Happy). Anyway, it has a cost as you correctly demonstrate.Multiple inheritance is really no bad thing, that's not what I wanted to demonstrate :lol:
My point was that multiple virtual inheritance is still more expensive than (single) virtual inheritance.
In fact, I believe that multiple inheritance is one of the best features of C++, you only have to keep a few things in your head. One such thing is the "Diamond of Dread", and another example is the extra memory cost for virtual base classes.
Let's not forget that neither Stroustrup is stupid, nor are the ISO committee members, so if multiple inheritance was really that bad, then it wouldn't have been implemented in the first place, and it would never have made it into the standard ;)
2. C++ was designed to write software that runs country-wide call-centers, international airports, and airline booking systems. Java was designed to run embedded smart appliances ( = toasters with internet access).
3. Multiple inheritance (C++ in general) is not fool-proof. You really have to know what you do, and you really have to think about what you do, or your life will be a very unhappy one. Java, however, was explicitely designed for fools. Java does not require the programmer to think about "dangerous" things (in fact, it does not even allow it). The good side (and certainly one reason why Java was so successful) is that this avoids many problems alltogether.
QuoteYou'ren't missing anything really. I just named the problem, why and where it happened, but the only interest shown there was how I got to compile GCC 4.1.0 SmileAnd I still have not managed to compile it... :(