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