BDE 4.14.0 Production release
|
Provide an STL-compliant stack class.
Canonical header: bsl_stack.h
This component defines a single class template, bsl::stack
, a container adapter that takes an underlying container and provides a stack interface which the user accesses primarily through push
, pop
, and top
operations. A deque
(the default), vector
, or list
may be used, but any container which supports push_back
, pop_back , back
, and size
, plus a template specialization uses_allocator::type
, may be used.
A stack meets the requirements of a container adaptor as described in the C++ standard [stack]. The stack
implemented here adheres to the C++11 standard when compiled with a C++11 compiler, and makes the best approximation when compiled with a C++03 compiler. In particular, for C++03 we emulate move semantics, but limit forwarding (in emplace
) to const
lvalues, and make no effort to emulate noexcept
or initializer-lists.
The bsl::stack
adapter can accept for its (optional) CONTAINER
template parameter bsl::deque
(the default), bsl::vector
, bsl::list
, or other container classes that support the following types and methods.
value_type
reference
size_type
allocator_type
(if any stack
constructor taking an allocator is used)void push_back(const value_type&)
(and variant taking rvalue reference)void pop_back()
reference back()
size_type size() const
const_reference back() const
==
, !=
, <
, >
, <=
, >=
operatorsswap
function (found via ADL with std::swap
in the lookup set)The following term is used to more precisely specify the requirements on template parameter types in function-level documentation:
equality-comparable: The type provides an equality-comparison operator that defines an equivalence relationship and is both reflexive and transitive.
When the CONTAINER
template parameter is omitted the VALUE
template parameter specifies the value_type
of bsl::vector
, the default container type. The VALUE
template has no other role.
For C++17 and later, the behavior is undefined unless:
Prior to C++17, CONTAINER::value_type
determines the contained value type and VALUE
is simply ignored. The resulting code may work with instances of VALUE
(e.g., VALUE
is convertible to CONTAINER::value_type
) or not (compiler errors).
No memory allocator template arg is directly supplied to this class, the allocator type used is the allocator specified for the container class. Some functions of this template only exist if type CONTAINER::allocator_type
exists, and if it does exist it is assumed to be the allocator type used by CONTAINER
, and that CONTAINER
supports constructors of this type.
The constructors of this class take, as optional parameters, allocators of the object's parameterized CONTAINER::allocator_type
type, and allocators of this type are propagated to all constructors of the underlying container. In the case of container types bsl::deque
(the default type), bsl::vector
, and bsl::list
, CONTAINER::allocator_type
is bsl::allocator
which is implicitly convertible from bslma::Allocator *
, and which can be converted to a bslma::Allocator *
through the mechanism
accessor.
Hence if the underlying container takes bsl::allocator
, then the stack
object can take bslma::Allocator *
s to supply memory allocation. If no allocator is specified, allocator()
is used, which winds up using bslma::Default::allocator(0)
.
Below is a list of public methods of the bsl::stack
class that effectively forward their implementations to corresponding operations in the held container (referenced as c
) which is here assumed to be either bsl::deque
, or bsl::vector
, or bsl::list
.
In this section we show intended use of this component.
Suppose someone wants to keep track of chores their partner has asked them to do. Over the years, they have noticed that their partner generally wants the most recently requested task done first. If the partner has a new task in mind that is low-priority, they will avoid asking for it until higher priority tasks are finished. When they have finished all tasks, they report to their partner that they are ready for more.
First, we define the class implementing the to-do list.
Then, create an object of type ToDoList
.
Next, a few tasks are requested:
Then, they watch the Yankee's game on TV. Upon returning to the list they consult the list to see what task is up next:
Next, they see that they have to pay the bills. When the bills are finished, they flush that task from the list:
Then, they consult the list for the next task.
Next, they see that they have to change the car's oil. Before they can get started, another request comes in:
Then, they drive the car to the convenience store and picks up some hot dogs and buns. Upon returning home, they give the hot dogs to their partner, update the list, and consult it for the next task.
Next, they finish the oil change, update the list, and consult it for the next task.
Finally, their partner has now been informed that everything is done, and they make another request: