So there's no way to have a fixed-size bounds-checked arrays in C as far as I know.
The *standard way* to do this in C++ is std::array which is templatized std::array<type, max_size> as in std::array<int, 6>.
With overloaded operator[] which does bounds-checks in debug (at least in MS implementation, GCC's impl doesn't do it by default I think).
DOOM-3-BFG has a idArray which is essentially the same thing with less bullshit.
The killer question here is simple, how hard does this tank the compile times if used in the *large*?
Because for the most part, all that's ever needed is whole bunch of fixed sized arrays.
And everything else is built on top of it (open-addressed hashmaps, packedarrays, freelists).
Every new std::array<Tulip, 100> will instantiate a new template and shit out a ton of code, and in a code-base of reasonable size this will take forever to compile, right?
The *standard way* to do this in C++ is std::array which is templatized std::array<type, max_size> as in std::array<int, 6>.
With overloaded operator[] which does bounds-checks in debug (at least in MS implementation, GCC's impl doesn't do it by default I think).
DOOM-3-BFG has a idArray which is essentially the same thing with less bullshit.
The killer question here is simple, how hard does this tank the compile times if used in the *large*?
Because for the most part, all that's ever needed is whole bunch of fixed sized arrays.
And everything else is built on top of it (open-addressed hashmaps, packedarrays, freelists).
Every new std::array<Tulip, 100> will instantiate a new template and shit out a ton of code, and in a code-base of reasonable size this will take forever to compile, right?
Edited by pragmatic_hero
on
Reason: Initial post
Macros?
Or C99 functions with static size arguments if arrays are fixed size.
Or C99 functions with static size arguments if arrays are fixed size.
Edited by Mārtiņš Možeiko
on
mmozeiko
Macros?
Or C99 functions with static size arguments if arrays are fixed size.
What do you mean?
Edited by pragmatic_hero
on
Something like this:
As for C99, it actually seems static array sizes in arguments work only for optimization, no warnings for bounds checking... :(
1 | #define GET(arr, i) (i < get_array_size(arr) ? fatal_assert() : arr[i]) |
As for C99, it actually seems static array sizes in arguments work only for optimization, no warnings for bounds checking... :(
Simple use of templates like you would have with std::array barely affect compile times in any measurable way.
It's the overuse where everything is a template instantiation that tanks compile times
It's the overuse where everything is a template instantiation that tanks compile times
ratchetfreak
Simple use of templates like you would have with std::array barely affect compile times in any measurable way.
It's the overuse where everything is a template instantiation that tanks compile times
But std::array is exactly that. Every array is a template instantiation. EVERY ARRAY.
It's not like a container where the types might overlap. Since the signature is Type x Size, its unlikely to ever overlap and reuse anything.
C++ tanks compile times by design. Not necessary from over-use of anything.
It's hard to predict over lifetime of a project how something seemingly innocuous might tank it.
The whole C++ standard library tanks compile times.
Using C++ as per Bjarnie and "Modern C++" would be std::vector (20k) + std::string (20k) + std::map(20k). There 60k lines out of nothing. Multiplied by meagre 10 compilation units, half a mil LoC.
Not that far fetched to assume that every new std::array instance would be like shitting out 300 loc compile time wise. 10 fixed size arrays? 3000 LoC! Hyperbole? I hope so.
Edited by pragmatic_hero
on