I have a few questions about the pseudo built in associative
arrays.
1. Is it possible to have the built in associative array use a
custom allocator from std.experimental.allocator to service it's
allocation needs?
2. A while ago I read on the newsgroup a while back that there
was a
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
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
I have a few questions about the pseudo built in associative arrays.
1. Is it possible to have the built in associative array use a custom
allocator from std.experimental.allocator to service it's allocation needs?
Nope.
2. A while ago I re
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
[...]
Nope.
[...]
As far as I'm aware, you are stuck using e.g. structs to
emulate AA behavior.
I have a VERY basic implementation here:
https://github.com/rikkimax/alphaPhobos
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
On 09/11/15 4:57 PM, TheFlyingFiddle wrote:
[...]
Nope.
[...]
As far as I'm aware, you are stuck using e.g. structs to
emulate AA behavior.
I have a VERY basic imp
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
https://github.com/economicmodeling/containers
I have a question regarding the impleme
On Monday, 9 November 2015 at 21:33:09 UTC, TheFlyingFiddle wrote:
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
https://github.com/e
On Monday, 9 November 2015 at 21:33:09 UTC, TheFlyingFiddle wrote:
On Monday, 9 November 2015 at 04:52:37 UTC, rsw0x wrote:
On Monday, 9 November 2015 at 04:29:30 UTC, Rikki Cattermole
wrote:
Fwiw, EMSI provides high quality containers backed by
std.experimental.allocator.
https://github.com/e
On Tuesday, 10 November 2015 at 01:29:11 UTC, Brian Schott wrote:
Yes. It's a hack that gives you a modulus without having to do
a modulus. It only works on powers of two.
http://graphics.stanford.edu/~seander/bithacks.html#ModulusDivisionEasy
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
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
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
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
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
Jonathan M Davis wrote:
[...]
This sort of explanation is missing in the docs.
-manfred
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
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.
istake is quite tricky, may be using and IDE could help.
This an example that shows that silent failures are sources of bugs...
So this time I don't agree with Jonathan Davis.
Python Zen contains:
Errors should never pass silently.
And Python associative arrays show it:
>>> d = {
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
enforc
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.
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
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 tri
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(
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 i
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 definite
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: http:/
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
> >> http://d.puremagic.com/issues/show
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
http://d.p
On 1/8/12, simendsjo 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 `in` operator.
I fil
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 actually valid at that point. It points to me
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 actua
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
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) key.
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 9
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 implementat
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
On 08.01.2012 14:40, Jonathan M Davis wrote:
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. D
On Sunday, January 08, 2012 14:57:51 simendsjo wrote:
> On 08.01.2012 14:40, Jonathan M Davis wrote:
> > 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;
> >>
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 Sunday,
Very interesting discussion. Tk u all.
Looks like this is fixed for 2.058.
https://github.com/D-Programming-Language/dmd/commit/3e23b0f5834acb32eaee20d88c30ead7e03bb2f4
On 08/01/2012 3:43 AM, 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
assert(key in aa);
aa.remove(key);
So, as far as I can tell, the current situation is more efficient, and it
doesn't cost you any expressiveness. You can still have an exception thrown
when remove fails if you use enforce before the call if you want an exception
thrown when the element isn't ther
On Sun, 08 Jan 2012 08:40:27 -0500, Jonathan M Davis
wrote:
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 a
On Monday, January 09, 2012 09:25:14 Steven Schveighoffer wrote:
> Actually, not invalid for the current implementation. I don't know if
> it's stated whether an AA specifically requires that elements do not
> re-associate on a rehash.
Well, like I said, it depends on the current implementation. T
On 1/9/12, Steven Schveighoffer wrote:
> BTW, dcollections' HashMap, HashSet, and HashMultiset do guarantee that
> adding elements does not invalidated cursors (dcollections' safe version
> of pointers) as long as you use the default Hash implementation. However,
> I just noticed this is not stat
On Mon, 09 Jan 2012 13:35:26 -0500, Andrej Mitrovic
wrote:
On 1/9/12, Steven Schveighoffer wrote:
BTW, dcollections' HashMap, HashSet, and HashMultiset do guarantee that
adding elements does not invalidated cursors (dcollections' safe version
of pointers) as long as you use the default Hash
Ok, allow me to temporarily hijack again and ask: Would you mind
adding opIn_r (or rather the newer opBinaryRight with "in") that
forwards to contains() for the HashSet and similar hash-based classes
that define contains()? It would make porting code that uses builtin
hashes to your own implementat
On Mon, 09 Jan 2012 14:57:36 -0500, Andrej Mitrovic
wrote:
Ok, allow me to temporarily hijack again and ask: Would you mind
adding opIn_r (or rather the newer opBinaryRight with "in") that
forwards to contains() for the HashSet and similar hash-based classes
that define contains()? It would m
On 1/9/12, Steven Schveighoffer wrote:
> Could this be you?
Ah, yes. I didn't even notice you've replied to that, sorry. Yes, I'm
ok with it.
dennis luehring wrote:
> why is there an exception/error neeeded if missing?
Exceptions or errors are not _needed_.
Their existence stems from the modell under which the user of the
operation _has_ to think about the operation, especially whether it
is
a:only the outcome of the operation or
Am 09.01.2012 22:08, schrieb Manfred Nowak:
dennis luehring wrote:
why is there an exception/error neeeded if missing?
Exceptions or errors are not _needed_.
Their existence stems from the modell under which the user of the
operation _has_ to think about the operation, especially whether it
dennis luehring wrote:
> so your FileDelete would not return an FileDoesNotExists-Error?
Correct.
> would it not help to better understand big code if the remove
> would be renamed to remove_existing or to add something like this?
Maybe.
You possibly know about the `rm'-command of *nix-like sys
I'm not questioning the design, but I would like to know the reason:
given the fact that associative arrays are built into the language,
why don't we have static associative arrays?
I have a variant associative array. In the example below I am wondering
if there is a way to create the array without having to indicate the
variant type on all of the values. Would like to be able to write code
like #2, or something cleaner/better for #1. This is intended for a
library. Othe
Is D supposed to be able to handle nested associative arrays ?
--
/Jacob Carlborg
Hello! Is it possible to define associative array on top level of
module?
I try to compile this code and I get message `Error: non-constant
expression ["s":"q", "ss":"qq"]`
import std.stdio;
auto dict = [
"s": "q",
"ss": "qq"
];
void main()
{
writeln(val);
}
I solved i
Hello,
I am new with D and want to convert a c program for a csv file
manipulation with exhaustive dynamic memory mechanics to D .
When reading a CSV-file line by line I would like to create an
associative array to get the row values by the value in the
second column.
Although I save the row
I've got two associative arrays and want to get a new one, which
is created out of both of them:
This works:
string[int] a = [1:"one", 7:"seven"];
string[int] b = [5:"five", 9:"nine"];
string[int] tmp = a.dup;
foreach (k,v;b) tmp[k] = v;
asser
On Saturday, April 07, 2012 18:45:40 Caligo wrote:
> I'm not questioning the design, but I would like to know the reason:
> given the fact that associative arrays are built into the language,
> why don't we have static associative arrays?
What do you mean my static associat
On Sat, Apr 07, 2012 at 09:01:40PM -0700, Jonathan M Davis wrote:
> On Saturday, April 07, 2012 18:45:40 Caligo wrote:
> > I'm not questioning the design, but I would like to know the reason:
> > given the fact that associative arrays are built into the language,
> >
On Sat, Apr 7, 2012 at 11:01 PM, Jonathan M Davis wrote:
>
> What do you mean my static associative arrays? Are you asking why you can't
> initialize a static variable which is an AA at compile time? e.g.
>
> - Jonathan M Davis
The same way I can create a static array:
On Sunday, April 08, 2012 01:24:02 Caligo wrote:
> On Sat, Apr 7, 2012 at 11:01 PM, Jonathan M Davis
wrote:
> > What do you mean my static associative arrays? Are you asking why you
> > can't
> > initialize a static variable which is an AA at compile time? e.g.
&
Jonathan M Davis , dans le message (digitalmars.D.learn:34332), a
écrit :
> On Sunday, April 08, 2012 01:24:02 Caligo wrote:
>> On Sat, Apr 7, 2012 at 11:01 PM, Jonathan M Davis
> wrote:
>> > What do you mean my static associative arrays? Are you asking why you
>>
Byron Heads:
I have a variant associative array. In the example below I am
wondering
if there is a way to create the array without having to
indicate the
variant type on all of the values. Would like to be able to
write code
like #2, or something cleaner/better for #1.
...
// #1 This
On Thursday, 9 May 2013 at 00:10:48 UTC, Byron Heads wrote:
I have a variant associative array. In the example below I am
wondering
if there is a way to create the array without having to
indicate the
variant type on all of the values. Would like to be able to
write code
like #2, or something
On Thu, 09 May 2013 03:29:06 +0200, evilrat wrote:
> first doesn't compile with DMD 2.062 as int implicitly not converted to
> long.
>
> foo func takes associative array, within this example you can use type
> Variant[string] to make life a bit easier(but i can't recommend it for
> ur real code c
On Thu, 09 May 2013 02:33:08 +0200, bearophile wrote:
> Byron Heads:
>
>> I have a variant associative array. In the example below I am
>> wondering if there is a way to create the array without having to
>> indicate the variant type on all of the values. Would like to be able
>> to write code l
Should be. Are you having problems?
(I don't use them much, but fwiw, it seems like tango had some
[trivial?] problems with them)
On 11/12/2010 10:08 AM, Jacob Carlborg wrote:
Is D supposed to be able to handle nested associative arrays ?
On 2010-11-12 17:44, Ellery Newcomer wrote:
Should be. Are you having problems?
(I don't use them much, but fwiw, it seems like tango had some
[trivial?] problems with them)
On 11/12/2010 10:08 AM, Jacob Carlborg wrote:
Is D supposed to be able to handle nested associative arrays ?
Jacob Carlborg:
> module main;
>
> void main ()
> {
> auto tree = ["" : ["" : ""]];
> }
>
> Using DMD 1.065 results in:
>
> Assertion failed: (0), function toExpression, file init.c, line 437.
Please put it in Bugzilla if not already present :-)
Bye,
bearophile
le to handle nested associative arrays ?
Well, yes. The following code:
module main;
void main ()
{
auto tree = ["" : ["" : ""]];
}
Using DMD 1.065 results in:
Assertion failed: (0), function toExpression, file init.c, line 437.
That's static initialisati
lborg wrote:
Is D supposed to be able to handle nested associative arrays ?
Well, yes. The following code:
module main;
void main ()
{
auto tree = ["" : ["" : ""]];
}
Using DMD 1.065 results in:
Assertion failed: (0), function toExpression, file init.c, line 437.
On 2010-11-13 14:39, bearophile wrote:
Jacob Carlborg:
module main;
void main ()
{
auto tree = ["" : ["" : ""]];
}
Using DMD 1.065 results in:
Assertion failed: (0), function toExpression, file init.c, line 437.
Please put it in Bugzilla if not already present :-)
Bye,
bearophile
Wow.
Yeah, I guess all bets are off when it comes to initializations.
In the meantime, I guess you'll have to use
string[string][string] tree;
tree = ["" : ["" : ""]];
On 11/13/2010 05:02 AM, Jacob Carlborg wrote:
Well, yes. The following code:
module main;
void main ()
{
auto tree = ["" :
them)
On 11/12/2010 10:08 AM, Jacob Carlborg wrote:
Is D supposed to be able to handle nested associative arrays ?
Well, yes. The following code:
module main;
void main ()
{
auto tree = ["" : ["" : ""]];
}
Using DMD 1.065 results in:
Assertion failed: (0),
On Sat, 13 Nov 2010 17:27:08 +
div0 wrote:
> > How about "associative array literal" then? Regardless of what you call
> > it I shouldn't get an assertion failure.
> >
>
> True. It's been fixed in dmd2 though, you get:
>
> Error: Integer constant expression expected instead of ""
>
> Whe
On 13/11/2010 20:02, spir wrote:
On Sat, 13 Nov 2010 17:27:08 +
div0 wrote:
How about "associative array literal" then? Regardless of what you call
it I shouldn't get an assertion failure.
True. It's been fixed in dmd2 though, you get:
Error: Integer constant expression expected instea
div0:
> I finally found the bit where it describes associative array literals
> and they look identical to initialising a flat array, so god only knows
> which one gets picked when. It would be better if they where made different.
One of my many enhancement requests, no one disturbs their sleep
On 11/13/2010 02:02 PM, spir wrote:
On Sat, 13 Nov 2010 17:27:08 +
But the compiler (D2) accepts nested aa literals remaining anonymous:
writeln(["a" : ["b" : "c"]]);// --> "a:b:c"
(where "auto aa = ..." fails)
The difference is initializer vs expression.
initializers occu
On 14/11/2010 00:28, Ellery Newcomer wrote:
On 11/13/2010 02:02 PM, spir wrote:
On Sat, 13 Nov 2010 17:27:08 +
But the compiler (D2) accepts nested aa literals remaining anonymous:
writeln(["a" : ["b" : "c"]]); // --> "a:b:c"
(where "auto aa = ..." fails)
The difference is initializer
On Sun, 14 Nov 2010 00:03:48 +
div0 wrote:
> yeah, but dmd's parser was written by hand so it's not surprising there
> are inconsistency's with what works where.
Well, most (all?) truely used languages have hand-written parsers, AFAIK. The
issue is not with writing the parser, I guess, bu
On Sun, 14 Nov 2010 10:35:42 +0100
spir wrote:
> > I finally found the bit where it describes associative array literals
> > and they look identical to initialising a flat array, so god only knows
> > which one gets picked when. It would be better if they where made
> > different.
>
> ... w
o had some
[trivial?] problems with them)
On 11/12/2010 10:08 AM, Jacob Carlborg wrote:
Is D supposed to be able to handle nested associative arrays ?
Well, yes. The following code:
module main;
void main ()
{
auto tree = ["" : ["" : ""]];
}
Using DMD 1.06
I was under the impression that associative arrays now used ?: to find
the best type for the array? Or was this change only made in D2? The
following:
void main()
{
auto foo = [ 2 : "a", 3 : "ab" ];
}
Gives the error:
test.d(3): Error: cannot implicitl
Shouldn't dynamic array be reference type?
uint[][uint] aa;
uint[] temp;
aa[5] = new uint[0];
temp = aa[5]; // copy uint[] reference
temp ~= 1;
assert(temp.length == 1 && temp[0] == 1); // pass
assert(aa[5].length == 1 && aa[5][0] == 1); // fail
Is this a bug?
Foo) foo;
foo = new immutable Foo; // fine
But for immutable associative arrays we can't:
Rebindable!(immutable int[string]) foo; // error
foo = assumeUnique(other);
Error: template instance
std.typecons.Rebindable!(immutable(int[string])) does not match
template declaration Rebindable(T) i
Is there a way to reserve capacity in associative arrays? In some
programs I've been writing I've been getting reasonable
performance up to about 10 million entries, but beyond that
performance is impacted considerably (say, 30 million or 50
million entries). GC stats (via the &q
On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote:
Hello! Is it possible to define associative array on top level
of module?
I try to compile this code and I get message `Error:
non-constant expression ["s":"q", "ss":"qq"]`
import std.stdio;
auto dict = [
"s": "q",
"ss": "
On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote:
Hello! Is it possible to define associative array on top level
of module?
I try to compile this code and I get message `Error:
non-constant expression ["s":"q", "ss":"qq"]`
import std.stdio;
auto dict = [
"s": "q",
"ss": "
On Tuesday, 2 May 2017 at 07:48:35 UTC, ANtlord wrote:
Hello! Is it possible to define associative array on top level
of module?
I try to compile this code and I get message `Error:
non-constant expression ["s":"q", "ss":"qq"]`
import std.stdio;
auto dict = [
"s": "q",
"ss": "
On Tuesday, 2 May 2017 at 08:24:09 UTC, evilrat wrote:
Making enum means that value should be available at compile
time and AA's are fully dynamic. But if my memory serves me
well, you can declare empty AA and delay initialization. So the
closest solution is to move initialization of AA to sh
On Tuesday, 2 May 2017 at 09:50:50 UTC, ANtlord wrote:
On Tuesday, 2 May 2017 at 08:24:09 UTC, evilrat wrote:
Making enum means that value should be available at compile
time and AA's are fully dynamic. But if my memory serves me
well, you can declare empty AA and delay initialization. So
th
On 2017-05-02 09:48, ANtlord wrote:
Hello! Is it possible to define associative array on top level of module?
I try to compile this code and I get message `Error: non-constant
expression ["s":"q", "ss":"qq"]`
import std.stdio;
auto dict = [
"s": "q",
"ss": "qq"
];
void main()
{
w
On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:
Note that when declared as "enum", all places it's referenced,
a new associative array will be allocated.
If it is allocated at all places I can move initialization to
module ctor as says evilrat but how can I make an immutable
a
On Tuesday, 2 May 2017 at 14:37:20 UTC, ANtlord wrote:
On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:
Note that when declared as "enum", all places it's referenced,
a new associative array will be allocated.
If it is allocated at all places I can move initialization to
module
On Tue, May 02, 2017 at 02:37:20PM +, ANtlord via Digitalmars-d-learn wrote:
> On Tuesday, 2 May 2017 at 12:41:01 UTC, Jacob Carlborg wrote:
> >
> > Note that when declared as "enum", all places it's referenced, a new
> > associative array will be allocated.
>
> If it is allocated at all plac
1 - 100 of 377 matches
Mail list logo
