Dev-C++: Thee is still wxDev-C++ which seems to be under active development.Looks like (in their Web site) it hasn't been updated for one year, or am I missing something ? Good tool, but buggy and CB is now far ahead ! I tested both, and got rid of wxDevC++ for CB.
VC8: MFC, .NET... (whatever, I don't really know);and also ATL/WTL
It's horribly optimized, allowing for some very slow, large file sizes being outputed. You also have to take great care in knowing which build has what switches enabled. 1 switch can mean the difference between a 1 min compile and a 1 hour compile. the GDB debugger is well...Well, with the last MingGW version and using precompiled headers, the compilation/link process has a very decent speed compared to VC 8.0's one. I don't see the huge difference you depict.
MingGW ...using precompiled headers...decent speed compared to VC 8.0's one. I don't see the huge difference you depict.I see it here, absolutely, all the time. Sadly, ouch is right on all [speed] points.
It's form builder [resource editor] is in classic microsoft fation very well designed.Eh? Windows 'resources' is basically a Windows 3.1 thing. You only get a real 'form builder' if you take the dotnet route, for regular C++ development MS is offering nothing comparable to say DialogBlocks, just the old primitive resource editor (MFC people are stuck with this).
If 6.0 is a tank, and 9.0 is a ferrari, mingw is some old broken down rust mobile held together with bungie cords, tie straps, and old extension cords used as rope... It's painfully slow (slowest compiler I've ever come across actually) what takes minuates in mingw compiles instantly in the 9.0 compiler and seconds in the 6.0 compiler. It's horribly optimized, allowing for some very slow, large file sizes being outputed.I have to object to this. Sorry, but I'm really soooooo fed up with those unfounded, biased Microsoft-vs-gcc comparisons.
The Express version is not usable (for anything serious)(http://forums.codeblocks.org/index.php/topic,7113.0.html)
You yourself spread compiler FUD. Remember thisI did when it came out, and it isn't usable for anything serious (unless one is willing to collect some odd bits here and there, and pirate some of the missing libraries, or never want to use 50% of the stuff, or never want to debug, etc).The Express version is not usable (for anything serious)(http://forums.codeblocks.org/index.php/topic,7113.0.html)
Did you ever try it? No?
it isn't usable for anything serious (unless one is willing to collect some odd bits here and there, and pirate some of the missing libraries, or never want to use 50% of the stuff, or never want to debug, etc).I don't see anything missing from the debugger. The pirated missing libraries referred to must be MFC, which is indeed left out (just as well, it is outdated). The Express edition comes with everything you need for [single platform] wxWidgets or Qt development for instance [only thing missing is a proper form designer]. You know how to argue. Do you know when to stop too?
I have a base class, which, for simplicity's sake, we'll just call Base. Not surprisingly, Derived is derived from Base. Base has a bunch of member variables and Derived adds some more. So far so good, right?It isn't nice to laugh at someone else's misfortune, but I can't help it... still rolling on the floor.
Now at some point my program just segfaults. At first I was completely puzzled as to what caused the crash. For 2 days I kept stumbling completely in the dark. Then I noticed that the crash only happened when I had previously made an assignment to Base's member m_pExceptionResult (which is a boost::shared_ptr). I started looking for possible out-of-bound array accesses and other such things that tend to corrupt a program's memory but couldn't find any place I did anything like that. So I took a look at the memory addresses of the members of Base and Derived respectively, and this is what I found out:
- m_pExceptionResult (boost::shared_ptr), the last member of Base, starts at address 0x1857268 ... sizeof( pExceptionResult ) gives 8 bytes
- m_value (an std::basic_string< wchar_t >), the first member of Derived, starts at address 0x1857264 ... sizeof( m_value ) gives 32 bytes
As you can see from that, the memory occupied by m_pExceptionResult partially overlaps with that of m_value!! So my question to that amounts to a simple WTF???
P.S. I'm using Visual C++ 2005.
It isn't nice to laugh at someone else's misfortune, but I can't help it... still rolling on the floor.
See, stuff like that is why I'd never use one of Microsoft's compilers.
Add(T object)
{
if(m_Count == 0)
{
m_Data = new T[1];
m_Data[0] = object;
m_Count = 1;
}
else
{
T tempData = new T[m_Count];
for(int i=0; i<m_Count; ++i)
{
tempData[i] = m_Data[i];
}
delete[] m_Data;
m_Data = new T[++m_Count];
for(int i=0; i<m_Count; ++i)
{
m_Data[i] = tempData[i];
}
m_Data[m_Count-1] = object;
delete[] tempData;
}
}
...the error wasn't on my code...Im truely just a hobbyist noob but i think it is in your code. Its also really early for me and I might be misreading a part.
m_Data = new T[++m_Count];
for(int i=0; i<m_Count; ++i)
{
m_Data[i] = tempData[i];
}
m_Data = new T[++m_Count];
for(int i=0; i< (m_Count-1); ++i) //dont go out of bounds
{
m_Data[i] = tempData[i];
}
T tempData = new T[m_Count+1];
Im truely just a hobbyist noob but i think it is in your code. Its also really early for me and I might be misreading a part.