On 31 March 2014 13:32, Adam D. Ruppe <destructionator@gmail.com> wrote:

> On Monday, 31 March 2014 at 03:25:11 UTC, Manu wrote:
>
>> I also feel quite dirty using pointers in D where there is a dedicated reference type available. I don't want * and & to appear everywhere in my D code.
>>
>
> structs can pretty easily be reference types too:
>
> struct RefType {
>    struct Impl {
>         // put all the stuff in here
>    }
>    Impl* impl;
>    alias impl this;
>
>    // add ctors and stuff that new the impl
> }
>

And you think this is 'cool'?
The amount of boilerplate required makes C++ look neat and tidy. You've
also truncated it significantly.

class RefType
{
  // put all the stuff in here
}


Why would anyone want to do all that crap? The reason is to overcome the
limitations/restrictions of class... so just fix class?
Or maybe improve struct, so that boilerplate can disappear.
Perhaps add a distinct ref type like MS did with '^' pointers in WinRT and
managed C++?

Either way, for my money, that code might appeal to a D nerd (because you
'can'!), but I find it acutely distasteful code otherwise.
No junior programmer would/should understand all that intuitively, and I
would be embarrassed to show that to a non-D-user that I was trying to
convince.

If this pattern is recurring (it seems that it is), then I think it's clear sign of a chronic deficiency in D. It should probably be studied and addressed. I'm seeing it appear a lot.

On 3/30/2014 8:32 PM, Adam D. Ruppe wrote:
> On Monday, 31 March 2014 at 03:25:11 UTC, Manu wrote:
>> I also feel quite dirty using pointers in D where there is a dedicated
>> reference type available. I don't want * and & to appear everywhere in my D code.
>
> structs can pretty easily be reference types too:

Or just:

   alias S* C;

Voila! Use C as the type instead of S*. The reason this works out so well in D is because C.member works (no need to use -> )

On 31 March 2014 17:28, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/30/2014 8:32 PM, Adam D. Ruppe wrote:
>
>> On Monday, 31 March 2014 at 03:25:11 UTC, Manu wrote:
>>
>>> I also feel quite dirty using pointers in D where there is a dedicated reference type available. I don't want * and & to appear everywhere in my D code.
>>>
>>
>> structs can pretty easily be reference types too:
>>
>
> Or just:
>
>    alias S* C;
>
> Voila! Use C as the type instead of S*. The reason this works out so well in D is because C.member works (no need to use -> )
>

Now it's deceptive that it's a pointer, and the pointer semantics are not
suppressed. It might be surprising to find that a type that doesn't look
like a pointer behaves like a pointer.
You lose access to the operators, indexing/slicing etc, etc.
I don't see how this is a reasonable comparison to 'class' as a reference
type by definition.

On 3/31/2014 12:51 AM, Manu wrote:
> Now it's deceptive that it's a pointer, and the pointer semantics are not
> suppressed. It might be surprising to find that a type that doesn't look like a
> pointer behaves like a pointer.
> You lose access to the operators, indexing/slicing etc, etc.
> I don't see how this is a reasonable comparison to 'class' as a reference type
> by definition.

Of course it's reasonable - not many classes overload operators.

The point is, there are numerous solutions available, you aren't stuck with one solution for every problem.

And, you can use 'alias this' as Adam showed to create a type with fully customized behavior - you don't have to change the language to prove your ideas.

On 3/30/2014 7:10 PM, Manu wrote:
> On 31 March 2014 11:39, bearophile <bearophileHUGS@lycos.com
> <mailto:bearophileHUGS@lycos.com>> wrote:
>
>     Manu:
>
>
>         The most annoying thing about a hidden vtable pointer is it breaks
>         alignment.
>
>
>     D class instances have two hidden fields.
>
>
> Oh yeah... well that loses a lot of appeal from me in that case ;)

On 64 bits, the two fields means the rest starts at 16 byte alignment - ideal for SIMD!

On Sunday, 30 March 2014 at 00:57:25 UTC, deadalnix wrote:
> All is in the title.
>
> This is becoming increasingly the norm in new languages. It is much better in term of performances (it avoid cascaded loads to call methods, which can be really costly on modern CPUs), make object themselves smaller.
>
> Would implementing them that way break D code ? What would be the extent of the breakage ?

How hard would that be to implement? Hard data would be much better than performance guesses all over this thread.

On Monday, 31 March 2014 at 04:48:20 UTC, Manu wrote:
> On 31 March 2014 13:32, Adam D. Ruppe <destructionator@gmail.com> wrote:
>
>> On Monday, 31 March 2014 at 03:25:11 UTC, Manu wrote:
>>
>>> I also feel quite dirty using pointers in D where there is a dedicated
>>> reference type available. I don't want * and & to appear everywhere in my D
>>> code.
>>>
>>
>> structs can pretty easily be reference types too:
>>
>> struct RefType {
>>    struct Impl {
>>         // put all the stuff in here
>>    }
>>    Impl* impl;
>>    alias impl this;
>>
>>    // add ctors and stuff that new the impl
>> }
>>
>
> And you think this is 'cool'?
> The amount of boilerplate required makes C++ look neat and tidy. You've
> also truncated it significantly.
>
> class RefType
> {
>   // put all the stuff in here
> }
>
>
> Why would anyone want to do all that crap? The reason is to overcome the
> limitations/restrictions of class... so just fix class?
> Or maybe improve struct, so that boilerplate can disappear.
> Perhaps add a distinct ref type like MS did with '^' pointers in WinRT and
> managed C++?
>
> Either way, for my money, that code might appeal to a D nerd (because you
> 'can'!), but I find it acutely distasteful code otherwise.
> No junior programmer would/should understand all that intuitively, and I
> would be embarrassed to show that to a non-D-user that I was trying to
> convince.
>
> If this pattern is recurring (it seems that it is), then I think it's clear
> sign of a chronic deficiency in D. It should probably be studied and
> addressed. I'm seeing it appear a lot.

I think you're missing the point. D is able to create structs that work as reference types, as a generic library type. No novice programmer or new adopter has to understand how they work in order to use them.

I think there should be a more vanilla reference type (than NullableRef) in std.typecons in order to address this.

On 31 March 2014 18:18, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/30/2014 7:10 PM, Manu wrote:
>
>> On 31 March 2014 11:39, bearophile <bearophileHUGS@lycos.com <mailto:bearophileHUGS@lycos.com>> wrote:
>>
>>     Manu:
>>
>>
>>         The most annoying thing about a hidden vtable pointer is it breaks
>>         alignment.
>>
>>
>>     D class instances have two hidden fields.
>>
>>
>> Oh yeah... well that loses a lot of appeal from me in that case ;)
>>
>
> On 64 bits, the two fields means the rest starts at 16 byte alignment - ideal for SIMD!
>

Most computers aren't 64bit though. The fact that the pointers change in size between platforms is a huge nuisance. I often find I end up with some very annoying #ifdef's at the start of tightly packed classes to deal with this issue in C++.

On 03/31/14 05:32, Adam D. Ruppe wrote:
> On Monday, 31 March 2014 at 03:25:11 UTC, Manu wrote:
>> I also feel quite dirty using pointers in D where there is a dedicated reference type available. I don't want * and & to appear everywhere in my D code.
> 
> structs can pretty easily be reference types too:
> 
> struct RefType {
>    struct Impl {
>         // put all the stuff in here
>    }
>    Impl* impl;
>    alias impl this;
> 
>    // add ctors and stuff that new the impl
> }

No. This will bite you once you decide to overload Impl's ops, such as indexing and slicing. And it's quite nasty, as the code will then keep compiling but return bogus results. Debugging this will be an "interesting" process, unless you're already aware of what's happening or get lucky and the program crashes...

A little safer hack would be:

   struct RefType {
      struct Impl {
           // put all the stuff in here

           @disable this(this);
      }
      Impl* impl;
      ref Impl _get() @property { return *impl; }
      alias _get this;

      // add ctors and stuff that new the impl
   }

but this is still a rather ugly workaround.

artur

On 03/31/14 09:28, Walter Bright wrote:
> On 3/30/2014 8:32 PM, Adam D. Ruppe wrote:
>>
>> structs can pretty easily be reference types too:
> 
> Or just:
> 
>    alias S* C;
> 
> Voila! Use C as the type instead of S*.

   C c = ...;

   auto a = c[42];

Boom!

This is a catastrophic failure mode. Op overloads may be added to the pseudo-C after it's already written and working, and then a) the bug might go unnoticed, and b) fixing it requires API changes. See also my other reply.

artur