bool __CLR_OR_THIS_CALL _Grow(size_type _Newsize,
bool _Trim = false)
{ // ensure buffer is big enough, trim to size if _Trim is true
if (max_size() < _Newsize)
_String_base::_Xlen(); // result too long
if (_Myres < _Newsize)
_Copy(_Newsize, _Mysize); // reallocate to grow
else if (_Trim && _Newsize < _BUF_SIZE)
_Tidy(true, // copy and deallocate if trimming to small string
_Newsize < _Mysize ? _Newsize : _Mysize);
else if (_Newsize == 0)
_Eos(0); // new size is zero, just null terminate
return (0 < _Newsize); // return true only if more work to do
}
I have NO idea what's going on. If I replace return i with return 0 or any number it works fine. Any ideas :S
Last edited by Xharock on Wed Dec 27, 2006 9:04 pm, edited 1 time in total.
No, I've done debugging and m_elements[0] is definatly a valid pointer. If it wasn't surely it would not like the line where I compare the two strings? Anyway it is valid as this is an excerpt from a menu system I'm writing and it gets set through the menu file which has all worked up until now when i started to add some new features.
It doesn't reach those in the tests I'm doing. The function will break from that loop as soon as it finds a match for the string provided and in the tests I'm doing m_elements[0] is that match.
Well, i don't know what m_elements is or what getName() does return, so there could be a bug which i can't see. But besides the strange "else continue;" and the possible problem that your m_elements objects could be invalid the function looks fine. And that else-line won't cause the crash.
You are writing something about xstring which is a class about which i don't know anything. I don't even see it used here.
getName() simply returns a value in the cMenuElements class which is what m_elements[] is. The else statement is just a remnant from a previous incarnation of the function so I just left it there as it's no cause of a problem. I'm not sure if xstring might be related to std::string in any way?