Semi-typeless dynamic array, feedback wanted

[solar kite]

https://gist.github.com/CoffeeCatRailway/c55f8f56aaf40e2ecd5c3c6994370289
I'm fairly new to C, as a small test/way to get started I made a dynamic array object.
It works for what I need & want to work on it further, just want to know in what ways I could improve or expand it.

[tiny hull]

Just out of curiosity? Why are you diving into macro magic if you're new in C?
Also if you want dynamic, but fixed, types, then you should probably try C++ where all of that would just be

std::vector<int>;
std::vector<float>;
std::vector<double>;
etc...

What I would do in any case however is to scrap the macro and replace the generic type with a void *. You'll delegate memory (de-)allocation for that void * to the caller, but have an easy generic function that way, similar to how qsort work

!man qsort

[unreal rain]

man7

qsort(3)

qsort, qsort_r - sort an array

Synopsis

#include <stdlib.h>

void qsort(void *base, size_t nmemb, size_t size,
           int (*compar)(const void *, const void *));
void qsort_r(void *base, size_t nmemb, size_t size,
           int (*compar)(const void *, const void *, void *),
           void *arg);

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

qsort_r():
    _GNU_SOURCE

[solar kite]

I forget why I chose macros instead of void*, something about void pointer oddness
Also I chose C because I don’t like C++

It’s strange

Also making a list/vector thing was good practice to get used to things

I did find someone else’s attempt at this using void* so I’m thinking of redoing it somehow

[quasi plaza]

C++ would be better for this. There are legitimate reasons against using c++, but "I don't like it" isn't one of them. If you insist on using C, use and external code generator.

[solar kite]

I understand what you mean, but I'm more so doing this to see how far I can push myself & C
Also, not sure what you mean by external code generator

[quasi plaza]

• There's no "namespace"
• The storage representation isn't configurable. Not all arrays require size_t
• capacityIncrement doesn't make much sense. Do you not want to amortize the cost of growing the array?
• Declaration is coupled to definition. Can't declare in one translation unit to be used in another. The funcions are all static
• It's coupled to stdio.h for bad reasons
• It exits when allocation fails. Should be configurable.
• I got pretty far into reading this before I realized array_<T>_t is contiguous with the elements. Use a flexible array member instead. array_<T>_t::array isn't required.
• The allocator isn't configurable.
• #120 memcpy is undefined for overlapping objects.
• #145 I assume this isn't actually going to be here in production.

[quasi plaza]

Rather than a cumbersome C preprocessor, use a more mature code generation tool

[quasi plaza]

None of these operations depend on anything beyond sizeof(type) or alignof(type). The typed interfaces could forward to a type-erased implementation.

[tiny hull]

The storage representation isn't configurable. Not all arrays require size_t
What do you mean by not all arrays require size_t? size_t is merely defined like so:
size_t [is an integer that] can store the maximum size of a theoretically possible object of any type (including array).

It exits when allocation fails. Should be configurable.
I'd say that as long as it's properly documented that would be justifiable and could be a deliberate design decision (I know it isn't in this case, but just saying that it could be)

Declaration is coupled to definition. Can't declare in one translation unit to be used in another.
This is actually one of my biggest icks with the whole thing.

No clue what you want to tell us with the last 2 bulletpoints.

[quasi plaza]

size_t is the maximum. On a 64 bit system it can be 8 bytes, which is often excessive.

https://gist.github.com/CoffeeCatRailway/c55f8f56aaf40e2ecd5c3c6994370289#file-array-h-L120 line 120, this memcpy is undefined behavior

https://gist.github.com/CoffeeCatRailway/c55f8f56aaf40e2ecd5c3c6994370289#file-array-h-L145 line 145, presumably this isn't actually part of a production include

[tiny hull]

With all due respect, that's completely negligible.
Register sizes on a 64-bit system are, well, 64-bit, so it's still just a single register load either way.

[quasi plaza]

Then you must also have the position that the extra pointer is negligible.

[modern shadow]

You can write C++ in C style if you prefer, using only the features you need (such as templates)

[solar kite]

I understand that, but I see C & C++ as two distinct languages.
The syntax is different, private/public is separated in odd ways and header/source files don't seem to be all that separate from one another in it. It's not C, it's C++ or just something different.

Really, I just want to use C and learn from it.

Anyway, back to the dynamic array. Thanks for the feedback I took some pointers (ha C joke) & found another implementation to learn from that isn't bound in one long define