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 http://www.wescottdesign.com I'm looking for work -- see my website!
Dimension of a matrix
Started by ●March 23, 2017
Reply by ●March 24, 20172017-03-24
Tim Wescott <seemywebsite@myfooter.really> writes:> Is there anything in the standard libraries that does this easy and > obvious thing?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 by ●March 24, 20172017-03-24
On 24/03/17 07:21, Paul Rubin wrote:> Tim Wescott <seemywebsite@myfooter.really> writes: >> Is there anything in the standard libraries that does this easy and >> obvious thing? > > 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. >std::array should involve no "bloat" whatsoever. It's basically a type-safe wrapper around C arrays, with the dimension easily available.
Reply by ●March 24, 20172017-03-24
On 24/03/17 00:17, Tim Wescott wrote:> 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).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).> > Is there anything in the standard libraries that does this easy and > obvious thing? >
Reply by ●March 24, 20172017-03-24
On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote:> Tim Wescott <seemywebsite@myfooter.really> writes: >> Is there anything in the standard libraries that does this easy and >> obvious thing? > > 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.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 I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●March 24, 20172017-03-24
On 24/03/17 17:05, Tim Wescott wrote:> On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote: > >> Tim Wescott <seemywebsite@myfooter.really> writes: >>> Is there anything in the standard libraries that does this easy and >>> obvious thing? >> >> 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. > > I know what I'm doing. I just want to know if the oft-used #DIM > construct has ever been formalized. >The short answer is "no".
Reply by ●March 24, 20172017-03-24
On Fri, 24 Mar 2017 17:33:58 +0100, David Brown wrote:> On 24/03/17 17:05, Tim Wescott wrote: >> On Thu, 23 Mar 2017 23:21:07 -0700, Paul Rubin wrote: >> >>> Tim Wescott <seemywebsite@myfooter.really> writes: >>>> Is there anything in the standard libraries that does this easy and >>>> obvious thing? >>> >>> 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. >> >> I know what I'm doing. I just want to know if the oft-used #DIM >> construct has ever been formalized. >> >> > The short answer is "no".Thanks. -- Tim Wescott Control systems, embedded software and circuit design I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●March 24, 20172017-03-24
On 2017-03-24, David Brown <david.brown@hesbynett.no> wrote:> On 24/03/17 07:21, Paul Rubin wrote: >> Tim Wescott <seemywebsite@myfooter.really> writes: >>> Is there anything in the standard libraries that does this easy and >>> obvious thing? >> >> 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. >> > > std::array should involve no "bloat" whatsoever. It's basically a > type-safe wrapper around C arrays, with the dimension easily available. >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 by ●March 24, 20172017-03-24
On Fri, 24 Mar 2017 18:24:44 +0000, Simon Clubley wrote:> On 2017-03-24, David Brown <david.brown@hesbynett.no> wrote: >> On 24/03/17 07:21, Paul Rubin wrote: >>> Tim Wescott <seemywebsite@myfooter.really> writes: >>>> Is there anything in the standard libraries that does this easy and >>>> obvious thing? >>> >>> 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. >>> >>> >> std::array should involve no "bloat" whatsoever. It's basically a >> type-safe wrapper around C arrays, with the dimension easily available. >> >> > 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...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 I'm looking for work! See my website if you're interested http://www.wescottdesign.com
Reply by ●March 24, 20172017-03-24
On 24/03/17 19:24, Simon Clubley wrote:> On 2017-03-24, David Brown <david.brown@hesbynett.no> wrote: >> On 24/03/17 07:21, Paul Rubin wrote: >>> Tim Wescott <seemywebsite@myfooter.really> writes: >>>> Is there anything in the standard libraries that does this easy and >>>> obvious thing? >>> >>> 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. >>> >> >> std::array should involve no "bloat" whatsoever. It's basically a >> type-safe wrapper around C arrays, with the dimension easily available. >> > > Well, "type-safe" if you ignore the little fact that the normal > indexing operator "[]" is not bounds checked. :-)The types are safe - it's just the ranges that are not...> > 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... >Yes, I think that would be a sensible idea. In many cases, the compiler can remove the run-time overhead of the checks.
