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

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.

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.next.codeblocks.org/index.php/topic,1670.msg12192.html#msg12192

Ok, I will close here my small parentheses .

Best wishes,
Michael

[JGM]

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.

Something similar happened to me with GCC on Linux (ubuntu). I Created a container with this function

Code Select Expand

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;
  }
}

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]

...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.

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 Select Expand

     m_Data = new T[++m_Count];
     for(int i=0; i<m_Count; ++i)
     {
       m_Data[i] = tempData[i];
     }

should be

Code Select Expand

     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];
     }

Right?  Sorry if im imagining things.  Wait actually more appropriate place to correct would be:

Code Select Expand

T tempData = new T[m_Count+1];

[thomas]

Yes, that looks like you're running out of bounds. That's a nasty to detect bug, because it won't work reliably, but it won't crash reliably, either. ( ---> but, not the compiler's fault)

[JGM]

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.

You are a great noob!

You have all the reason.

The headache I got checking the code, and didn't see that.  :oops:
At least was a good exercise for you  :wink:
Two pairs of eyes work better than one pair

Well, guess then that GCC is perfect