Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26180 > unrolled thread

Dimension of a matrix

Back to article view | Back to comp.arch.embedded

Contents

  Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-23 18:17 -0500
    Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-23 23:21 -0700
      Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 09:18 +0100
        Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-24 18:24 +0000
          Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 19:32 -0500
            Re: Type-safety and C++, was: Re: Dimension of a matrix Stefan Reuther <stefan.news@arcor.de> - 2017-03-25 09:59 +0100
            Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:08 -0500
          Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-25 01:57 +0100
            Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-25 18:34 +1100
              Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-26 23:53 +0000
                Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 09:51 +0200
                  Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-27 20:19 +1100
                    Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 12:17 +0200
            Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-25 09:20 -0700
          Re: Type-safety and C++, was: Re: Dimension of a matrix George Neuner <gneuner2@comcast.net> - 2017-03-24 23:14 -0400
            Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-25 11:07 -0500
              Re: Type-safety and C++, was: Re: Dimension of a matrix George Neuner <gneuner2@comcast.net> - 2017-03-26 05:45 -0400
                Re: Type-safety and C++, was: Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 13:14 +0200
                  Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-26 11:08 -0700
                    Re: Type-safety and C++, was: Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 20:24 +0200
                Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-26 15:16 -0500
                  Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-27 00:09 +0000
                    Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-26 19:43 -0500
                      Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 16:57 +0100
                        Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-27 11:53 -0500
                          Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-27 22:04 +0200
                            Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-27 18:32 -0500
                              Re: Type-safety and C++, was: Re: Dimension of a matrix Clifford Heath <no.spam@please.net> - 2017-03-28 11:03 +1100
                          Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 22:07 +0100
                          Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-27 23:42 -0700
                            Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-28 09:22 +0200
                              Re: Type-safety and C++, was: Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-28 00:42 -0700
                              Re: Type-safety and C++, was: Re: Dimension of a matrix Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-28 09:07 +0100
                                Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-28 19:34 -0500
                                Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-29 11:39 -0500
                              Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-28 19:29 -0500
                                Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-29 10:31 +0200
                                  Re: Type-safety and C++, was: Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 00:23 +0000
                                  Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-29 19:31 -0500
                                    Re: Type-safety and C++, was: Re: Dimension of a matrix Phil Martel <pomartel@comcast.net> - 2017-03-30 11:51 -0400
                                      Re: Type-safety and C++, was: Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-30 19:16 -0500
                                      Re: Type-safety and C++, was: Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-31 09:21 +0200
                            Re: Type-safety and C++, was: Re: Dimension of a matrix Tim Wescott <seemywebsite@myfooter.really> - 2017-03-28 14:19 -0500
      Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 11:05 -0500
        Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 17:33 +0100
          Re: Dimension of a matrix Tim Wescott <tim@seemywebsite.com> - 2017-03-24 12:09 -0500
        Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:09 -0500
      Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:05 -0500
    Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-24 09:20 +0100
      Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 13:12 -0500
        Re: Dimension of a matrix Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-03-25 20:08 +0100
          Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:17 -0500
            Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-26 17:32 +0200
              Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-26 11:55 -0500
                Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-26 21:23 +0200
                  Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-29 19:36 -0500
                    Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 00:36 +0000
                      Re: Dimension of a matrix Paul Rubin <no.email@nospam.invalid> - 2017-03-29 19:55 -0700
                        Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-30 09:49 +0200
                          Re: Dimension of a matrix Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-30 18:07 +0000
                    Re: Dimension of a matrix David Brown <david.brown@hesbynett.no> - 2017-03-30 09:47 +0200
    Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-25 19:08 +0100
      Re: Dimension of a matrix Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:21 -0500
        Re: Dimension of a matrix Wouter van Ooijen <wouter@voti.nl> - 2017-03-26 14:43 +0200

Page 1 of 4  [1] 2 3 4  Next page →

#26180 — 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
http://www.wescottdesign.com

I'm looking for work -- see my website!

[toc] | [next] | [standalone]

#26190

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.

[toc] | [prev] | [next] | [standalone]

#26194

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.

[toc] | [prev] | [next] | [standalone]

#26219 — Type-safety and C++, was: Re: Dimension of a matrix

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

[toc] | [prev] | [next] | [standalone]

#26230 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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

[toc] | [prev] | [next] | [standalone]

#26241 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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

[toc] | [prev] | [next] | [standalone]

#26251 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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

[toc] | [prev] | [next] | [standalone]

#26232 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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.

[toc] | [prev] | [next] | [standalone]

#26239 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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

[toc] | [prev] | [next] | [standalone]

#26294 — Re: Type-safety and C++, was: Re: Dimension of a matrix

On 2017-03-25, Clifford Heath <no.spam@please.net> wrote:
> On 25/03/17 11:57, David Brown wrote:
>> On 24/03/17 19:24, Simon Clubley wrote:
>>>
>>> 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...

Some people would disagree with that definition of "type-safe". :-)

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

And that's exactly why they would disagree. If the bounds are
not enforced, then it's not type-safe IMHO.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[toc] | [prev] | [next] | [standalone]

#26301 — Re: Type-safety and C++, was: Re: Dimension of a matrix

On 27/03/17 01:53, Simon Clubley wrote:
> On 2017-03-25, Clifford Heath <no.spam@please.net> wrote:
>> On 25/03/17 11:57, David Brown wrote:
>>> On 24/03/17 19:24, Simon Clubley wrote:
>>>>
>>>> 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...
> 
> Some people would disagree with that definition of "type-safe". :-)
> 
>>
>> 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".
>>
> 
> And that's exactly why they would disagree. If the bounds are
> not enforced, then it's not type-safe IMHO.
> 

Type safety is primarily a compile-time feature.  The aim of type safety
is to stop you trying to use the wrong "type" of "thing" (objects,
classes, types, whatever) in the wrong place.  And by restricting the
operations you can do on your "things", you spot more mistakes at
compile-time.  A vital point is that type safety checks are free with
respect to run-time costs.  And your aim is to stop certain classes of
error being /possible/.

Checking the bounds of array accesses is primarily a run-time feature.
There are run-time safety checks you can make - they are not type safety
checks.  They involve some run-time overhead, and you need run-time
methods of dealing with detected errors - your aim is to detect certain
classes of error when they happen, and stop them leading to worse problems.

Sometimes there is a middle ground.  The compiler may be able to check,
at compile time, whether an array access is always safe, possibly safe,
or always bad.  It is certainly a good thing if the compiler can warn
you on third case, and omit any run-time checks in the first case.

You can argue that a std::array type is a type with a fixed known size,
and therefore should not allow any access beyond its bounds.  But
actually it is defined as a type that wraps a C array with no run-time
overheads for normal use, without run-time checking of bounds.  It gives
you methods for accessing the data, but there is a pre-condition on the
[] operator that you are within the bounds of the array.  This is a
perfectly good way to define a type and its operations - type-safety
does /not/ require run-time checking that pre-conditions to methods are
met.  That is the responsibility of the code using the type.

Of course one could make a type for which bounds checking was part of
the [] operator method specification.  But even then, the check is not
part of the type safety system because the index is not part of a type,
and the check is not at compile-time.  If you want that kind of type
safety, use a std::tuple and get<i> functions for access - /those/
accesses are type checked.

[toc] | [prev] | [next] | [standalone]

#26303 — Re: Type-safety and C++, was: Re: Dimension of a matrix

On 27/03/17 18:51, David Brown wrote:
> On 27/03/17 01:53, Simon Clubley wrote:
>> On 2017-03-25, Clifford Heath <no.spam@please.net> wrote:
>>> On 25/03/17 11:57, David Brown wrote:
>>>> On 24/03/17 19:24, Simon Clubley wrote:
>>>>>
>>>>> 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...
>>
>> Some people would disagree with that definition of "type-safe". :-)
>>
>>>
>>> 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".
>>>
>>
>> And that's exactly why they would disagree. If the bounds are
>> not enforced, then it's not type-safe IMHO.
>>
>
> Type safety is primarily a compile-time feature.

Sorry, but you can't just redefine "type safety" to mean "static
type safety" and exclude "dynamic type safety".

I get it, static >> dynamic, but they're both about type safety.

Clifford Heath.

[toc] | [prev] | [next] | [standalone]

#26304 — Re: Type-safety and C++, was: Re: Dimension of a matrix

On 27/03/17 11:19, Clifford Heath wrote:
> On 27/03/17 18:51, David Brown wrote:
>> On 27/03/17 01:53, Simon Clubley wrote:
>>> On 2017-03-25, Clifford Heath <no.spam@please.net> wrote:
>>>> On 25/03/17 11:57, David Brown wrote:
>>>>> On 24/03/17 19:24, Simon Clubley wrote:
>>>>>>
>>>>>> 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...
>>>
>>> Some people would disagree with that definition of "type-safe". :-)
>>>
>>>>
>>>> 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".
>>>>
>>>
>>> And that's exactly why they would disagree. If the bounds are
>>> not enforced, then it's not type-safe IMHO.
>>>
>>
>> Type safety is primarily a compile-time feature.
> 
> Sorry, but you can't just redefine "type safety" to mean "static
> type safety" and exclude "dynamic type safety".
> 
> I get it, static >> dynamic, but they're both about type safety.
> 

Fair enough, I suppose.  C++ supports dynamic type safety too, such as
the dynamic_cast operator.  But static type safety is the main mechanism
for type safety in C++.

std::array is defined to be a type with greater static type safety
compared to standard C/C++ arrays - it knows its size, does not decay to
a pointer, etc.  It is not defined to have run-time bounds checking by
default - but you have the option if you want (with the "at" method).

Type safety - dynamic or static - does not mean preventing any possible
errors.  It merely means making it hard to accidentally make errors from
mixing up types - and it is a balance between safety, convenience (in
writing the code) and efficiency (code size and speed at run-time).  It
is not an absolute term (at least, not in real-world programs in
real-world programming languages).  It would be fair to say that an
array container that always checked its bounds is /safer/ than
std::array, and is more "type safe".  But it could never be completely
type safe - not in C++, where you have reinterpret_cast, unions, void*,
memcpy, and all sorts of other ways to cheat on type safety.

[toc] | [prev] | [next] | [standalone]

#26246 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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.

[toc] | [prev] | [next] | [standalone]

#26237 — Re: Type-safety and C++, was: Re: 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

[toc] | [prev] | [next] | [standalone]

#26245 — Re: Type-safety and C++, was: Re: Dimension of a matrix

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

[toc] | [prev] | [next] | [standalone]

#26276 — Re: Type-safety and C++, was: Re: Dimension of a matrix

On Sat, 25 Mar 2017 11:07:30 -0500, Tim Wescott <tim@seemywebsite.com>
wrote:

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

Yes. But not every array in C++ uses the STL class, and I was reacting
to Simon's comment about the '[]' index operator.  

It would be hopelessly confusing if the index operator of the array
class was checked, but the general (C compatible) index operator was
not.  If the general operator were checked, undoubtedly some code
would break, and even though STL arrays are heap allocated with some
overrun slop, I suspect that checking the operator there also would
break some existing code.
[Not that breaking crappy code is a bad thing ... 8-) ]

YMMV,
George

[toc] | [prev] | [next] | [standalone]

#26279 — Re: Type-safety and C++, was: Re: Dimension of a matrix

Op 26-Mar-17 om 11:45 schreef George Neuner:
> On Sat, 25 Mar 2017 11:07:30 -0500, Tim Wescott <tim@seemywebsite.com>
> wrote:
>
>> 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.
>
> Yes. But not every array in C++ uses the STL class, and I was reacting
> to Simon's comment about the '[]' index operator.
>
> It would be hopelessly confusing if the index operator of the array
> class was checked, but the general (C compatible) index operator was
> not.  If the general operator were checked, undoubtedly some code
> would break, and even though STL arrays are heap allocated with some
> overrun slop,

There are no such things as 'STL arrays', and the ones you probably talk 
about (containers?) are not guranteed to have overrun 'slop' (room 
before and after?).

Wouter "Objects? No Thanks!" van Ooijen

[toc] | [prev] | [next] | [standalone]

#26286 — Re: Type-safety and C++, was: Re: Dimension of a matrix

Wouter van Ooijen <wouter@voti.nl> writes:
> There are no such things as 'STL arrays'

I believe we've been using the term to refer to this:

  http://en.cppreference.com/w/cpp/container/array

[toc] | [prev] | [next] | [standalone]

#26287 — Re: Type-safety and C++, was: Re: Dimension of a matrix

Op 26-Mar-17 om 20:08 schreef Paul Rubin:
> Wouter van Ooijen <wouter@voti.nl> writes:
>> There are no such things as 'STL arrays'
>
> I believe we've been using the term to refer to this:
>
>   http://en.cppreference.com/w/cpp/container/array

That type of array has nothing to do with heap storage, and it has zero 
overhead.

(In contrast to for instance std::vector and other dynamically-sized 
array-like things, which do use the heap.)

Wouter "Objects? No Thanks!" van Ooijen

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web