Dimension of a matrix

On Fri, 24 Mar 2017 18:24:44 -0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

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

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

On 25/03/17 11:57, David Brown wrote:
> 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...

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

Am 25.03.2017 um 01:32 schrieb Tim Wescott:
> 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. :-)

Then it would again be "bloat" compared to a regular array...

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

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

On Fri, 24 Mar 2017 23:14:36 -0400, George Neuner wrote:

> On Fri, 24 Mar 2017 18:24:44 -0000 (UTC), Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
> 
>>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...
> 
> 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.]

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'm looking for work!  See my website if you're interested
http://www.wescottdesign.com

David Brown <david.brown@hesbynett.no> writes:
> Yes, I think that would be a sensible idea.  In many cases, the
> compiler can remove the run-time overhead of the checks.

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.

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

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

Tim Wescott wrote:
> 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.
>


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

Op 24-Mar-17 om 00:17 schreef Tim Wescott:
> 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?

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

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

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

-- 
Les Cargill

David Brown wrote:
> 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).
>

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.

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

-- 
Les Cargill