Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Building C::B with GCC 4.1.0
Michael:
Hello,
I have used the GCC 4.1.0 that Ceniza has provided :D. Check here for more info. Practically you should download MinGW if you not have it already. I have installed version 5.0. Then you download Ceniza's package, unzip it and copy and paste the repositories in MinGW. In C::B under Settings-->Compiler and debugger-->Directories tab-->Compiler tab, you add:
--- Quote ---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
--- End quote ---
That's all, at least with me. If you have some problems, just post here.
Anyway, after installing MinGW, you should let C::B autodects it and then check if the pathes it has set are correctly. Then you add GCC 4.1.0 and modify the compiler path (with me it was necessary to avoid file not found errors).
Best wishes,
Michael
Michael:
--- Quote from: Michael on February 01, 2006, 07:17:14 pm ---
--- Quote ---sdk/propgrid/include/wx/propgrid/propgrid.h:2352: warning: 'class wxPropertyContainerMethods' has virtual functions but non-virtual destructor
--- End quote ---
--- End quote ---
Concerning this warning, I have found an interesting discussion in the Qt forum.
This FAQ could also be helpful. At least it was for me :D.
[EDIT]: 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 ---
Michael
tiwag:
is gcc 4.1 really so much faster than gcc 3.4 on windows platform ??
has anyone done a comparison already , if so please post results.
any issues with using gcc 4.1 ??
Michael:
Hello,
Personally, I have not remarked a real speed difference between GCC 4.1.0 and GCC 3.4.4. The building time for C::B seems to be quite the same with both GCC 4.1.0 and GCC 3.4.4 (if we exclude the several warnings that GCC 4.1.0 displays: around 3600-3700 for C::B and 700-800 for contr. plugins. Until now C::B built with GCC 4.1.0 (debug) works not really faster that the same version compiled with GCC 3.4.4 (debug). May be a bit faster, but not so much.
Concerning the issues, I had to solve some with C::B, otherwise all seem to work well (until now :)).
Best wishes,
Michael
PS.: Anyway, the GCC 4.1.0 I am using (snapshot from Ceniza) is not the final release and this could have some influence.
thomas:
--- 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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version