Safe interval pointer

bearophile bearophileHUGS at lycos.com
Fri Jan 29 00:32:18 PST 2010


BCS:

> Things I'd use in place of that:
> 
> /////
> char[] str, int at = 0;
> ...
> switch(str[at]) { ... }
> ...
> at++;
> 
> or
> 
> /////
> char[] str;
> ...
> switch(str[0]) { ... }
> ...
> str = str[1..$];

When in not-debug mode that struct of mine is just 1 word long, so it hopefully gets optimized well by LDC2. While removing that free 2-word ling "str" is a bit harder.

With that struct you don't need to carry around two things, a vector and index, you have to keep and move around just one variable. And it acts just like a pointer, so you can move it in both directions, etc (it's not handy nor safe to do this with a slice, you need to keep a 3 words of memory as state to be safe).

You can (hopefully) use it as drop-in safer replacement for a pointer that you know spans a range of memory (it can have few holes too), so you can use it in D2 code translated from original C code, changing it very little. You don't want to modify too much that kind of C code. In that broken finite state machine of mine I've had to change just one line of code, where the "p" pointer is defined.

With DMD you can remove 100% of the overhead defining it as a pointer in not-debug release, and keeping the rest of the code that use the pointer unchanged. This can be done locally (with a bit more complex pointer definition that defines a true pointer in not-debug mode), or more generally modifying those functions that act as constructors, so they return a true pointer in not-debug mode (but I like this less, I think it's not tidy to have functions that return different types in debug mode).

Having safer pointers goes well with the style of D language. Probably I'll put this struct in my future d2libs :-) Maybe with small changes such safe ranged pointers can be used in SafeD modules too :-)

Bye,
bearophile



More information about the Digitalmars-d mailing list