Hi,
I know I’m late to this email thread topic, but email’s free so why not…
I saw some questions on if the indexed_array would be useful/used.
I don’t have a crystal ball, but I can tell you we have a similar type in my employer’s codebase, and we use it. Like indexed_array, ours is a std::array, all done at compile time, etc.
Ours is purely for enum-based indexing, and only for scoped enums that start at value 0 and increase sequentially – i.e. contiguous, no “holes”. We happen to be able to verify that property of enums at compile-time, and can static_assert that it’s true, so ours just ends up doing a static_cast under-the-hood. (I can’t quite tell what indexed_array does in the end, since it also deals with non-contiguous index values.)
Like indexed_array, ours also allows the user to initialize entries, which was probably the hardest aspect of writing our own.
Had Boost had the indexed_array when we wrote ours, it is extremely likely we would have used Boost’s instead. (we use Boost a lot)
I’m not sure we would have ever used the non-contiguous aspect. We have plenty of non-contiguous enums, but no one’s ever clamored for array support for them. (of course that could just be a self-fulfilling prophecy, since we don’t already have such an array) It definitely appears to make it more complicated, from my quick perusal of indexed_array on github.
To give you some numbers, we’re what I consider a medium-sized codebase, and there are well over 100 different uses of this array in our codebase. That’s approximately a 15:1 ratio of enum types to our array types – i.e., for every 15 enum types in our codebase, we have one of these array types. It surprises me that it’s so many of these arrays, but that’s what the numbers show. Around 1/3rd of them are purely in test code, the rest production.
-hadriel
From: Boost