www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - aa -> set

reply "Ilya Zaitseff" <sark7 mail333.com> writes:
interesting...

void[int] x; // set declaration

void main()
{
	x[1]; // add element '1' to set
	if (1 in x != null) printf("1 in set");
}

currently it works.
but, are there any warranty that compiler do not remove x[1] expression?
Jun 05 2005
next sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 06 Jun 2005 14:19:52 +1100, Ilya Zaitseff wrote:


 interesting...
 
 void[int] x; // set declaration
 
 void main()
 {
 	x[1]; // add element '1' to set
 	if (1 in x != null) printf("1 in set");
 }
 
 currently it works.
 but, are there any warranty that compiler do not remove x[1] expression?


This looks like a neat way to create sets. I normally use 'bool[int]' to do
the same.

-- 
Derek
Melbourne, Australia
6/06/2005 1:24:42 PM
Jun 05 2005
prev sibling next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Very interesting.  I would like some way to have a void value hash... 
basically just a btree, where missing is the same as false.

I wonder if it takes memory for the values anyway?  Probably does.

-[Unknown]



 interesting...
 
 void[int] x; // set declaration
 
 void main()
 {
     x[1]; // add element '1' to set
     if (1 in x != null) printf("1 in set");
 }
 
 currently it works.
 but, are there any warranty that compiler do not remove x[1] expression?
Jun 05 2005
prev sibling parent reply "Walter" <newshound digitalmars.com> writes:
"Ilya Zaitseff" <sark7 mail333.com> wrote in message
news:op.srxh7egpaaezs2 ilya.tec.amursk.ru...

 interesting...

 void[int] x; // set declaration

 void main()
 {
 x[1]; // add element '1' to set
 if (1 in x != null) printf("1 in set");
 }

 currently it works.
 but, are there any warranty that compiler do not remove x[1] expression?


That's going away in the next release, due to popular revulsion at the idea
that referencing a non-existent key in an associative array would implicitly
add it.
Jun 05 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
"Walter" <newshound digitalmars.com> wrote in message 
news:d80rpv$2p85$4 digitaldaemon.com...

 "Ilya Zaitseff" <sark7 mail333.com> wrote in message
 news:op.srxh7egpaaezs2 ilya.tec.amursk.ru...

 interesting...

 void[int] x; // set declaration

 void main()
 {
 x[1]; // add element '1' to set
 if (1 in x != null) printf("1 in set");
 }

 currently it works.
 but, are there any warranty that compiler do not remove x[1] expression?


 That's going away in the next release, due to popular revulsion at the 
 idea
 that referencing a non-existent key in an associative array would 
 implicitly
 add it.


Just as an idea:
In my implementation of Dictionary (wrapper around map) I am using 
additional
forms:

VALUE opIndex(KEY key, VALUE delegate(KEY k) ctor)
VALUE opIndex(KEY key, VALUE function(KEY k) ctor)

Additional parameter allows to construct value on the fly if it does not 
exist effectively
as there are cases (e.g. implementation of String.intern in Java) where it 
is nice to have feature.

And of course:
const void[int] x;  //eh?
Jun 06 2005
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
In article <d80rpv$2p85$4 digitaldaemon.com>, Walter says...

"Ilya Zaitseff" <sark7 mail333.com> wrote in message
news:op.srxh7egpaaezs2 ilya.tec.amursk.ru...

 interesting...

 void[int] x; // set declaration

 void main()
 {
 x[1]; // add element '1' to set
 if (1 in x != null) printf("1 in set");
 }

 currently it works.
 but, are there any warranty that compiler do not remove x[1] expression?


That's going away in the next release, due to popular revulsion at the idea
that referencing a non-existent key in an associative array would implicitly
add it.


I actually like this :p  But I suppose it's because I'm used to the behavior of
std::map in C++.


Sean
Jun 06 2005
prev sibling parent Kevin Bealer <Kevin_member pathlink.com> writes:
In article <d80rpv$2p85$4 digitaldaemon.com>, Walter says...

"Ilya Zaitseff" <sark7 mail333.com> wrote in message
news:op.srxh7egpaaezs2 ilya.tec.amursk.ru...

 interesting...

 void[int] x; // set declaration

 void main()
 {
 x[1]; // add element '1' to set
 if (1 in x != null) printf("1 in set");
 }

 currently it works.
 but, are there any warranty that compiler do not remove x[1] expression?


That's going away in the next release, due to popular revulsion at the idea
that referencing a non-existent key in an associative array would implicitly
add it.


(I thought the current behavior was weird when I first saw it in C++.  I'm used
to it now, but if it changes that's okay.)

What replaces the current behavior?  Do you get an exception from T[unknown], or
just T.init?

The C++ way seems to make sense in C++, since I can store a C++ reference to an
object and then avoid a second lookup for the insertion phase.  In D you can't
store a mutable reference (as far as I know), unless maybe with:

T * xp = & x[i];

Does this work now (it seems to, with int[char[]]), would it still work, or
would there still be a way to avoid the second lookup for the "if (i !in
container) { container[i] = 100; }"?

I guess I'm back to proposing opIndexMutable() or similar... It seems like
"writeable" cases such as the above could use the (current) "x[i] = T.init"
semantics if not present.  Likewise for passing to inout parameters.

FWIW, I don't mind if "second lookup avoidance" is a little more awkward syntax
wise since its only an optimization.  The current mechanism probably leads many
people to do two lookups, either with "in" then "x[i]=" or another similar
two-step.

One syntax might be:

x.lookup(i): returns "T*".

Sorry if it seems like you're getting fired on from both camps...

Kevin
Jun 06 2005