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

Question

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

Orthopsychiatry

Answer 1

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

Strut

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. – Organology

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. – Strut

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. – Selaginella

high quality implementations will throw/assert that issue anyway – Bearce

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

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) – Bearce

@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 – Bearce

Answer 2

You get undefined behaviour.

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

Academicism

Answer 3

Yes, you can use 'at' like Graham mentioned instead of using front.

But, at(0) is only available for some containers - vectors, deque and not for others - list, queue, stack. In these cases you've to fall back on the safety of the 'empty' check.

Tatty

Answer 4

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.

Ptosis

Answer 5

Undefined Behaviour

Theo