Lazy range of hashes?

Era Scarecrow rtcvb32 at yahoo.com
Sun Aug 26 11:01:18 PDT 2012


On Sunday, 26 August 2012 at 15:28:17 UTC, Ali Çehreli wrote:
> On 08/26/2012 12:55 AM, Era Scarecrow wrote:

> Interestingly, it has some value in C++ because if a type has 
> defined operator->() (rather, for this discussion, operator.(), 
> which does not exist in C++ today), then the following would 
> cause confusion for types that worked like smart pointers:

> D does not have that question because the dot operator may not 
> be overloaded. (opDot() has been (will be?) deprecated.)

  Since D wouldn't ever have a need to emulate pointers (like 
Iterators for C++) the -> and . overloading seem moot. Some 
features are best not to be implemented as they would give more 
trouble than they're worth.

> No: The dot does not convert the type. The dot has different 
> meanings on structs vs. classes. With structs, it always 
> operates on the struct object:
>
>     o.sizeof   // The size of the struct object
>     o.foo()    // The member of the struct object
>
> With classes, it operates sometimes on the reference and 
> sometimes on the referenced object:
>
>     o.sizeof   // The size of the class reference
>     o.foo()    // The member of the class object
>
> That's D's way of confusing on this topic.

  Only if o.sizeof may refer to the pointer size and not the class 
object.

> You meant sv:
>
>     return sv ? sv : 0;

  Ack! bad typo! Bad bad typo!

> That is still a compilation error for a statically-typed 
> language like D. The types of sv and 0 don't match. But the 
> line should always be like this anyway:
>
>     return sv ? *sv : 0;
>
> Because sv is always a pointer:

  Gotcha.

> > Rather than auto could ref work?
>
> You mean, 'ref' on the return type, right? For opIn_r, it 
> better not be 'ref', because then it would be returning a 
> reference to a local pointer:

  And here i thought it would refer the reference (from in's case) 
to the original object. Mmmm.

>     // Note ref return. I think this is a bug.
>     ref opIn_r(X)(X x)
>     {
>         foreach (hash; hashes)
>         {
>             auto p = x in hash;
>             if (p)
>                 return p; // <-- return a reference to the 
> local pointer
>         }
>
>         return null;
>     }
>
> I think that is a bug but the compiler does not give a warning 
> about returning a reference to the local pointer.

  I've actually had this problem before. Ended up having to use 
ref on the input and then force a pointer to get my code 
elsewhere to work (without copying). But that's kinda 
unimportant; If the compiler issues a warning than all the better 
now :)

> As you said, returning *x would return a copy of the value if 
> it were a struct.

  K. Glad to get that out of the way.


More information about the Digitalmars-d-learn mailing list