3 ms·
> I don't have data on this but I feel that posix_memalign might be more widely supported than aligned_alloc. Possibly. IIRC Microsoft's CRT does not support a
by el_pollo_diablo 3y ago
> I don't have data on this but I feel that posix_memalign might be more widely supported than aligned_alloc.
Possibly. IIRC Microsoft's CRT does not support aligned_alloc() because their implementation of free() cannot deal with extended alignment requirements, so they have separate functions for aligned (de)allocation. To be fair, they probably do not support posix_memalign() either.
> it becomes a serious pain to go through all allocations and figure out a reasonable alignment value
Sure, you can pass _Alignof(max_align_t) in almost all cases, or have generic (= not reimplemented by each allocator) convenience wrapper functions that do that for you. If you want to pass the least restrictive alignment in all cases, you can enlist the help of a macro, but this is a bit more awkward. For instance:
#define ALLOC(ptr, size) ((ptr) = alloc(_Alignof(typeof(*(ptr))), (size)))
foo_t *p;
ALLOC(p, 42 * sizeof *p);
(Note that this uses the typeof() operator, which should become standard with C23.)
- tlb 3y agomax_align_t is only the max for scalar types, typically 8 or 16 bytes. But often math-intensive code wants 16 or 32 byte alignment for float arrays, to enable SIMD operations.
- el_pollo_diablo 3y ago> max_align_t is only the max for scalar types, typically 8 or 16 bytes. But often math-intensive code wants 16 or 32 byte alignment for float arrays, to enable SIMD operations. Indeed, but _Alignof(max_align_t) is a good compromise for a default alignment requirement in an allocator interface, which is what eqvinox calls for. Standard C does exactly that: malloc(), realloc(), and calloc() promise that they satisfy _Alignof(max_align_t), but nothing stricter. To reach for extended alignment requirements, your only standard tool is aligned_alloc().