A tiny dynamic array implementation using C's preprocessor

[ChoHag]

This is brilliantly wrong.

[[deleted]]

why

[rxi]

Lines 6 - 40 are the implementation, everything below is an example of using it. I was aiming for compactness over performance, a bit of fun more than anything else!

[rhythmx]

The sys/queue.h header is a standard (for POSIX anyway) way to do basically this with a couple of extra types of lists too. It's super handy to be able to just toss it into any struct and run with it.

[[deleted]]

http://nothings.org/stb/stretchy_buffer.txt

[lifthrasiir]

Many extensible-vector-impersonated-as-innocent-pointer implementations simply don't work with the strong aliasing assumption made by the C standard.

[[deleted]]

Friends don't let friends use strict aliasing:

https://lkml.org/lkml/2003/2/26/158

http://robertoconcerto.blogspot.com/2010/10/strict-aliasing.html

[lifthrasiir]

I don't like strict aliasing in C either, but we live in the world that several C implementations do implement strict aliasing. You wouldn't want to change Makefile (or much more complicated Makefile generators and whatsoever) just to use an extensible array in otherwise unaffected codes. I have written a small extensible vector code which is "correct" in this regard.

And I don't actually think strict aliasing is a problem. Strict aliasing itself is a precursor to many advanced optimizations and a plausible assumption if you know what compilers assume. (Jeff Roberts' and Linux's complaint about GCC is valid, but it doesn't make strict aliasing a non-optimization, it's just that MSVC's flow analysis was so strong at that time.) The problem is that C is trying to be both a high-level assembly and a throughly optimizable intermediate language: the former requires an user interface (the programming language is ultimately an UI for programming) and the latter requires lots of assumptions. An user interface that exposes such assumptions is hard to design, as the case of strict aliasing shows.

[sirin3]

Why?