On 1/7/2012 8:54 PM, bearophile wrote:
Yes, Jonathan, you're right.
the question arose precisely from a typo... i had to remove an
item with key length... i wrote lengt and the item never went
away... i knew that lengt was not in my key list... This kind of
mistake is quite tricky, may be
On Sunday, January 08, 2012 01:39:24 Kapps wrote:
For most languages (such as C# and maybe Java), the Remove method on
collections returns a boolean indicating whether it was removed. So you
could write:
enforce(MyAA.remove(lenght))
or
bool Result = MyAA.remove(lenght);
assert(Result);
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
http://d.puremagic.com/issues/show_bug.cgi?id=4523
On 08/01/2012 1:39 AM, Kapps wrote:
For most languages (such as C# and maybe Java), the Remove method on
collections returns a boolean indicating whether
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
http://d.puremagic.com/issues/show_bug.cgi?id=4523
Ah, TDPL says that it returns bool. Well, then it definitely needs to be
changed, and it's good to
On 08.01.2012 10:43, Jonathan M Davis wrote:
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
http://d.puremagic.com/issues/show_bug.cgi?id=4523
Ah, TDPL says that it returns bool. Well, then it
simendsjo wrote:
Wouldn't it make sense to return a pointer to the item being
removed/null?
According to the docs this is the intended behavior.
-manfred
On 08.01.2012 11:09, Manfred Nowak wrote:
simendsjo wrote:
Wouldn't it make sense to return a pointer to the item being
removed/null?
According to the docs this is the intended behavior.
-manfred
The only mention I can see of remove is at the top, and it doesn't state
return value:
On Sunday, January 08, 2012 11:02:41 simendsjo wrote:
On 08.01.2012 10:43, Jonathan M Davis wrote:
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
On 08.01.2012 11:27, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:02:41 simendsjo wrote:
On 08.01.2012 10:43, Jonathan M Davis wrote:
On Sunday, January 08, 2012 03:24:22 Kapps wrote:
Ah, found the bug / pull request.
https://github.com/D-Programming-Language/dmd/pull/597
On 1/8/12, simendsjo simend...@gmail.com wrote:
Wouldn't it make sense to return a pointer to the item being
removed/null?
Seems like that would be even more costly. Personally I think
returning bool is unnecessary, if we really want to know if something
is in the hash we can check with the
simendsjo wrote:
it doesn't state return value
Yes, I haven't read carefully enough.
-manfred
On 08.01.2012 12:18, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
I was thinking it could be a shorthand for the following:
auto item = key in aa;
if (item) key.remove(key);
I take it that you then intend to use item after that? I'm not sure that item
is
On Sunday, January 08, 2012 12:35:27 simendsjo wrote:
On 08.01.2012 12:18, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
I was thinking it could be a shorthand for the following:
auto item = key in aa;
if (item) key.remove(key);
I take it that you
On 08.01.2012 12:57, Jonathan M Davis wrote:
On Sunday, January 08, 2012 12:35:27 simendsjo wrote:
On 08.01.2012 12:18, Jonathan M Davis wrote:
On Sunday, January 08, 2012 11:33:51 simendsjo wrote:
I was thinking it could be a shorthand for the following:
auto item = key in aa;
if (item)
On Sunday, January 08, 2012 13:06:06 simendsjo wrote:
Certainly not obvious to me :)
Well, what's obvious to one person is not always obvious to another. I'm sure
that there are plenty of things that Walter thinks should be perfectly obvious
which 90% of programmers would never think of. A lot
On 08.01.2012 13:49, Jonathan M Davis wrote:
On Sunday, January 08, 2012 13:06:06 simendsjo wrote:
Certainly not obvious to me :)
Well, what's obvious to one person is not always obvious to another. I'm sure
that there are plenty of things that Walter thinks should be perfectly obvious
which
On Sunday, January 08, 2012 14:24:32 simendsjo wrote:
Thanks for your clarifications.
Does this mean even this is undefined?
aa[a] = new C();
auto c = a in aa;
aa[b] = new C();
// Using c here is undefined as an element was added to aa
Yes. Depending on the current implementation of AAs
Jonathan M Davis wrote:
In this case, it's very much like dealing with C++ iterators
A relevant part of Andrei's thread on associative arrays iteration:
http://www.digitalmars.com/d/archives/digitalmars/D/associative_arrays_
iteration_is_finally_here_99576.html#N99614
-manfred
C# has Object Initializers:
http://msdn.microsoft.com/en-us/library/bb384062.aspx
Java has Double Brace Initializers:
http://www.c2.com/cgi/wiki?DoubleBraceInitialization
D has with: http://dlang.org/statement.html#WithStatement
The nice thing about object initializers is that you can
Hi,
Is there a reason 'ref' is disallowed for local variables? I want to
write something like:
MapTile[] map; // It's a struct
ref MapTile tile=map[y*w+x];
tile.id=something;
tile.isWall=true;
My actual case is more complicated, so inlining the expression
everywhere would be messy. I
MapTile[] map; // It's a struct
ref MapTile tile=map[y*w+x];
tile.id=something;
tile.isWall=true;
MapTile* tile = map[y*w+x];
Based on these arguments does that mean std.file.remove should
not be throwing when a file doesn't exist?
Or more precisely should I add a bugzilla entry to change this. I
certainly have a lot of if(exists) remove() in my code and end up
having to change where I just use remove().
On
Sorry, didn't read the rest. ^^
On 08.01.2012 18:54, Ben Davis wrote:
Hi,
Is there a reason 'ref' is disallowed for local variables? I want to
write something like:
MapTile[] map; // It's a struct
ref MapTile tile=map[y*w+x];
tile.id=something;
tile.isWall=true;
My actual case is more complicated, so inlining the
I also meant to say: 80x25? Epic :D
On 08/01/2012 20:25, Ben Davis wrote:
There are two things going on in your example:
1. Use of 'auto' where I'm currently having to write 'MapTile*' and
wanted to write 'ref MapTile'. It will infer 'MapTile*'. Or, if you
forget the , then it will infer
There are two things going on in your example:
1. Use of 'auto' where I'm currently having to write 'MapTile*' and
wanted to write 'ref MapTile'. It will infer 'MapTile*'. Or, if you
forget the , then it will infer 'MapTile' and do the copy that I want
to avoid. So it might be slightly more
Very interesting discussion. Tk u all.
On Sun, 08 Jan 2012 18:54:13 +0100, Ben Davis ent...@cantab.net wrote:
Hi,
Is there a reason 'ref' is disallowed for local variables? I want to
write something like:
MapTile[] map; // It's a struct
ref MapTile tile=map[y*w+x];
tile.id=something;
tile.isWall=true;
My actual case is more
28 matches
Mail list logo
