> You could fix this with some kind of module system but this would mean that you'd always need the whole module which may be multiple megabytes (...) You don'

> You could fix this with some kind of module system but this would mean that you'd always need the whole module which may be multiple megabytes (...) You don't need the whole module. You need the module's interface to compile anything that depends on the module. Of course, type sizes and alignments must be a part of the interface in a C-like language. But “exporting sizes and alignments” doesn't necessitate “exporting the entire internal representation of the type”, cf. Rust. > (...) vs a .hpp which is generally small (or a forward-declaration which is negligible). You can't forward-declare type sizes and alignments. This is precisely why you must pay the aforementioned indirection tax. > Regarding (2), C11 has some generics nowadays Which is just a compile-time switch statement on types. You still have to write separate implementations of generic algorithms for every concrete type on which you want to use them. > (and for more complex stuff you'd be much better served by c++ templates) The pain associated to using C++ templates is exactly what happens when you try to do generic programming in a language with no support for abstract type specifications.