Possible to rename/alias the well-known CC types? (like vec, list, map, omap etc)

[metaleap]

Just discovered CC and am delighted with the approach and the attention paid here also to non-code things (readme, articles).

I'm interested in whether type renames are possible. Not just because I usually typedef aliases that begin with an uppercase letter, but also because: whenever I'm in a codebase that has mathematical vector types (as in Vec2, Vec3, Vec4, as in 2d/3d gfx), I'm always minorly irked by languages/libs that choose to name dynamically-allocated-resizable-contiguous-homogenous lists "vectors". Of course C++ stdlib is another perp here. So I might just be inclined to "rename"/alias CC's cc_vec to something like List, cc_list to LinkedList (or whatever), etc.

None too critical but just curious anyway.. given whatever macro magic occurs I'm pretty sure I won't even have to try a naive typedef vec List here 😁

[JacksonAllan]

Glad you're enjoying the library!

None too critical but just curious anyway.. given whatever macro magic occurs I'm pretty sure I won't even have to try a naive typedef vec List here 😁

Right, typedef will only work with a complete CC type (i.e. including the key/element type/s) because cc_vec, cc_list, and so on are macros that generate a type based on their arguments. So you can, for example, do typedef cc_vec( int ) IntList; but not typedef cc_vec List;. Of course, if you're typedefing every container and key/element type combination, you would probably be better off just using a library based around manually instantiated pseudo-templates (I like STC in particular).

But you can always define your own macro aliases for CC macros, e.g. #define List cc_vec.

whenever I'm in a codebase that has mathematical vector types (as in Vec2, Vec3, Vec4, as in 2d/3d gfx), I'm always minorly irked by languages/libs that choose to name dynamically-allocated-resizable-contiguous-homogenous lists "vectors"`

I do plan on reconsidering some of the macro names that CC uses, as discussed here. However, that's at least two versions away (the upcoming version will mostly just add dynamic strings and won't include any breaking API changes). And although I share your sentiment regarding "vector", I'm reluctant to change that name because it's probably the most familiar name for that type of container for C programmers (because of the C++ standard library).

[metaleap]

But you can always define your own macro aliases for CC macros, e.g. #define List cc_vec.

Yeah sometime later I had a real "but of course" face-palm moment when the above occurred to me, the simple & sufficient solution that I had seemingly somehow inexplicably forgotten about 😁 indeed that alone will already do.

Thanks for pointing me to STC, will keep it in mind should my upcoming CC adoption attempt prove irksome for some reason or other.

Which reminds me of a curiosity that might be pertinent — as a placeholder lib (until "the choice" would be decided on more in-depth-ly at a later future point) I used this so far in a tutorial project where I only needed vectors so far. I encountered the issue where the vector add and insert methods use realloc but I used them for lists/vectors of structs that contain fields of an aligned-struct type leading to segfaults / UBSan alerts (the gritty details here). I had to add to that temporary container lib an alternative secondary add method impl, which instead of reallocing, does malloc/memcpy/free — with CC is this sth I'd have to patch in, or already covered / a non-issue, or you'd be open to realloc-free secondary implementations of methods that ordinarily use realloc?

"Just provide an alternative malloc/realloc impl to the lib" might not quite cut it insofar that one might want to keep the usual normal realloc-using calls around wherever they don't blow up, using the secondary (necessarily suboptimal vs native realloc) alternative ones only for those struct vectors that'll need it.

Conundrum perhaps — maybe it's just out of scope for "a generic container library" and to be hand-treated, curious about your views on this, at your leisure =)

[JacksonAllan]

Unfortunately, CC doesn't support over-aligned types. I should probably include this detail in the documentation. Trying to adapt the library to work with those types would be very difficult for two reasons:

• CC's support for custom allocators is pretty basic. You can define a custom allocator, but it applies to all containers (you can toggle it on and off, but wrapping every potentially reallocating API call with #define CC_REALLOC aligned_32_realloc/#define CC_FREE aligned_32_free and #undef CC_REALLOC/#undef CC_FREE seems cumbersome and error-prone). Also, the custom allocator API is the same as the realloc/free API, whereas an aligned_realloc function would need an extra original_size parameter so that it can memcpy the original data to a new buffer allocated with aligned_alloc (or else you'd need prefix allocations with a custom allocation-metadata header). A future version of CC might introduce more versatile per-type allocator customization using a similar API to the per-type hash, comparison, and destruction functions.

• For the sake of memory and performance, CC stores multiple kinds of data in each allocation and relies in various places on the assumption that no type has an alignment greater than cc_max_align_ty (a 16-byte aligned type on MSVC and a typedef for max_align_t on other compilers). For example, each container prefixes its data with a header whose size is a multiple of alignof( cc_max_align_ty ), without any extra padding bytes. So even if you were to use the custom allocator API to provide a realloc that guarantees 32-byte alignment, your data would still be misaligned. The library could be modified to address this issue, but it would be quite a task.

Over-aligned types might pose problems for any container library you try. However, the aforementioned STC does appear to allow a per-complete-container-type realloc function with an original-size parameter, thereby addressing the first point above. I don't know whether over-aligned types could cause other issues internally, though (@tylov?).