EDIT
I found the bug. It was in line 26. The call to string::substr takes a start index and a count, not a stop index, which is what I was doing.
As soon as I changed line 26 to :
string sub = string_to_split.substr(start_index, stop_index - start_index);
Then it (the function) worked again. GDB is still doing the same crazy thing, going from line 28 to line 26. I can't explain that. EDIT - The MSVC2015 Debugger doesn't do that. :/
--------------------------------------------------------
I am attempting to debug my GUI library, specifically, the SplitByDelimiterString function. It is doing some really crazy things that I can't explain.
Can you guys look at my code and see if there is anything wrong with it? This simple program just does not do what it is supposed to.
Take a look at this debugging session from gdb. It does crazy things, like jumping lines in source code :
For some unknown reason, when typing 'next' gdb jumps from line 28 to line 26, skipping lines 22-25.
Is this a bug in MinGW? GDB? My code?
I'm about to tear my hair out.
Halp!
Edgar
EDIT
FWIW, mingw-w64-x86_64 g++ 6.2.0 and gdb 7.12 does exactly the same thing. I originally compiled it with MinGW 5.3.0 and ran it with gdb 7.6.1.
I'm just curious. What does your st.exe source look like?
st.exe was compiled from StringTest.cpp which was given above exactly as written.
Edit
Gdb goes from line 28 to the next line (an empty brace) and calls it line 26. Definitely a bug in gdb.
The naming convention of "test" throws me a bit. To me, that would indicate that this is a test file, as in, a file that contains code that performs a list of tests outputting "pass" or "fail" for each test.
Test files look a bit different, and usually consist of several test cases, where each test case checks that a single piece of expected behavior works by using assertions.
That's why I never use the STL.
Never.
The naming convention of "test" throws me a bit. To me, that would indicate that this is a test file, as in, a file that contains code that performs a list of tests outputting "pass" or "fail" for each test.
Test files look a bit different, and usually consist of several test cases, where each test case checks that a single piece of expected behavior works by using assertions.
Pedantic much? It's not named UnitTest, it's named SplitTest, and all it does is test whether a given string splits properly or not. What are you so worried about my naming conventions for? It's a simple throw away test file, who cares what I name it? Maybe later I'll expand it to actually do unit tests, I don't know, who cares so what? I only used it to isolate code that wasn't performing as expected. Sorry I didn't name it properly for you. :/
Also, please do note that assertions are not normally catchable by a debugger. Good luck debugging with assertions if they don't throw a catchable signal.
I'm just tellin you how it is man
So you know how it is then? Congratulations on knowing everything.
You didn't find the bug, you didn't offer alternatives to gdb or explanations as to why it does crazy things. Seems like there are a few things you don't know yet. :/