New slides about Go

[Denis Koroskin]

On Fri, 15 Oct 2010 03:23:00 +0400, Nick Sabalausky <a at a.a> wrote:

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

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