What do I get from front() of empty std container?

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()?

From stackoverflow

• 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().

  Dave Van den Eynde : You can also use empty().

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

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

  Dave Van den Eynde : 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.

  Mark Ransom : size() can be very expensive for some containers. empty() is the appropriate call to use.

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

  Johannes Schaub - litb : high quality implementations will throw/assert that issue anyway

  graham.reeds : A debug implementation might throw or assert, but the release should never do that as it is non-standard.

  Johannes Schaub - litb : 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

• You get undefined behaviour.

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

• Undefined Behaviour

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