Does D have too many features?

Dmitry Olshansky dmitry.olsh at gmail.com
Sun Apr 29 05:28:23 PDT 2012


On 29.04.2012 10:42, Jonathan M Davis wrote:
> On Sunday, April 29, 2012 09:53:15 Dmitry Olshansky wrote:
>> On 29.04.2012 4:31, Jonathan M Davis wrote:
>>> For better or worse, the solution for smart pointers in D would be to use
>>> opDispatch,
>>
>> *cough* alias this *cough*
>
> That's not necessarily a good idea, depending on how it's used. You want to
> avoid having the smart pointer implicitly convert to what it holds such that a
> reference to it leaks. If you're dealing with a pointer to a struct, and alias
> this aliases to the struct (rather than the pointer), then you're okay. But if
> you're dealing with a class, you don't have that option. So, alias this ends
> up leaking a reference to the class, which defeats the purpose of the smart
> pointer. You have the same problem if alias this aliases to the pointer rather
> than what's pointed to.

Point taken.

>
> But regardless of whether you use alias this or opDispatch, you have the same
> problem with regards to ->. In C++, . would be used to call the smart
> pointer's functions, and ->  would be used to call functions on the object
> pointed to. In D, the two aren't distinguished - both use . - so you can't
> have any functions on the type pointed to which conflict with the smart
> pointer's functions, or you won't be able to call them (unless another way to
> call them is provided somehow). So, it's definitely something that C++ does
> better with as far as that goes.


So you just need not to have any _member_ functions on smart pointer? 
Just use free functions that take SmartPointer!T. UFCS may also lend a 
hand if T and SmartPointer do not have ambiguous funcs.

-- 
Dmitry Olshansky


More information about the Digitalmars-d mailing list