Dimension of a matrix

I just put the following into yet another c/c++ file:

#define DIM(x) (sizeof(x) / sizeof(*x))

It calculates the number of elements in the array x (assuming that x is, indeed an array).

Is there anything in the standard libraries that does this easy and obvious thing?

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

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.

Reply to
Paul Rubin

std::array should involve no "bloat" whatsoever. It's basically a type-safe wrapper around C arrays, with the dimension easily available.

Reply to
David Brown

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).

Reply to
David Brown

I know what I'm doing. I just want to know if the oft-used #DIM construct has ever been formalized.

--
Tim Wescott 
Control systems, embedded software and circuit design 
 Click to see the full signature
Reply to
Tim Wescott

The short answer is "no".

Reply to
David Brown

Thanks.

--
Tim Wescott 
Control systems, embedded software and circuit design 
 Click to see the full signature
Reply to
Tim Wescott

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
Reply to
Simon Clubley

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 
 Click to see the full signature
Reply to
Tim Wescott

The types are safe - it's just the ranges that are not...

Yes, I think that would be a sensible idea. In many cases, the compiler can remove the run-time overhead of the checks.

Reply to
David Brown

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.]

George

Reply to
George Neuner

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".

Reply to
Clifford Heath

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?)

Stefan

Reply to
Stefan Reuther

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 
 Click to see the full signature
Reply to
Tim Wescott

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.

Reply to
Paul Rubin

It might and it might not be. There are cases where a (hacky C-style) library may expect a contiguous block of some type.

--
Les Cargill
Reply to
Les Cargill

I have added functions to systems that return yes/no to the question "is this index in range?". Those can then be disabled after test.

It'd be nice to have this be built in, but it's hardly necessary.

--
Les Cargill
Reply to
Les Cargill

Op 24-Mar-17 om 00:17 schreef Tim Wescott:

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?

Wouter "Objects? No Thanks!" van Ooijen

Reply to
Wouter van Ooijen

It has not been formalized to my knowledge. Which is curious.

--
Les Cargill
Reply to
Les Cargill

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.

--
Les Cargill
Reply to
Les Cargill

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.