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);
I'm not sure why it doesn't in D, but I thought I rem
Jonathan M Davis wrote:
> So, as far as I can tell, the current situation is more efficient
There are some more arguments:
1) Different threads might want to `remove' the same key from the AA. I
don't see a reason why only the first served thread should complete the
operation without an error.
On Saturday, January 07, 2012 21:54:07 bearophile wrote:
> Maybe D associative arrays too should have both kinds of deleting methods
> :-)
Why? What's the gain? If you care that the element is already in the AA, then
do either
assert(key in aa);
aa.remove(key);
or
enforce(key in aa);
aa.remove
RenatoL:
> 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 using and IDE could he
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 using and IDE could help.
On Sunday, January 08, 2012 00:13:12 Manfred Nowak wrote:
> Jonathan M Davis wrote:
>
> [...]
>
> This sort of explanation is missing in the docs.
Which part?
- Jonathan M Davis
Jonathan M Davis wrote:
[...]
This sort of explanation is missing in the docs.
-manfred
On Saturday, January 07, 2012 23:34:05 RenatoL wrote:
> Yes, i agree this may acceptable. On the other hand if i really
> want/have to remove an item i have to be very careful cause a
> trivial typo could cause a disaster
In general, if an element isn't in a container, and you expect it to be
On Saturday, January 07, 2012 15:06:30 Ali Çehreli wrote:
> On 01/07/2012 02:11 PM, RenatoL wrote:
> > Very quick question
> >
> > import std.stdio;
> > void main()
> > {
> >
> >auto arr1 = ["uno":1, "due":2, "tre":3];
> >arr1.remove("xxx");
> >
> > }
> >
> > also in this ca
Yes, i agree this may acceptable. On the other hand if i really
want/have to remove an item i have to be very careful cause a
trivial typo could cause a disaster
RenatoL wrote:
> Would not it be better if an exception was raised?
No, because exceptions are guarenteed to be slow.
> if i write: writeln(arr1["xxx"]);
> runtime expresses its disappointment...
I would be disappointed too, if the commands for removing and for
requesting something are sequence
On 01/07/2012 02:11 PM, RenatoL wrote:
> Very quick question
>
> import std.stdio;
> void main()
> {
>auto arr1 = ["uno":1, "due":2, "tre":3];
>arr1.remove("xxx");
> }
>
> also in this case the compiler does not say anything and the
> program goes out silently ... why? Would not it be bett
Very quick question
import std.stdio;
void main()
{
auto arr1 = ["uno":1, "due":2, "tre":3];
arr1.remove("xxx");
}
also in this case the compiler does not say anything and the
program goes out silently ... why? Would not it be better if an
exception was raised? After all if i writ
Steven Schveighoffer:
> http://d.puremagic.com/issues/show_bug.cgi?id=7243
Thank you :-) I think in Bugzilla there is space for few performance-related
enhancement requests too, if they are about very common/important parts of the
language :-)
Bye,
bearophile
On Sat, 07 Jan 2012 14:24:19 -0500, bearophile
wrote:
Steven Schveighoffer:
Wasted space. An appendable array requires extra space at the end of
the
block to store the 'used' length.
> If the disadvantages are significant is this improvement in Bugzilla
as
> enhancement request?
It'
Steven Schveighoffer:
> Wasted space. An appendable array requires extra space at the end of the
> block to store the 'used' length.
>
> > If the disadvantages are significant is this improvement in Bugzilla as
> > enhancement request?
>
> It's not in bugzilla, but it's strictly a performan
On Sat, 07 Jan 2012 13:29:25 -0500, bearophile
wrote:
Steven Schveighoffer:
Interesting trivia, the compiler actually transforms the following:
struct S
{
int x;
}
auto s = new S;
into this:
auto s = (new S[1]).ptr;
Found that out when revamping the array allocation code. It's one t
Steven Schveighoffer:
> Interesting trivia, the compiler actually transforms the following:
>
> struct S
> {
> int x;
> }
>
> auto s = new S;
>
> into this:
>
> auto s = (new S[1]).ptr;
>
> Found that out when revamping the array allocation code. It's one thing
> that still bugs me becau
On Mon, 02 Jan 2012 18:30:52 -0500, Timon Gehr wrote:
On 01/03/2012 12:02 AM, Mafi wrote:
Am 02.01.2012 23:33, schrieb Timon Gehr:
On 01/02/2012 11:21 PM, RenatoL wrote:
Just curious... the answer of the compiler it's a bit unclear to
me...
T[] is a dynamic array of type T.
T[][] is a dynam
On Thu, 22 Dec 2011 00:01:53 -0500, Vladimir Panteleev
wrote:
On Thursday, 22 December 2011 at 04:15:25 UTC, Froglegs wrote:
You can allocate classes anywhere, if you're OK with forfeiting
safety guarantees. For example, see emplace in std.conv:
http://dlang.org/phobos/std_conv.html#emp
On Wed, 21 Dec 2011 10:54:06 -0500, pompei2 wrote:
Hello.
I want to add the option to iterate objects of my class using foreach. I
need them to be iterable as view-only const and as mutable too. I would
prefer to iterate using the "return a delegate" but if that's not
possible, ranges ar
On Wed, 21 Dec 2011 11:34:18 -0500, pompei2 wrote:
On Wednesday, 21 December 2011 at 16:05:24 UTC, Trass3r wrote:
Can't really answer your original question, but
1. Why don't you use opApply?
2. Why do you use ref int even in the const version?
3. You could also use alias this to allow iterati
Oh, right, thanks!
On 07-01-2012 01:31, H. S. Teoh wrote:
On Sat, Jan 07, 2012 at 12:49:46AM +0100, Alex Rønne Petersen wrote:
On 07-01-2012 00:37, Jonathan M Davis wrote:
On Saturday, January 07, 2012 00:03:39 Alex Rønne Petersen wrote:
Most likely those functions are just implemented using inline
assembly, the
24 matches
Mail list logo
