My program skips the return statement

Question

My program has this function:

vector<itemPtr> Level::getItemsAt(const Point& pt) { vector<itemPtr> vect(items.size()); // copy all items at pt position to vect remove_copy_if(items.begin(), items.end(), vect.begin(), boost::bind(matchesPosition<itemPtr>, _1, pt)); // update LevelMap and return map.setHasItem(pt, false); return vect; } 

This compiles fine (I use g ++, my version of gcc is 4: 4.4.1-1ubuntu2), but when I run the program, it skips right above the return statement.

I went through gdb, setting a breakpoint on the previous line and getting the following:

 Breakpoint 1, yarl::level::Level::getItemsAt (this=0x80d4d58, pt=...) at src/Level.cpp:519 519 map.setHasItem(pt, false); (gdb) next 521 } (gdb) 

I tried to recompile from scratch several times, having previously deleted the executable and all the object files, and it still does.

It's strange if I comment on the return statement and try to compile it, it gives only warning: no return statement in function returning non-void . I would think that not providing a return statement in a function that returns something would be a compiler error, but I think not.

I understand that this is not so much, but does anyone have an idea why this is happening? What to check? At the moment, I don’t even know where to start.

EDIT: for clarification, I am compiling with -O0 .

According to tjm, my gcc version will still use RVO even with the -O0 compiler -O0 , so that was the problem after all. Thanks for the help guys.

Answer 1

C ++ source code does not have to match the resulting one-on-one object-code code while the behavior is preserved. What happens here is that the compiler reorders the code and probably causes the Return Value to be optimized .

Edit:

Add this to the GCC options: -fdump-tree-nrv to see the NRVO applications by the compiler (you will get a file with the extension .nrv ). This only works with an optimization level greater than -O0 .

Without optimization, replacing the return with a copy constructor or calling the copy assignment statement is still a front-end C ++ conversion that is not elegantly handled by gdb .

Answer 2

I can think of several reasons why the return statement might be skipped - could it be so?

• An exception is thrown on line 519. This sounds very unlikely if the given line 521 is included.
• The compiler has optimized the return statement string - are you debugging the correct debug assembly (without optimizations)?

Does the function work normally - does it return the calling result and does it continue to have fun?

Answer 3

Are maps and pt properly allocated and initialized objects?

If an exception is thrown from line 519, then the method will not return normally. In this case, you can expect the next line to “complete” as line 521 when the packet breaks up.

I saw quite a lot of this in Visual C ++ when the code does something that leads to "undefined behavior". I don't have enough experience with g ++ to find out if the observed behavior is the same.