SeveralBuilder_test Class Reference

Description

Test:

use lib::Several to establish small collections of elements, possibly with sub-classing and controlled allocation.

• the container is populated through a separate builder
• the number of elements is flexible during population
• the actual container allows random-access via base interface

  See also

  several-builder.hpp

Definition at line 137 of file several-builder-test.cpp.

Private Member Functions
void	check_Builder ()
void	check_CustomAllocator ()
void	check_ElementStorage ()
void	check_ErrorHandling ()
virtual void	run (Arg)
void	simpleUsage ()

Member Function Documentation

simpleUsage()

void simpleUsage ( )

inlineprivate

Test:

demonstrate basic behaviour

Definition at line 157 of file several-builder-test.cpp.

check_Builder()

void check_Builder ( )

inlineprivate

Test:

various ways to build an populate the container

• with a defined interface type I, instances of arbitrary subclasses can be added, assuming there is sufficient pre-allocated buffer space; all these subclass instances are accessed through the common interface.

• yet the added elements can also be totally unrelated, in which case an unchecked wild cast will happen on access; while certainly dangerous, this behaviour allows for special low-level data layout tricks.
• the results from an iterator can be used to populate by copy

Definition at line 177 of file several-builder-test.cpp.

check_ErrorHandling()

void check_ErrorHandling ( )

inlineprivate

Test:

proper handling of exceptions during population

• when the container is filled with arbitrary subclasses of a base interface with virtual destructor, the first element is used to accommodate the storage spread; larger elements or elements of a completely different type can not be accommodated and the container can not grow beyond the initially allocated reserve (defined to be 10 elements by default).

• when the container is defined to hold elements of a specific fixed subclass, it can be filled with default-constructed instances, and the initial allocation can be expanded by move-relocation. Yet totally unrelated elements can not be accepted (due to unknown destructor); and when accepting another unspecific subclass instance, the ability to grow by move-relocation is lost.
• a container defined for trivial data elements (trivially movable and destructible) can grow dynamically just by moving data around with memmove. Only in this case the element spread can easily be adjusted after the fact, since a trivial element can be relocated to accommodate an increased spread. It is possible to add various different data elements into such a container, yet all will be accessed through an unchecked hard cast to the base element (uint8_t in this case). However, once we add a non-copyable element, this capability for arbitrarily moving elements around is lost — we can not adapt the spread any more and the container can no longer grow dynamically.
• all these failure conditions are handled properly, including exceptions emanating from element constructors; the container remains sane and no memory is leaked.

Definition at line 268 of file several-builder-test.cpp.

check_ElementStorage()

void check_ElementStorage ( )

inlineprivate

Test:

verify correct placement of instances within storage

• use a low-level pointer calculation for this test to draw conclusions regarding the spacing of objects accepted into the lib::Several-container
• demonstrate the simple data elements are packed efficiently
• verify that special alignment requirements are observed
• emplace several ''non copyable objects'' and then move-assign the lib::Several container instance; this demonstrates that the latter is just a access front-end, while the data elements reside in a fixed storage buffer

Definition at line 476 of file several-builder-test.cpp.

References lib::makeSeveral().

Here is the call graph for this function:

check_CustomAllocator()

void check_CustomAllocator ( )

inlineprivate

Test:

demonstrate integration with a custom allocator

• use the TrackingAllocator to verify balanced handling of the underlying raw memory allocations
• use an AllocationCluster instance to manage the storage

Definition at line 551 of file several-builder-test.cpp.

References SeveralBuilder< I, E, POL >::append(), SeveralBuilder< I, E, POL >::build(), TrackingAllocator::checksum(), SeveralBuilder< I, E, POL >::fillElm(), AllocationCluster::max_size(), TrackingAllocator::numAlloc(), TrackingAllocator::numBytes(), AllocationCluster::numBytes(), SeveralBuilder< I, E, POL >::reserve(), SeveralBuilder< I, E, POL >::shrinkFit(), and TrackingAllocator::use_count().

Here is the call graph for this function:

Inheritance diagram for SeveralBuilder_test:

Collaboration diagram for SeveralBuilder_test:

---

The documentation for this class was generated from the following file:

• several-builder-test.cpp