discrimination of constructors with same number of parameters

Lutger Blijdestijn lutger.blijdestijn at gmail.com
Thu Dec 30 07:11:27 PST 2010


Guilherme Vieira wrote:

> On Thu, Dec 30, 2010 at 12:18 PM, spir <denis.spir at gmail.com> wrote:
> 
>> On Thu, 30 Dec 2010 08:15:51 -0500
>> bearophile <bearophileHUGS at lycos.com> wrote:
>>
>> > > But some language types (or machine types) can have very diverse
>> _human_ semantics, and thus be used for various purposes which should,
>> but cannot, be considered different:
>> >
>> > You may wrap your data in a struct.
>>
>> Yes, thank you for this hint. A kind of proxy struct? It can indeed be
>> used everywhere performance is not critical. But a side issue is that it
>> requires the 'alias this' hack, I guess, or forwarding every operation to
>> the actual, but wrapped, element. What do you think
>>
>> Denis
>> -- -- -- -- -- -- --
>> vit esse estrany ☣
>>
>> spir.wikidot.com
>>
>>
> Why is performance harmed by the use of a struct? Wouldn't it be
> zero-overhead like C++'s std::auto_ptr?
> 
> Also, the alias this and the forward might be a real good solution. And a
> mixin like Luger's might be jackpot, really. I just dislike the use in:
> 
> func2(Position(1)); // implicit conversion to int with alias this

This is deliberate, in this case I think of Position as a subtype of int so 
it is entirely reasonable to implicitly convert it. With opDispatch and 
operator overloading you could achieve the semantics you are after though.
  
> I guess that can be actually a bug, not a feature :) Maybe one day the
> function signature changes slightly and the problem is further disguised
> because "you're obviously passing the right Position here"... when it's
> actually an "int count" thing. The "alias this" thing is a good shorthand
> when assigning, though:
> 
> int a = pos; // implicit conversion from Position to int instead of
> int b = pos.base;
> 


More information about the Digitalmars-d-learn mailing list