On 2/14/16 10:22 PM, Jon D wrote:
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
On Monday, 15 February 2016 at 05:29:23 UTC, sigod wrote:
On Monday, 15 February 2016 at 03:22:44 UTC, Jon D wrote:
Is there a way to reserve capacity in associative arrays?
[snip]
Maybe try using this: http://code.dlang.org/packages/aammm
Thanks, I wasn't aware of this package. I'll give
On Monday, 15 February 2016 at 03:22:44 UTC, Jon D wrote:
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
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 "--DRT-
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
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 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
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.
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.
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 plan
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 read
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:
On Sunday, 9 August 2015 at 12:54:39 UTC, Nicholas Wilson wrote:
On Sunday, 9 August 2015 at 01:29:16 UTC, Christopher Davies
wrote:
[...]
using UFCS (universal function call syntax) you would normally
write that as:
records =records.filter!(r = r[where] == val)();
and then leveraging D's
On Sunday, 9 August 2015 at 14:23:33 UTC, Chris Davies wrote:
The problem is, based on user input, I am optionally filtering
a list, possibly passing it through 0, 1, 2 or more filters
based on their input. Each successive filter runs on either the
original range or the result of the previous
On Sunday, 9 August 2015 at 01:29:16 UTC, Christopher Davies
wrote:
I'm just learning D. Something I often do in C# is have an
IEnumerable (Range) of some type that is then conditionally
filtered. It looks like this:
IEnumerableDictionarystring, string foo = bar;
if (baz)
{
foo =
On Sunday, 9 August 2015 at 14:35:23 UTC, Marc Schütz wrote:
You can use InputRange:
http://dlang.org/phobos/std_range_interfaces.html#InputRange
e.g.
auto input = yourOriginalData.map!someTransformation;
InputRange!string range;
if(where != )
range =
I'm just learning D. Something I often do in C# is have an
IEnumerable (Range) of some type that is then conditionally
filtered. It looks like this:
IEnumerableDictionarystring, string foo = bar;
if (baz)
{
foo = foo.Where(d = d[key] == value);
}
I'm trying to do the same in D. Here's
Rikki Cattermole:
Foo*[string] bar;
Foo v = *bar.grab(mykey);
Is this the setdefault of Python dicts? If this need is strong a
new function could be added to Phobos (or even druntime if you
want to reduce the number of hash computations).
Bye,
bearophile
of associative arrays. Anyway, while waiting for
a better solution to present itself, we might as well have a look at this very
dirty one. ;)
extern(C) void* _aaGetX(void* aa, const TypeInfo keyti, in size_t
valuesize, in void* pkey);
V* aaGet(K, V)(V[K] arr, K key) {
return
In C++, the index operator for maps will either return a
reference to the existing value if the key can be found, or a
reference to a new, default-initialized value if one with the
given key cannot be found.
In D, an exception is thrown instead when a value with the given
key cannot be
On Wednesday, 18 February 2015 at 00:21:11 UTC, Matt Kline wrote:
if (value) {
should of course be
if (!value) {
Sorry for the typo.
:
Apparently byKeyValue does not exist for associative arrays,
should it?
void main() {
int[string] a;
a.byKeyValue(); //Error: byKeyValue doesn't exist.
}
If it shouldn't could someone remove it from the documentation?
http://dlang.org/hash-map.html
On Saturday, January 24, 2015 12:05:10 Bayan Rafeh via Digitalmars-d-learn
wrote:
On Saturday, 24 January 2015 at 11:18:57 UTC, ketmar wrote:
On Sat, 24 Jan 2015 11:17:03 +, Bayan Rafeh wrote:
Apparently byKeyValue does not exist for associative arrays,
should it?
void main
On Saturday, 24 January 2015 at 11:18:57 UTC, ketmar wrote:
On Sat, 24 Jan 2015 11:17:03 +, Bayan Rafeh wrote:
Apparently byKeyValue does not exist for associative arrays,
should it?
void main() {
int[string] a;
a.byKeyValue(); //Error: byKeyValue doesn't exist
On Sat, 24 Jan 2015 11:17:03 +, Bayan Rafeh wrote:
Apparently byKeyValue does not exist for associative arrays, should it?
void main() {
int[string] a;
a.byKeyValue(); //Error: byKeyValue doesn't exist.
}
If it shouldn't could someone remove it from the documentation
Apparently byKeyValue does not exist for associative arrays,
should it?
void main() {
int[string] a;
a.byKeyValue(); //Error: byKeyValue doesn't exist.
}
If it shouldn't could someone remove it from the documentation?
http://dlang.org/hash-map.html
On Tue, Jan 06, 2015 at 04:18:17PM +, Idan Arye via Digitalmars-d-learn
wrote:
I have an associative array, and I use the `in` operator to get a
reference to a value inside it and store it in a pointer:
int[string] aa;
aa[myKey] = 42;
int* myPointer = myKey in aa;
Is it
. Arrays can be
reallocated, associative arrays can be rehased, and the stuff in
std.collection does not expose the internal references...
Well, the AA will not move your value to another memory location unless
you remove it. Even with a rehash. But this is NOT guaranteed, future
implementations may
be
reallocated, associative arrays can be rehased, and the stuff in
std.collection does not expose the internal references...
I have an associative array, and I use the `in` operator to get a
reference to a value inside it and store it in a pointer:
int[string] aa;
aa[myKey] = 42;
int* myPointer = myKey in aa;
Is it possible that due to rehashing or something D will decide
to move the associative array's
On Tue, Jan 06, 2015 at 05:39:50PM +, Idan Arye via Digitalmars-d-learn
wrote:
[...]
I see... quite a shame there are no built-in data structures that
provide forever-valid references to their members. Arrays can be
reallocated, associative arrays can be rehased, and the stuff
On Thursday, 14 August 2014 at 13:10:58 UTC, bearophile wrote:
Marc Schütz:
Isn't SuperFastHash vulnerable to collision attacks?
D AAs used to be not vulnerable to collision attacks because
they resolved collisions building a red-black tree for each
bucket. Later buckets became linked
Superfast. Though Murmur has gotten good enough that I'm tempted
to switch. At the time, Murmur didn't even have a license so it
wasn't an option.
On Thursday, 14 August 2014 at 13:10:58 UTC, bearophile wrote:
D AAs used to be not vulnerable to collision attacks because
they resolved collisions building a red-black tree for each
bucket. Later buckets became linked lists for speed,
Slight corrections:
It was a effectively a randomized
What hashing algorithm is used for the D implementation of
associative arrays? Where in the D source does the AA code live?
On 08/09/2014 11:33 AM, Gary Willoughby wrote:
What hashing algorithm is used for the D implementation of associative
arrays? Where in the D source does the AA code live?
Paul Hsieh's SuperFastHash:
http://www.azillionmonkeys.com/qed/hash.html
The source is here:
https://github.com/D
On Saturday, 9 August 2014 at 09:33:12 UTC, Gary Willoughby wrote:
What hashing algorithm is used for the D implementation of
associative arrays? Where in the D source does the AA code live?
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/aaA.d
I think it uses
On 08/09/2014 01:43 PM, Gary Willoughby wrote:
On Saturday, 9 August 2014 at 10:28:02 UTC, Mike Wey wrote:
Paul Hsieh's SuperFastHash:
http://www.azillionmonkeys.com/qed/hash.html
Where is this implemented?
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/util/hash.d
On Saturday, 9 August 2014 at 10:28:02 UTC, Mike Wey wrote:
On 08/09/2014 11:33 AM, Gary Willoughby wrote:
What hashing algorithm is used for the D implementation of
associative
arrays? Where in the D source does the AA code live?
Paul Hsieh's SuperFastHash:
http://www.azillionmonkeys.com
#!/usr/bin/rdmd
import std.algorithm;
import std.stdio;
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
$ ./test.d
./test.d(8): Error: template std.algorithm.map cannot deduce
function from argument types !((a) = a - 2)(uint[uint]),
candidates
Freddy:
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
If you need keys or values you have .keys .values, .byKey,
.byValue (the first two are eager). If you need both you are out
of luck, and if you want to write safe code it's better to
On Friday, 1 August 2014 at 23:22:06 UTC, bearophile wrote:
Freddy:
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
If you need keys or values you have .keys .values, .byKey,
.byValue (the first two are eager). If you need both you are
out
On Friday, 1 August 2014 at 23:33:22 UTC, Freddy wrote:
On Friday, 1 August 2014 at 23:22:06 UTC, bearophile wrote:
Freddy:
uint[uint] test;
void main(){
test=[0:2 ,1:3 ,2:4];
writeln(test.map!(a=a-2));
}
If you need keys or values you have .keys .values, .byKey,
.byValue
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
Jack Applegame:
Should Rebindable to support associative arrays?
I guess so. But how to implement it?
Bye,
bearophile
On Saturday, 12 April 2014 at 09:18:12 UTC, bearophile wrote:
Jack Applegame:
Should Rebindable to support associative arrays?
I guess so. But how to implement it?
Bye,
bearophile
May be just like Rebindable for classes?
On Saturday, 12 April 2014 at 09:18:12 UTC, bearophile wrote:
Jack Applegame:
Should Rebindable to support associative arrays?
I guess so. But how to implement it?
Bye,
bearophile
Related: Rebindable supports arrays (Which makes no sense)
https://issues.dlang.org/show_bug.cgi?id=12046
Through Reddit I've found posts about hash-based associative
arrays:
http://bannalia.blogspot.it/2013/10/implementation-of-c-unordered.html
http://bannalia.blogspot.it/2014/01/a-better-hash-table.html
Those little images like this one are excellent at explaining in
a short space the basic
On Thursday, 9 January 2014 at 10:48:22 UTC, bearophile wrote:
Through Reddit I've found posts about hash-based associative
arrays:
http://bannalia.blogspot.it/2013/10/implementation-of-c-unordered.html
I think the worry that a hash function should throw an exception
is a bit over the top
On Tuesday, 5 November 2013 at 17:47:16 UTC, bearophile wrote:
TV[TK] mergeAAs(TK, TV)(TV[TK] aas...) {
It seems even fit for Phobos.
Bye,
bearophile
I have something I would appreciate feedback/criticism on. My
first stab at it worked, but had no support for passing in
const/immutable.
The code below causes a crash. What is the idiomatic way to merge
associative arrays? If there is a simple version that allows the
value at a key to be clobbered by the value of the right hand
operand when there is a collision, that is a start.
import std.stdio;
void main() {
double[string
Daniel Davidson:
Is there a way to do something like this and have opApply be
called for '+'?
If so, is it a bad idea?
import std.stdio;
double[string] opApply(string op)(const double[string][] inputs
...)
if(op == +) {
double[string] result;
foreach( map ; inputs ) {
foreach(
Also, please report the crash in Bugzilla if you haven't already.
d.puremagic.com/issues/
Gary Willoughby:
Are associative arrays stable in D?
See also:
http://d.puremagic.com/issues/show_bug.cgi?id=4179
Bye,
bearophile
On Tuesday, 16 July 2013 at 19:37:14 UTC, Gary Willoughby wrote:
If however you remove the .byKey() call and use .keys instead,
it works!
With byKey, you are iterating over a range of original key
values, meaning that attempting to remove any of them will result
in bad bahavior. With
On Wednesday, 17 July 2013 at 08:31:00 UTC, Mike Parker wrote:
On Tuesday, 16 July 2013 at 19:37:14 UTC, Gary Willoughby wrote:
If however you remove the .byKey() call and use .keys instead,
it works!
With byKey, you are iterating over a range of original key
values, meaning that
On Wednesday, 17 July 2013 at 09:48:06 UTC, monarch_dodra wrote:
I find it disturbing that the built-in property keys would
dup an entire array, and then copy all the keys into that
array, whereas the function byKeys() will simply allow you to
iterate on the keys.
keys is in blatant
On Wednesday, July 17, 2013 19:21:03 Yota wrote:
On Wednesday, 17 July 2013 at 09:48:06 UTC, monarch_dodra wrote:
I find it disturbing that the built-in property keys would
dup an entire array, and then copy all the keys into that
array, whereas the function byKeys() will simply allow you
On 07/17/2013 10:21 AM, Yota wrote:
On Wednesday, 17 July 2013 at 09:48:06 UTC, monarch_dodra wrote:
I find it disturbing that the built-in property keys would dup an
entire array, and then copy all the keys into that array, whereas the
function byKeys() will simply allow you to iterate on
Are associative arrays stable in D? I have to ask because i'm
having a great deal of problems with them for simple operations.
For example the following crashes.
import std.stdio;
void main(string[] args)
{
int[string] waiting;
waiting[gary] = 1;
waiting[tess] = 2
On Tuesday, July 16, 2013 21:37:13 Gary Willoughby wrote:
Are associative arrays stable in D? I have to ask because i'm
having a great deal of problems with them for simple operations.
For example the following crashes.
import std.stdio;
void main(string[] args)
{
int[string] waiting
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 cause
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 like #2,
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.
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
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
Am Mon, 15 Apr 2013 13:06:01 -0400
schrieb Steven Schveighoffer schvei...@yahoo.com:
On Sun, 14 Apr 2013 02:50:07 -0400, gedaiu szabobog...@yahoo.com wrote:
On Saturday, 13 April 2013 at 21:10:16 UTC, Nicolas Guillemot wrote:
I think we should introduce a removeAll function for hashes.
On Sunday, 14 April 2013 at 06:50:08 UTC, gedaiu wrote:
On Saturday, 13 April 2013 at 21:10:16 UTC, Nicolas Guillemot
wrote:
I think we should introduce a removeAll function for hashes.
Either
through Druntime or through a UFCS function that we could put
in
std.array or somewhere.
How about
You could set the length to 0.
Not on associative arrays afaik.
On Monday, 15 April 2013 at 11:36:55 UTC, Tobias Pankrath wrote:
You could set the length to 0.
On Sun, 14 Apr 2013 02:50:07 -0400, gedaiu szabobog...@yahoo.com wrote:
On Saturday, 13 April 2013 at 21:10:16 UTC, Nicolas Guillemot wrote:
I think we should introduce a removeAll function for hashes. Either
through Druntime or through a UFCS function that we could put in
std.array or
On Monday, 15 April 2013 at 11:36:55 UTC, Tobias Pankrath wrote:
You could set the length to 0.
Before version 4.0 in C# a Clear extension-method just calls
Collection.length = 0; Later this method was included to BCL.
In D length property for AA is readonly.
On Saturday, 13 April 2013 at 21:10:16 UTC, Nicolas Guillemot
wrote:
I think we should introduce a removeAll function for hashes.
Either
through Druntime or through a UFCS function that we could put
in
std.array or somewhere.
How about .clear() for consistency with C++ containers?
It looks
Hi,
I have an associative array: string values[string], and i want to
remove all the values from this array. I looked at the
documentation here: http://dlang.org/hash-map.html and i can't
see any method for this action.
There is a nice way to remove the values, or I should use foreach?
Hey gedaiu,
I'm still a novice to D, but here are some solutions I found.
They can probably be improved.
1) Assigning to it an empty map
https://ideone.com/h7ffmD
2) Removing all entries
https://ideone.com/E7k2WL
My guess is that the first method is more efficient. I wish I
knew how to do
On Saturday, 13 April 2013 at 09:09:36 UTC, Nicolas Guillemot
wrote:
Hey gedaiu,
I'm still a novice to D, but here are some solutions I found.
They can probably be improved.
1) Assigning to it an empty map
https://ideone.com/h7ffmD
2) Removing all entries
https://ideone.com/E7k2WL
My guess
values = null;
and it seems it works great. But, i don't know how correct is
this... I was expecting to have a clear() method on array.
Makes sense to me! Looks like the technique you described is
explained here: http://ddili.org/ders/d.en/null_is.html
Good find, thanks for sharing!
On 4/13/13, gedaiu szabobog...@yahoo.com wrote:
looks great, but i cleared the array like this:
values = null;
That's not clearing the array, that's clearing the reference to the
array. For example:
void main()
{
int[int] hash;
hash[1] = 1;
auto hash2 = hash; // new reference
On Saturday, 13 April 2013 at 09:52:45 UTC, Andrej Mitrovic wrote:
On 4/13/13, gedaiu szabobog...@yahoo.com wrote:
looks great, but i cleared the array like this:
values = null;
That's not clearing the array, that's clearing the reference to
the
array. For example:
void main()
{
On 4/13/13, gedaiu szabobog...@yahoo.com wrote:
I know, that's why I am asking how i should do this...
I think we should introduce a removeAll function for hashes. Either
through Druntime or through a UFCS function that we could put in
std.array or somewhere.
Putting it in Druntime is probably
I think we should introduce a removeAll function for hashes.
Either
through Druntime or through a UFCS function that we could put in
std.array or somewhere.
How about .clear() for consistency with C++ containers?
How safe is it to rely on doing something like this:
uint[size_t] x;
foreach(i; iota(0, 10))
x[i]++;
foreach(i; iota(5, 15))
x[i]++;
... ? In this case correct output comes out -- that is, values for keys 1-4
and 10-14 come out as 1, values for keys 5-9 come out
Joseph Rushton Wakeling:
How safe is it to rely on doing something like this:
uint[size_t] x;
foreach(i; iota(0, 10))
x[i]++;
foreach(i; iota(5, 15))
x[i]++;
This is part of the D associative array specs, so in theory it's
safe, but you have to keep this
Le 11/11/2012 12:38, Manfred Nowak a écrit :
Jakse wrote:
It would also be interesting to have ideas for the general
case
Yes, ideas might be interesting. :-)
A root of good hashing is incorporated in algorithm2 of your
posting:
spread the values produced by the hash function uniformly
pressing reason for avoiding associative arrays as it happens was
simply that I was getting unacceptably large memory usage as a result: I'd got
some data stored in the form of byte[size_t] (really this should have been a set
of size_t's, but this seemed theoretically an acceptable stop gap while
Jakse wrote:
It would also be interesting to have ideas for the general
case
Yes, ideas might be interesting. :-)
A root of good hashing is incorporated in algorithm2 of your
posting:
spread the values produced by the hash function uniformly over
the interval size_t.min .. size_t.max.
of the object.
As another case, a single class object is owned by the runtime but many
class variables of it can exist in multiple AAs.
The more pressing reason for avoiding associative arrays as it happens
was simply that I was getting unacceptably large memory usage as a
result: I'd got some
On 11/11/2012 07:40 PM, Ali Çehreli wrote:
I think std.container.RedBlackTree can take that responsibility but if you don't
need the elements to be in any particular order, then it may be seen as an
overkill as well.
I know, and I probably should give that a go, but as I've got working code
=?UTF-8?B?QWxpIMOHZWhyZWxp?= wrote:
but the hash buckets are probably singly-linked lists
They are unbalanced binary search trees, which indeed turn to
singly-linked lists on sorted input.
-manfred
Hello,
Thanks for this complete answer. I will take a look to your code.
Additionally, Ali gave me a really interesting link about hashing, good
practices, what is efficient, etc. If you didn't read it, it might
interest you. Here it is:
On Saturday, 10 November 2012 at 07:55:18 UTC, Raphaël Jakse
wrote:
Hello,
Thanks for this complete answer. I will take a look to your
code.
Ok - good. I've been using 2.061 which I just realized allows
dup on an associative array, a feature which was not available
in 2.060. So mixin(Dup)
or class be hashed? (What about a tuple?)
I ask because I'm considering associative arrays where the key is a custom class
or tuple as part of a current coding project.
. Assuming I don't write a custom
re-implementation, how would a custom struct or class be
hashed? (What about a tuple?)
I ask because I'm considering associative arrays where the key
is a custom class or tuple as part of a current coding project.
Not sure I understand the question. But here
a custom re-implementation,
how would a custom struct or class be hashed? (What about a tuple?)
I ask because I'm considering associative arrays where the key is a
custom class or tuple as part of a current coding project.
For classes, because they are reference types, it is the object
of performance of associative arrays in D
when the hash function is not well designed (returning the same
hash for too many values). When the hash function returns the
same hash for too many values, performance are dramatic (See
the end of the post for more information).
This makes sense
Hello everybody,
we had a conversation with Ali Cehreli about the right ways of
hashing values / objects. This is related to the D language when
using associative arrays but applies for any language as well.
One of the points was, we have the following class:
==
class Student // class
On Saturday, 1 September 2012 at 09:16:30 UTC, Jonathan M Davis
wrote:
[SNIP]
so it looks like not only do all instances of the same string
enum use the
same memory, but another enum with the same string literal
shares it as well.
So, only one is allocated. And on Linux at least, as I
On 09/02/2012 03:45 PM, monarch_dodra wrote:
On Saturday, 1 September 2012 at 09:16:30 UTC, Jonathan M Davis
wrote:
[SNIP]
so it looks like not only do all instances of the same string enum use
the
same memory, but another enum with the same string literal shares it
as well.
So, only one is
On Sunday, 2 September 2012 at 16:20:16 UTC, Timon Gehr wrote:
On 09/02/2012 03:45 PM, monarch_dodra wrote:
FYI: I get the exact same behavior in Windows. Not that it
matters, but it sounded like you were asking.
I'm a bit confused now though: Why would someone want to use an
enum when they
On 09/02/2012 06:26 PM, monarch_dodra wrote:
On Sunday, 2 September 2012 at 16:20:16 UTC, Timon Gehr wrote:
On 09/02/2012 03:45 PM, monarch_dodra wrote:
FYI: I get the exact same behavior in Windows. Not that it
matters, but it sounded like you were asking.
I'm a bit confused now though: Why
101 - 200 of 352 matches
Mail list logo
