User forums > General (but related to Code::Blocks)
dev student in distress...
thomas:
Using MinGW gcc 4.2-dw2 :) But yes, you're right, they're faster on Linux. I think that the process creation overhead plays a not quite so insignificant role in that too (much more expensive under Windows).
My post may have been somewhat too harsh towards you personally, I apologise for that. Anything similar to "MinGW/gcc is slow" or "gcc is a bad compiler" is like a red rag to a bull for me. It is an urban myth that doesn't seem to die.
thomas:
Lol, what a shame this didn't come a month earlier :)
--- Quote from: http://www.gamedev.net/community/forums/topic.asp?topic_id=494086 ---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?
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.
--- End quote ---
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.
Michael:
Hello Thomas,
what you report is quite scaring, but good to know :). It remembers me some bad experiences I have had with Visual C++ 6, 7.0 and 7.1 (I also had some nice experiences btw).
Anyway, time ago (if not years :)), I have posted a website where they have made 'conformance tests' by using different compilers. It is a bit old, but still of interest (hope they will update it one day). Here is the link for those who are interested:
http://forums.codeblocks.org/index.php/topic,1670.msg12192.html#msg12192
Ok, I will close here my small parentheses :).
Best wishes,
Michael
JGM:
--- Quote from: thomas on May 13, 2008, 03:10:59 pm ---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.
--- End quote ---
Something similar happened to me with GCC on Linux (ubuntu). I Created a container with this function
--- Code: ---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;
}
}
--- End code ---
That code gave me segfault by the memory allocation functions of the c/c++ libraries, the error wasn't on my code, dont know why happened that :( Maybe some similar issue to MS Compiler. What a headache :?
Seronis:
--- Quote ---...the error wasn't on my code...
--- End quote ---
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.
In the 'else' block you create tempdata equal to the current size of m_Data and copy everything before freeing the memory m_Data occupies. You then increment the target size (m_Count) so that when you reallocate m_Data it now has room for the new object you are inserting. You then copy the now larger number of items from tempdata to m_Data, meaning that you attempt to retrieve one-too-many objects from tempdata into m_Data (you read past the end of tempdata). So:
--- Code: --- m_Data = new T[++m_Count];
for(int i=0; i<m_Count; ++i)
{
m_Data[i] = tempData[i];
}
--- End code ---
should be
--- Code: --- 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];
}
--- End code ---
Right? Sorry if im imagining things. Wait actually more appropriate place to correct would be:
--- Code: ---T tempData = new T[m_Count+1];
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version