In full-fat C++ systems it's preferable to use STL containers for arrays instead of using hacky C-style pointers to simulate them. On embedded devices STL might be considered too much bloat though.
This is the common way to define such a macro. It does not work if you pass arrays around, of course - they decay into pointers when you pass them as function pointers (unless your array is wrapped in a struct).
Well, "type-safe" if you ignore the little fact that the normal indexing operator "[]" is not bounds checked. :-)
In the C++ library, it would be nice if the indexing operator most people would use by default, "[]", was the bounds checked one and the alternative indexing operator, "at()", was the non-bounds checked one. That way, you would have to do something unusual in your code to turn _off_ bounds checking instead of having to do something unusual in your code to turn _on_ bounds checking...
Simon.
--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Even better (for me) would be if there were a define that could turn bounds checking on -- that way I could do testing with bounds checking on, and release (presumably faster) code with bounds checking off.
--
Tim Wescott
Control systems, embedded software and circuit design
Agreed. However, that would violate the C/C++ mantra that those who do not want a feature should not have to pay for it.
Strict bounds checking - particularly checks per dimension as opposed to a single check that the overall target lies within the array - would break some existing code. [For the same reasons that pointers may be one-of before or after the array, and iterators may be considered to point "between" elements.]
Beyond the bounds, you're looking at something which is probably not the type you think you're looking at. That is pretty-much the definition of "not type-safe".
Then it would again be "bloat" compared to a regular array...
As far as I understand, such a thing would be a legal C++ implementation (bounds violations are undefined behaviour, which means an implementation could define it as "raises an exception" or "writes a coredump"), so bug your compiler maker until they implement that :-) (Don't we already have some "checked" STL implementations?)
We're talking about the C++ STL "array" class, which is defined as having a certain size, with no guarantees about what lies outside the range of the actual data.
Bounds checking on the C '[]' operator would probably break some code, for the reasons you mention.
--
Tim Wescott
Control systems, embedded software and circuit design
I use .at() all the time now. Every time I've tested it both ways in a real program, the checks didn't make any noticible slowdown. It could be that the compiler is able to hoist them out of lots of loops.
Just for my curiosity, why would you want to do that? You don't need it for iteration.
Maybe to make a same-sized temporary array? But then it would make sense to name the array type, and use that type. But maybe for a same-sized array of a different element type. But I think I could make a template to do that.
And if you do need it, if the array declaration is in scope, I assume that it was defined with some named literal dimension, so why not used that?
I could not tell you which versions of which compilers support this, but in some toolchains, it's possible to specify the size of an array being passed - void p(char x[256])... .
I may be thinking of compiling C code using a C++ compiler, or it may be in C99. I don't think it's in C89/ANSI.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.