digitalmars.D - aa -> set
- "Ilya Zaitseff" <sark7 mail333.com> Jun 05 2005
- Derek Parnell <derek psych.ward> Jun 05 2005
- "Unknown W. Brackets" <unknown simplemachines.org> Jun 05 2005
- "Walter" <newshound digitalmars.com> Jun 05 2005
- "Andrew Fedoniouk" <news terrainformatica.com> Jun 06 2005
- Sean Kelly <sean f4.ca> Jun 06 2005
- Kevin Bealer <Kevin_member pathlink.com> Jun 06 2005
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
Derek Parnell <derek psych.ward> 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
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
"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
"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
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
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