On Fri, 15 Oct 2010 03:23:00 +0400, Nick Sabalausky <a...@a.a> wrote:
"bearophile" <bearophileh...@lycos.com> wrote in message
news:i97utq$d7...@digitalmars.com...
- In my D programs I sometimes use pointers, but pointer arithmetic is
indeed uncommon.
If you're actually doing systems-level or high-performance work, it can
be
essential in certain cases depending on how good the optimizer is.
Loops like this are fairly typical (using 'for' instead of
'foreach'/'map'/etc for clarity):
T[] myArray = ...;
for(int i=0; i<max; i++)
{
myArray[i] // <- do something with that
}
If the compiler isn't smart enough to turn that into this:
T[] myArray = ...;
auto ptr = myArray.ptr;
auto end = myArray.ptr + max;
for(auto ptr = myArray.ptr; ptr<end; ptr++)
{
*myArray // <- do something with that
}
Then you're wasting cycles every iteration (by doing an extra addition
and
maybe an extra shift or even multiplication depending on T: Ie,
(cast(ubyte*)myArray.ptr) + i * T.sizeof). That was a pretty common
inner-loop optimization back in my C days.
And keep in mind, of course, real-world examples can be much more complex
than that, so even if the compiler can handle trivial cases like this (I
have no idea if it can, although using 'foreach' would probably make it
easier - in some cases), it might not work for other cases. So unless the
optimizer was known to be that good even in complex cases, I wouldn't
want
to be without pointer arithmetic. It's not needed often, but when it is
needed it's indispensable (and still results in much more
readable/portable
code then delving down to asm).
Plus, I've never once done pointer arithmetic accidentally in D, so I
don't
see any safety to be gained from not allowing it.
First, compiler doing pointer arithmetics != user doing pointer arithmetic.
Second, I believe it's not about a danger or accidental pointer arithmetic
usage, it's more about syntax (and ambiguities it introduces).
For example, I once suggested using pointer syntax for classes too, and
provided tons of arguments for that (ranging from solving tail-const issue
to solving many language inconstancies that are in D between struct/class
syntax and a lot more), plus a ton of additional functionality it
optionally can provide if implemented. There was only one problem with
that - pointer arithmetic syntax came into the way. E.g.
Foo* foo = new Foo(); foo += 1; // is that operator overloading or
pointer arithmetic?
Foo foo = new Foo(); foo += 1; // compare to current version
I still hope we deprecate pointer arithmetic and introduce another syntax
for it for a next major D revision (i.e. D3)
- Turning x++; into statements seems harsh, but indeed it solves some
problems. In practice in my D programs the ++ is often used as a
statement, to avoid bugs.
I've long been of the opinion that should just be a statement. All it
ever
does as an expression, if anything, is obfuscate code. I've never once
seen
a case where it clarified anything.
- Segmented stack: allows to avoid some stack overflows at the price of
a
bit of delay at calling functions.
Seems a bad idea to force the overhead of that, but it should definitely
be
available as an option. Contrary to what Walter and Andrei seem to think,
32-bit systems are still very much alive and will be for quite awhile
longer. Especially when you remember that there are more computers out
there
than just desktops and servers. (Ex: When is a phone ever going to need
64-bit? Eventually maybe, but certainly not anytime soon.)
