74

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

Improve this question

6 Answers 6

Reset to default
91

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

Improve this answer
Sign up to request clarification or add additional context in comments.

7 Comments

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.
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.
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.
A debug implementation might throw or assert, but the release should never do that as it is non-standard.
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)
|
18

You get undefined behaviour.

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

Improve this answer

Comments

8

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.

Improve this answer

Comments

2

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.

Improve this answer

Comments

1

Undefined Behaviour

Improve this answer

Comments

0

C++11 N3337 standard draft quote

I just wanted to quickly dig up where it says so in the standard, and I think this is it:

23.2.3 Sequence containers

Expression Operational semantics Container
a.front() *a.begin() vector

This says that a.front() is the same as *a.begin(), and we know that *a.begin() on an empty container is undefined.

We know that std::vector is a sequence container from:

23.3.6.1 Class template vector overview

A vector satisfies all of the requirements of a container and of a reversible container, of a sequence container [...]

Also of interest is the non-normative example:

17.3.26 valid but unspecified state

an object state that is not specified except that the object’s invariants are met and operations on the object behave as specified for its type

[ Example: If an object x of type std::vector is in a valid but unspecified state, x.empty() can be called unconditionally, and x.front() can be called only if x.empty() returns false. — end example ]

Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.