tags:

views:

388

answers:

4

If front () returns a reference and the container is empty what do I get, an undefined reference? Does it mean I need to check empty() before each front()?

+12  A: 

You get undefined behaviour - you need to check that the container contains something using empty() (which checks if the container is empty) before calling front().

anon
You can also use empty().
Dave Van den Eynde
I wish they had been more specific when they designed and specified STL. I think a large number of C++ porting issues and bugs are caused by platform-specifing implementations of these "undefined behaviours" exploited by not-so-good programmers.
DrJokepu
The decision to make something UB usually means there was some overhead in the alternative - in this case throwing an exception, which C++ always strives to avoid.
anon
I think so too. UB simply means "strange behaviour will occur from now on", not that one platform will do one thing and another will do something else.
Dave Van den Eynde
size() can be very expensive for some containers. empty() is the appropriate call to use.
Mark Ransom
I have an aversion to using empty() because subconciously I think it is a command rather than a question. I wish it had been called "is_empty". Also, I rarely uses lists, which is the only one of the standard containers where size() is problematic.
anon
high quality implementations will throw/assert that issue anyway
Johannes Schaub - litb
A debug implementation might throw or assert, but the release should never do that as it is non-standard.
graham.reeds
graham, huh? throwing or asserting in that case is not non-standard. it is undefined behavior to do so, so the implementation is allowed to do everything it wants. including throwing or raising an assertion failure. but it would be quite silly to still do asserts in release build (for op[] at least)
Johannes Schaub - litb
@Neil i mean the issue that one does v[outOfBounds] for example. if you are building in debug mode, i would expect a high quality implementation to throw/assert-fail that
Johannes Schaub - litb
+6  A: 

You get undefined behaviour.

To get range checking use at(0). If this fails you get a out_of_range exception.

graham.reeds
+1  A: 

Undefined Behaviour

anil
+1  A: 

You've always have to be sure your container is not empty before calling front() on this instance. Calling empty() as a safe guard is good.

Of course, depending on your programm design, always having a non-empty container could be an invariant statement allowing you to prevent and save the call to empty() each time you call front(). (or at least in some part of your code?)

But as stated above, if you want to avoid undefinied behavior in your program, make it a strong invariant.

yves Baumes