Jump to page: 1 24  
Page
Thread overview
defining "in" What is the proper way in D2?
Sep 11, 2011
Charles Hixson
Sep 11, 2011
David Nadlinger
Sep 11, 2011
Vladimir Panteleev
Sep 11, 2011
David Nadlinger
Sep 11, 2011
Charles Hixson
Sep 11, 2011
Charles Hixson
Sep 11, 2011
Jonathan M Davis
Sep 11, 2011
David Nadlinger
Sep 11, 2011
Timon Gehr
Sep 11, 2011
Jonathan M Davis
Sep 11, 2011
Timon Gehr
Sep 11, 2011
Jonathan M Davis
Sep 11, 2011
bearophile
Sep 12, 2011
Simen Kjaeraas
Sep 12, 2011
Timon Gehr
Sep 12, 2011
Timon Gehr
Sep 12, 2011
Timon Gehr
Sep 12, 2011
Jonathan M Davis
Sep 12, 2011
Timon Gehr
Sep 11, 2011
Charles Hixson
Sep 11, 2011
Jonathan M Davis
Sep 11, 2011
Timon Gehr
Sep 12, 2011
Charles Hixson
Sep 12, 2011
Timon Gehr
Sep 12, 2011
Charles Hixson
Sep 13, 2011
Vladimir Panteleev
September 11, 2011
What is the proper way to define the "in" operation in D2?  I can't figure it out from http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary , and the source code doesn't seem to have any examples.

My current (untested) find method is:
bool	find (Key k, Node!(Key, Data) t)
{	if	(level == 0)	return	false;
	if	(k < t.key)	return	find (k, t.left);
	if (t.key < k)	return	find (k, t.right);
	return	true;
}

but I'd really rather have it be an "in" method.
September 11, 2011
On 9/11/11 10:02 PM, Charles Hixson wrote:
> What is the proper way to define the "in" operation in D2?

For containers, you typically want to use opBinaryRight:

---
bool opBinaryRight(string op : "in")(ElemType e) const {
  return …;
}
---

David
September 11, 2011
On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson <charleshixsn@earthlink.net> wrote:

> I can't figure it out from http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary

// I assume your data structure looks like this
class Node(Key, Data)
{
	Key k;
	Node!(Key, Data) left, right;
	int level;
	// ...

	void opBinary!("in")(Key k)
	{
		if	(level == 0)	return	false;
		if	(k < key)   	return	k in left;
		if	(key < k)   	return	k in right;
		return	true;
	}
}
-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net
September 11, 2011
On 9/11/11 10:25 PM, Vladimir Panteleev wrote:
> void opBinary!("in")(Key k)

Shouldn't that be »void opBinary(string op : "in")(Key k)«? Also, you probably want to use opBinaryRight, because opBinary hooks »if (container in key)«.

David
September 11, 2011
On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
> On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
> <charleshixsn@earthlink.net> wrote:
>
>> I can't figure it out from
>> http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
>
> // I assume your data structure looks like this
> class Node(Key, Data)
> {
> Key k;
> Node!(Key, Data) left, right;
> int level;
> // ...
>
> void opBinary!("in")(Key k)
> {
> if (level == 0) return false;
> if (k < key) return k in left;
> if (key < k) return k in right;
> return true;
> }
> }

VOID??  I'm going to presume that this should have been bool.
Otherwise, thanks.  That was they syntax I couldn't figure out from the docs.

And, yeah.  That's what it looks like.  My find code was wrong, because it should have referenced the node, so what I need to do is move the cod into the node class.  But it was the syntax of defining the opBinary specialization that was hanging me up.  (For some reason I have a hard time wrapping my mind around template code.)
September 11, 2011
On 09/11/2011 01:33 PM, David Nadlinger wrote:
> On 9/11/11 10:25 PM, Vladimir Panteleev wrote:
>> void opBinary!("in")(Key k)
>
> Shouldn't that be »void opBinary(string op : "in")(Key k)«? Also, you
> probably want to use opBinaryRight, because opBinary hooks »if
> (container in key)«.
>
> David

And thanks for THIS, too.  I'd just started to wonder about the order of the syntax.  After all, the key is in the container, but not conversely.

Charles

September 11, 2011
On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
> On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
> > On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
> > 
> > <charleshixsn@earthlink.net> wrote:
> >> I can't figure it out from http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
> > 
> > // I assume your data structure looks like this
> > class Node(Key, Data)
> > {
> > Key k;
> > Node!(Key, Data) left, right;
> > int level;
> > // ...
> > 
> > void opBinary!("in")(Key k)
> > {
> > if (level == 0) return false;
> > if (k < key) return k in left;
> > if (key < k) return k in right;
> > return true;
> > }
> > }
> 
> VOID??  I'm going to presume that this should have been bool. Otherwise, thanks.  That was they syntax I couldn't figure out from the docs.
> 
> And, yeah.  That's what it looks like.  My find code was wrong, because it should have referenced the node, so what I need to do is move the cod into the node class.  But it was the syntax of defining the opBinary specialization that was hanging me up.  (For some reason I have a hard time wrapping my mind around template code.)

The "in" operator normally returns a pointer to the value that you're trying to find (and returns null if it's not there). Making it return bool may work, but it's going to be a problem for generic code. That's like making opBinary!"*" return a type different than the types being multiplied. It's just not how the operator is supposed to be used and could cause problems.

- Jonathan M Davis
September 11, 2011
On 9/11/11 11:12 PM, Jonathan M Davis wrote:
> The "in" operator normally returns a pointer to the value that you're trying
> to find (and returns null if it's not there). Making it return bool may work,
> but it's going to be a problem for generic code. That's like making
> opBinary!"*" return a type different than the types being multiplied. It's just
> not how the operator is supposed to be used and could cause problems.
>
> - Jonathan M Davis

+1, I once ran into a bug because of which I used bool instead, but that one should be fixed since quite some time now.

David
September 11, 2011
On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
> On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
>> On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
>>> On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
>>>
>>> <charleshixsn@earthlink.net>  wrote:
>>>> I can't figure it out from
>>>> http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
>>>
>>> // I assume your data structure looks like this
>>> class Node(Key, Data)
>>> {
>>> Key k;
>>> Node!(Key, Data) left, right;
>>> int level;
>>> // ...
>>>
>>> void opBinary!("in")(Key k)
>>> {
>>> if (level == 0) return false;
>>> if (k<  key) return k in left;
>>> if (key<  k) return k in right;
>>> return true;
>>> }
>>> }
>>
>> VOID??  I'm going to presume that this should have been bool.
>> Otherwise, thanks.  That was they syntax I couldn't figure out from the
>> docs.
>>
>> And, yeah.  That's what it looks like.  My find code was wrong, because
>> it should have referenced the node, so what I need to do is move the cod
>> into the node class.  But it was the syntax of defining the opBinary
>> specialization that was hanging me up.  (For some reason I have a hard
>> time wrapping my mind around template code.)
>
> The "in" operator normally returns a pointer to the value that you're trying
> to find (and returns null if it's not there). Making it return bool may work,
> but it's going to be a problem for generic code.

-1

I think the fact that "in" for AAs returns a pointer is a mistake and ugly in the first place and any generic code that relies on any container to return a raw internal pointer is flawed by itself imho.

> That's like making
> opBinary!"*" return a type different than the types being multiplied. It's just
> not how the operator is supposed to be used and could cause problems.
>

short a,b;
static assert(!is(typeof(a * b) == short));











September 11, 2011
On Monday, September 12, 2011 00:11:11 Timon Gehr wrote:
> On 09/11/2011 11:12 PM, Jonathan M Davis wrote:
> > On Sunday, September 11, 2011 14:00:55 Charles Hixson wrote:
> >> On 09/11/2011 01:25 PM, Vladimir Panteleev wrote:
> >>> On Sun, 11 Sep 2011 23:02:37 +0300, Charles Hixson
> >>> 
> >>> <charleshixsn@earthlink.net>  wrote:
> >>>> I can't figure it out from http://www.digitalmars.com/d/2.0/operatoroverloading.html#Binary
> >>> 
> >>> // I assume your data structure looks like this
> >>> class Node(Key, Data)
> >>> {
> >>> Key k;
> >>> Node!(Key, Data) left, right;
> >>> int level;
> >>> // ...
> >>> 
> >>> void opBinary!("in")(Key k)
> >>> {
> >>> if (level == 0) return false;
> >>> if (k<  key) return k in left;
> >>> if (key<  k) return k in right;
> >>> return true;
> >>> }
> >>> }
> >> 
> >> VOID??  I'm going to presume that this should have been bool.
> >> Otherwise, thanks.  That was they syntax I couldn't figure out from
> >> the
> >> docs.
> >> 
> >> And, yeah.  That's what it looks like.  My find code was wrong,
> >> because
> >> it should have referenced the node, so what I need to do is move the
> >> cod
> >> into the node class.  But it was the syntax of defining the opBinary
> >> specialization that was hanging me up.  (For some reason I have a hard
> >> time wrapping my mind around template code.)
> > 
> > The "in" operator normally returns a pointer to the value that you're trying to find (and returns null if it's not there). Making it return bool may work, but it's going to be a problem for generic code.
> 
> -1
> 
> I think the fact that "in" for AAs returns a pointer is a mistake and ugly in the first place and any generic code that relies on any container to return a raw internal pointer is flawed by itself imho.

It's an issue of efficiency. It's more efficient to grab the item once, getting null if it's not there, then it is to check if it's there and then grab it. Being a systems language, D is _very_ interested in efficiency. Keeping the pointer returned from in around for much after the call is likely to be bad code (and can certainly lead to problems), but there's nothing unsafe about the pointer in and of itself.

> > That's like making
> > opBinary!"*" return a type different than the types being multiplied.
> > It's just not how the operator is supposed to be used and could cause
> > problems.
> short a,b;
> static assert(!is(typeof(a * b) == short));

Those are primitive types, not user-defined types. They are also effectively derived types in terms of how they function. There's a big difference between returning a derived type and returning a completely different type.

- Jonathan M Davis
« First   ‹ Prev
1 2 3 4