struct cmc_collection {
    enum cmc_collection_type type; // DEQUE, HASHMAP, LIST, STACK, etc
    const char *key_type;
    const char *val_type;
};

A cmc_collection is the common interface to all data structures so that you can differentiate them when storing them on void pointers

INIT

• Bitset
• Deque
• HashBidiMap
• HashMap
• HashMultiMap
• HashMultiSet
• HashSet
• Heap
• IntervalHeap
• LinkedList
• List
• Queue
• SkipList
• SortedList
• Stack
• TreeBidiMap
• TreeMap
• TreeMultiMap
• TreeMultiSet
• TreeSet

ITER

• Bitset
• Deque
• HashBidiMap
• HashMap
• HashMultiMap
• HashMultiSet
• HashSet
• Heap
• IntervalHeap
• LinkedList
• List
• Queue
• SkipList
• SortedList
• Stack
• TreeBidiMap
• TreeMap
• TreeMultiMap
• TreeMultiSet
• TreeSet

STR

• Bitset
• Deque
• HashBidiMap
• HashMap
• HashMultiMap
• HashMultiSet
• HashSet
• Heap
• IntervalHeap
• LinkedList
• List
• Queue
• SkipList
• SortedList
• Stack
• TreeBidiMap
• TreeMap
• TreeMultiMap
• TreeMultiSet
• TreeSet

• Bitset
• Deque
• HashBidiMap
• HashMap
• HashMultiMap
• HashMultiSet
• HashSet
• Heap
• IntervalHeap
• LinkedList
• List
• Queue
• SkipList
• SortedList
• Stack
• TreeBidiMap
• TreeMap
• TreeMultiMap
• TreeMultiSet
• TreeSet

Currently, bitset always uses a power of 2 size. If you want to only use 100 bits, all operations are based on 128 and might be incorrect. Operations on the last word must always be checked if all of its bits are being used.

Feature Request Template

What is the nature of this request?

• Restructure the main library include file to selective include only what you need

Is your feature request related to a problem? Please describe.

Trying to use this library in a 32bit Cortex M0 microcontroller. Including macro_collections.h is overkill and gives compile error for stuff that I don't even need (multithreading, etc.)

Describe the solution you'd like

I have produced a simple header file - for instance, macro_defs.h - where only the global macros are defined. Then it is just a matter of including the needed header files in your code, like:

#include "cmc_list.h"
#include "ext_cmc_list.h"
#include "utl_futils.h"
#include "macro_defs.h"

The existing macro_collections.h can include this file as the very last and we have the same functionality as before

Includes testing

• Callbacks
• Alloc
• Flags
• Ftables

Feature Request

What is the nature of this request?

• Change in source code details (names of variables, functions, parameters, etc)

Is your feature request related to a problem? Please describe.

cmc log functions from log.h, cmc_log_trace for example, are defined as:

#define cmc_log_trace(fmt, ...) cmc_log(CMC_LOG_TRACE, __FILE__, __func__, __LINE__, fmt, ##__VA_ARGS__)

##__VA_ARGS__ is supported by most compilers, but still non-standard, -pedantic issues a warning about it.

C23 solves the problem by introducing the __VA_OPT__ preprocessor. So this is the C23 solution:

#define cmc_log_trace(fmt, ...) cmc_log(CMC_LOG_TRACE, __FILE__, __func__, __LINE__, fmt __VA_OPT__(,)  __VA_ARGS__)

Full C23 support is yet to be available, so not a high priority.

Describe the solution you'd like

Detect the version via __STDC_VERSION__, and use the standard solution if C23 or later.

This library is constantly receiving new updates that are disruptive and I believe that by now all examples no longer compile. This will eventually be fixed but only when all collections have the functions in the scope defined by the TODO file and the unit tests are complete.

HashBidiMap iterators are still not implemented properly. Currently you can only iterate over the keys. Decide whether:

• One iterator containing both IterKey and IterVal
• Separate iterators for IterKey and IterVal*

See which approach is most compatible with CMC_FOREACH and have a similar look to the other iterators.

What is the nature of this request?

• New functionalities

Is your feature request related to a problem? Please describe.

I'm working with sprites on a game. I'll create, destroy and loop the sprites over the frame a bunch of times, and sort them only at the end, before rendering. SortedList is not suited for this since it might sort the list automatically unnecessarily. I would much rather have a list.h and manually sort at the appropriate time.

Describe the solution you'd like

have a sort function for list.h

• Called in every function, passing down a few parameters like the first one e.g. self or _list_ and the function name
• Called at the end and at the start, where both can be toggled separately
• Continue to be optional to not incur performance overhead

Can I suggest we parse the deallocator to the "new" function and hold it in the container, thus avoiding having to parse it to every "pop", "remove" and "clear" function.

The library should:

• Allow fkey and fval parameters to be null
• Check in _new() for required functions
• Check if the struct and if the functions are null before every usage and report errors instead of crashing

Thanks for working on C-Macro-Collections!

What is the nature of this request?

• Change in standards

Is your feature request related to a problem? Please describe.

you can easily make a new list with

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#include <cmc/ds/list.h>

since cmc/ds/list.h includes the #include "cmc/list/code.h", you can't just place the above snippet on a header, because it would define each function multiple times.

In order to share declarations, you need to do something like this

file.c

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#include <ds/cmc/list/code.h>
#include <ds/cor/undef.h>

file.h

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#include <ds/cmc/list/struct.h>
#include <ds/cmc/list/header.h>
#include <ds/cor/undef.h>

Describe the solution you'd like

I think it would be much better if we could do this

file.c

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#include <ds/cmc/list/code.h>
// code includes undef.h

file.h

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#include <ds/cmc/list.h>

What do you think? It would be a breaking change, I can open a PR if you agree it's a good change.

Alternatves

Maybe this? I prefer the above
file.c

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#define SOURCE
#include <ds/cmc/list.h>

file.h

#define V struct my_struct
#define PFX my_struct
#define SNAME my_struct_list
#include <ds/cmc/list.h>

Feature Request Template

What is the nature of this request?

• New functionalities

Is your feature request related to a problem? Please describe.

I think SNAME, the name of the collection, is a reasonable PFX. So maybe if PFX is not set, we could assume SNAME=PFX?

Describe the solution you'd like

#ifndef PFX
#define PFX SNAME
#endif // PFX

With the release of 1.8, examples and benchmarks are once again outdated.

• Remake examples
• Remake benchmarks

Line 299, I think it should be
memmove(list->buffer, list->buffer + 1, (list->count - 1) * sizeof(V));

Line 311, I think it should be
memmove(list->buffer + index, list->buffer + index + 1, (list->count - index - 1) * sizeof(V));

I also suggest calling PFX##_pop_at(list, 0) inside PFX##_pop_front.
Also, all of the pop functions should be calling deallocators

• Bitset
• Deque
• HashBidiMap
• HashMap
• HashMultiMap
• HashMultiSet
• HashSet
• Heap
• IntervalHeap
• LinkedList
• List
• Queue
• SkipList
• SortedList
• Stack
• TreeBidiMap
• TreeMap
• TreeMultiMap
• TreeMultiSet
• TreeSet

cmc_string is used by to_string functions and it is currently not ideal. How to replace it?

• Allocate a char *
• Print it straight to a FILE *

Thanks for working on C-Macro-Collections!

What is the nature of this request?

• Change in source code details (names of variables, functions, parameters, etc)

Is your feature request related to a problem? Please describe.

I think it would be less typing if we moved everything out of cmc folder. We could then avoid adding a bunch of -I flags on our build systems. It's also pointless to have a src/ folder, since there's no include/ folder.

Describe the solution you'd like

Remove the src folder, and remove the cmc/cmc/ folder, moving everything inside of it out one level.
Instead of

src/
   cmc/
       cor/
       cmc/
          list/
            code.h
       list.h

Do something like

cmc/
   cor/
   list/
     code.h
   list.h

We would then do something like -I.

and include like this

#include <cmc/list.h>
#include <cmc/list/code.h>

At this point of the project if feels like the ext collections are growing quite big and the idea of having half of the collections in one folder and the other half in another is quite unnecessary. So eventually merge all collections into the cmc folder and leave dev and sac.

• Allows to switch between hash based and tree based data structures (e.g. AVL vs RBT, Round Robin vs Hopscotch, etc)

Tests should be based on heap allocated of char * and not size_t to test against NULL pointers and memory leaks.

Basic implementation and tests

• Bitset
• Deque
• HashBidiMap
• HashMap
• HashMultiMap
• HashMultiSet
• HashSet
• Heap
• IntervalHeap
• LinkedList
• List
• Queue
• SkipList
• SortedList
• Stack
• TreeBidiMap
• TreeMap
• TreeMultiMap
• TreeMultiSet
• TreeSet

Feature Request Template

What is the nature of this request?

• New functionalities

Is your feature request related to a problem? Please describe.

Compiling on windows/mingw requires each symbol to be exported, with something like __declspec(dllexport), libraries usually have something like this, example from PHYSFS

#if defined(PHYSFS_DECL)
/* do nothing. */
#elif defined(PHYSFS_STATIC)
#define PHYSFS_DECL   /**/
#elif defined(_WIN32) || defined(__OS2__)
#define PHYSFS_DECL __declspec(dllexport)
#elif defined(__SUNPRO_C)
#define PHYSFS_DECL __global
#elif ((__GNUC__ >= 3) && (!defined(__EMX__)) && (!defined(sun)))
#define PHYSFS_DECL __attribute__((visibility("default")))
#else
#define PHYSFS_DECL
#endif

or at least expose a LIB_DECL, which can be defined by the consumer

Describe the solution you'd like

prefix every function declaration on header.h with CMC_DECL, and have something like the above example on core.h

Feature Request Template

What is the nature of this request?

• New functionalities

Is your feature request related to a problem? Please describe.

I have a localization system, I compile a human-readable format into a binary one, and load each string into a hashmap depending on the selected language. Since I know each string key ahead of time, I could hash them offline, and increase performance when loading new strings.

Describe the solution you'd like

A way to insert an already hashed Key into a hashmap/hashset

• When a collection pops or removes elements from it, without returning it to the user, check for ftable->free and free the element

Feature Request Template

What is the nature of this request?

• Change in standards

Is your feature request related to a problem? Please describe.

CMC_EXT_INIT just adds two new functions, they should be there by default and save everyone the hassle. Unused functions can be easily stripped from release builds.

Describe the solution you'd like

remove CMC_EXT_INIT, have _init functions by default.

Feature Request Template

What is the nature of this request?

• Change in standards

Is your feature request related to a problem? Please describe.

I always use CMC_EXT_INIT. So I generate a collection like this

#define V struct timeline
#define PFX timeline_list
#define SNAME timeline_list
#define CMC_EXT_INIT
#include <lib/ds/list/code.h>
#include <lib/ds/list/ext/code.h>
#include <lib/ds/cor/undef.h>

which is very verbose, I also need a copy of this on the header in order to share declarations.

Describe the solution you'd like

Ditch the ext/ folder, e.g· merge everything inside list/ext/code.h into list/code.h, list/header.h etc... and activate the feature with a macro. Like this

#define V struct timeline
#define PFX timeline_list
#define SNAME timeline_list
#define CMC_EXT_INIT
#include <lib/ds/list/code.h>
#include <lib/ds/cor/undef.h>

What is worth being an extension or included by default is another discussion, but for this particular case of CMC_EXT_INIT #37

Feature Request Template

What is the nature of this request?

• New functionalities

Is your feature request related to a problem? Please describe.

Currently, if you want to add an element then get it's reference, you need to first call _push_back, then _get_ref(_count(list) - 1), _back returns a copy, so we can't use that. This is quite verbose.

Describe the solution you'd like

it would be useful if we had an _push_back_ref, function, which is like _push_back, but it returns the pointer instead of a bool.

Maybe a _back_ref

Not sure if expanding the API surface is worth it, but it might be worth considering.

Bug Report template

Describe the bug

Compiling without CMC_CALLBACKS support, generates the following warning with -pedantic:

In file included from /cmc/list.h:84:
/cmc/list/struct.h:43:20: warning: extra ';' inside a struct [-Wextra-semi]
        CMC_CALLBACKS_DECL;

Without CMC_CALLBACKS, CMC_CALLBACKS_DECL is expanded to nothing, so CMC_CALLBACKS_DECL; indeed produces a stray semicolon,

Expected behavior

Perhaps suppress the warning somehow with #pragmas, or something like this

struct {
...
#ifdef CMC_CALLBACKS
     cmc_callback callbacks:
#endif
}

Thanks for working on CMC!

What is the nature of this request?

• Change in source code details (names of variables, functions, parameters, etc)

Is your feature request related to a problem? Please describe.

some functions do not modify the collection, like the _count functions, these should have the collection parameter marked as const

Describe the solution you'd like

functions like _count, _get (except for sorted lists), _index_of, _contains should have the collection marked as const

Not a breaking change as C auto casts to const

CMC_SAC makes a collection to have a fixed buffer size, possibly avoiding allocations, but the _new() function allocates the struct anyway. This can be good if the buffer size is huge and wouldn't fit on the stack.

• Find a way to avoid having malloc, free, etc. in the code whe CMC_SAC is defined
• Decide what to do with _new() and _init()

Overflow warnings in utl_futils.h

Describe the bug

Compiling the utl_futils.h header on a 32bit Cortex M0 ARM gives overflow warnings for hash math, since 64bit integer math is apparently not supported.

How to Reproduce

Steps to reproduce the behavior:

1. Setup a cross-compiling environment for a ARM M0 Cortex (i.e Raspberry Pi Pico)
2. compile the main example.c
3. See the warnings

Expected behavior

Somehow this 64bit math should not be included in this case.

Screenshots

[build] [1/2  50% :: 0.097] Building C object console/CMakeFiles/console.dir/console.c.obj
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h: In function 'cmc_str_hash_java':
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h:413:28: warning: conversion from 'long long unsigned int' to 'size_t' {aka 'unsigned int'} changes value from '1125899906842597' to '4294967269' [-Woverflow]
[build]   413 |     size_t hash = UINT64_C(1125899906842597); // prime
[build]       |                            ^~~~~~~~~~~~~~~~
[build] In file included from /home/rafa/repos/own/pico/pico-lipophot4c/src/console/console.c:16:
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h: In function 'cmc_str_hash_murmur3':
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h:428:13: warning: right shift count >= width of type [-Wshift-count-overflow]
[build]   428 |     x ^= (x >> 33);
[build]       |             ^~
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h:430:13: warning: right shift count >= width of type [-Wshift-count-overflow]
[build]   430 |     x ^= (x >> 33);
[build]       |             ^~
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h:432:13: warning: right shift count >= width of type [-Wshift-count-overflow]
[build]   432 |     x ^= (x >> 33);
[build]       |             ^~
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h: In function 'cmc_str_hash_murmur3_variant':
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/lib/C-Macro-Collections/include/c_macro_collections/utl_futils.h:447:13: warning: right shift count >= width of type [-Wshift-count-overflow]
[build]   447 |     x ^= (x >> 33);
[build]       |             ^~
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/console/console.c: In function 'console_init':
[build] /home/rafa/repos/own/pico/pico-lipophot4c/src/console/console.c:52:80: warning: initialization of '_Bool (*)(FILE *, int)' from incompatible pointer type '_Bool (*)(FILE *, int32_t)' {aka '_Bool (*)(FILE *, long int)'} [-Wincompatible-pointer-types]
[build]    52 |     struct int_list *list = intl_new_custom(32, &(struct int_list_fval){.str = cmc_i32_str, NULL}, &custom_allocator, NULL);

Please complete the following information:

• Type: [e.g. src, tests, examples, benchmarks]
• OS: linux, cross development for raspberry pi pico
• Compiler GCC
• Compiler Version 10.3.1 arm-none-eabi

Additional context

...and that needs to change.

• hashbidimap
• hashmultimap
• hashmultiset
• hashset
• treemap
• treeset