v0.79.5

Release Notes:

• Internal portable fix for size_t portable bit counting fallback.

v0.79.4

Release Notes:

• #206 Optimize calls to memcpy for bubble up operation. Similar to the bottom-up reheap shift operation, which eliminates 2 unnecessary memcpy calls per tree level, the bubble-up operation also performs this optimization; however, it requires only 1 pass.

v0.79.3

Release Notes:

• Implement shifting optimization for bottom-up heapify and bottom-up heapsort. The number of comparisons and calls to memcpy is now optimal given heapify and heapsort constraints.

v0.79.2

Release Notes:

• Internal flat hash map performance improvement.
  • Eliminate redundant group load and match when seeking the key or an insert slot in flat hash map insert operations.

v0.79.1

Release Notes:

• Internal performance improvements.
  • Implement bottom-up-reheap and bottom-up-heapsort for flat priority queue, significantly cutting down comparison callbacks. This means faster sorting and heapifying for the C Container Collection.

v0.79.0

Release Notes:

An alignment argument has been added to allocator interface. This is not a breaking change. Most existing CCC code can remain the same. However, I encourage users to use alignment-aware allocators moving forward to ensure correctness across all use cases.

/** @brief A bundle of arguments to pass to the user-implemented
Allocator_interface function interface. This ensures clarity in inputs and
expected outputs to an allocator function the user wishes to use for managing
containers. Additional context can be provided for more complex allocation
schemes.

The pointers are const to bind the input closely with its context, if context is
provided. Because container code is providing the user a reference to a user
type it currently stores, or data it manages, it is critical the user does not
accidentally move or misuse the pointer to jeopardize container invariants. */
typedef struct {
    /** The input to the allocation function. NULL or previously allocated. */
    void *const input;
    /** The bytes being requested from the allocator. 0 is a free request. */
    size_t bytes;
    /** The alignment for the base address of the returned bytes. */
    size_t alignment;
    /** Additional state to pass to the allocator to help manage memory. */
    void *const context;
} CCC_Allocator_arguments;

These arguments are then expected in the allocator interface function and interpreted as follows.

/** @brief The function interface for allocating, resizing, and freeing memory.

The C Container Collection relies on the following behaviors when calling the
user provided allocator function internally.

- If input is NULL and bytes 0, NULL is returned.
- If input is NULL with non-zero bytes, new memory is allocated and returned
  with the base address aligned to at least the alignment argument. If alignment
  is zero, the default alignment of the allocator is used (usually
  `max_align_t`).
- If input is non-NULL it has been previously allocated by the allocator.
- If input is non-NULL with non-zero bytes, input is resized to at least the
  bytes argument's capacity. The pointer returned is NULL if resizing fails.
  Upon success, the pointer returned might not be equal to the pointer provided
  and is aligned to at least the provided alignment argument. If alignment is
  zero, the default alignment of the allocator is used (usually `max_align_t`).
- If input is non-NULL and size is 0, input is freed and NULL is returned.

For example, one allocation interface using the standard library allocator might
be implemented as follows (alignment and context is not needed):

void *
std_allocate(CCC_Allocator_arguments const arguments) {
    if (!arguments.input && !arguments.bytes) {
        return NULL;
    }
    if (!arguments.input) {
        return malloc(arguments.bytes);
    }
    if (!arguments.bytes) {
        free(arguments.input);
        return NULL;
    }
    return realloc(arguments.input, arguments.bytes);
}

However, the above example is only useful if the standard library allocator
is used. Any allocator that implements the required behavior is sufficient.
For example programs that utilize the context parameter, see the sample
programs. Using custom arena allocators or container compositions are cases when
context is needed.

@warning Alignments are assumed to be powers of 2. Wrapping `malloc`, `realloc`,
and `free` is sufficient if all CCC container requested alignments are less than
or equal to `max_align_t`. If CCC requests alignments that exceed `max_align_t`,
a custom alignment-aware allocator is required. Some CCC code may request
alignments greater than the alignment of the user type stored in the container
when allocating; specifically, the flat hash hash map and array map containers
may request alignments that are greater then the user type being stored. */
typedef void *CCC_Allocator_interface(CCC_Allocator_arguments);

Making the allocator and entire C Container Collection alignment-aware ensures better performance and better allocator implementations. For a container such as the flat hash map that uses SIMD 16-byte group-aligned loads, it is critical that alignment is respected during the construction or allocation of the struct-of-arrays.

The following containers make use of the new alignment argument when requesting memory from an allocator. They also use the alignas compiler directive when constructing fixed-size containers.

• CCC_Array_adaptive_map
• CCC_Array_tree_map
• CCC_Flat_hash_map

When wrapping traditional malloc/realloc/free with a CCC_Allocator, alignment should be correct in most cases due to these functions using the alignment of max_align_t for allocations by default. If using special types with alignment greater than max_align_t or if CCC_FLAT_HASH_MAP_GROUP_COUNT exceeds max_align_t on your platform, an alignment-aware allocator is required.

v0.78.0

Release Notes:

• Fix metadata struct cleanup behavior for ordered maps upon clear and clear and free.
• Recommend upgrading to this version or newer.

v0.77.8

Release Notes:

• Add more const correct signatures to CCC_Flat_priority_queue interface.
  • Operations such as heapifying, sorting, updating, increasing, and decreasing do not actually modify any metadata fields of the CCC_Flat_priority_queue struct itself. They only operate by possibly swapping elements in the contiguous memory pointed to by the metadata. Therefore, const is the correct signature for those functions.

v0.77.7

Release Notes:

• Enable immutable releases.

v0.77.6

Release Notes: