www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Array Indexing/Slicing Range Checking, Exceptions and nogc

reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
I'm working on a support-it-all Array implementation (with 
optional sortedness) at

https://github.com/nordlow/justd/blob/master/packedarray.d

that has a very flexible memory allocation model via either 
GC.malloc or via privately imported malloc, realloc and free. 
This in order to provide pure  trusted access in all cases except 
slicing and `auto ref opIndex`.

I'm however uncertain about how to implement error handling of 
bounds checking and how these interact with ` nogc`. My main goal 
is to match semantics of builtin D arrays and slices. If so 
should we implement bounds checking as either

opIndex(size_t index) nothrow  nogc
{
     assert(index < length, "Index out of bounds");
}

or via

opIndex(size_t index) // cannot be nothrow  nogc
{
     if (index >= length) { throw new RangeError("Index out of 
bounds"); }
}

?

What's the preferred policy here?
Mar 30 2016
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On 30.03.2016 15:12, Nordlöw wrote:

 https://github.com/nordlow/justd/blob/master/packedarray.d


 From there:


     this(R)(R values, bool assumeSortedParameter = false)  trusted nothrow
 ("complexity", "O(n*log(n))")
         if (isInputRange!R)


This is off topic, but don't mark templates like that  trusted. By doing 
so you also trust R, but you don't know if it's memory safe.
Mar 30 2016
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 30 March 2016 at 13:24:20 UTC, ag0aep6g wrote:

 On 30.03.2016 15:12, Nordlöw wrote:

 https://github.com/nordlow/justd/blob/master/packedarray.d


 From there:


     this(R)(R values, bool assumeSortedParameter = false) 
  trusted nothrow  ("complexity", "O(n*log(n))")
         if (isInputRange!R)


 This is off topic, but don't mark templates like that  trusted. 
 By doing so you also trust R, but you don't know if it's memory 
 safe.


Should I post in group "General" instead?
Mar 30 2016
parent ag0aep6g <anonymous example.com> writes:
On 30.03.2016 15:44, Nordlöw wrote:

 On Wednesday, 30 March 2016 at 13:24:20 UTC, ag0aep6g wrote:


[...]

 This is off topic, but don't mark templates like that  trusted. By
 doing so you also trust R, but you don't know if it's memory safe.


 Should I post in group "General" instead?


No, no, I meant my comment is off topic.
Mar 30 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 30 March 2016 at 13:12:49 UTC, Nordlöw wrote:

 I'm however uncertain about how to implement error handling of 
 bounds checking and how these interact with ` nogc`. My main 
 goal is to match semantics of builtin D arrays and slices.


I would actually cheat on this somehow.... and actually, there's 
a better way entirely:

Don't use your ptr method. Instead, make it a slice method: 
`return _store[0 .. _length];`

Now you can just index it internally and let the compiler 
automatically insert range checks. When you need the pointer, you 
still have slice.ptr.

So punt the problem to the compiler. This will also ensure you 
always use it correctly too.


If you don't want to do that, you could cheat on the range error 
a couple other ways too:

1) define a function to allocate the exception that lies about 
being nogc. It is an Error and unrecoverable anyway - you are 
allowed to throw them from nothrow too!

2) Define a fake slice and index into it, knowing it is out of 
bounds so the compiler generates the error. Dangerous in -release 
mode though!

3) Pre-allocate a RangeError object. Meh, I wouldn't do that, but 
listing it because you could.
Mar 30 2016
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
On Wednesday, 30 March 2016 at 13:38:40 UTC, Adam D. Ruppe wrote:

 Don't use your ptr method. Instead, make it a slice method: 
 `return _store[0 .. _length];`

 Now you can just index it internally and let the compiler 
 automatically insert range checks. When you need the pointer, 
 you still have slice.ptr.

 So punt the problem to the compiler. This will also ensure you 
 always use it correctly too.


Superb! Thanks.
Mar 30 2016