New slides about Go

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:i97utq$d7e$1 at 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.

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