The call is rewriten to _aa_len(aa) and checks for null.
This can almost be done with a normal class, except the compiler inserts a
null check into each member function, iirc.
I guess that's another bit of magic that can't be handled simply.
It can still be done with a struct:
struct AAPimpl
{
On 19/02/2012 15:05, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jhr0qf$24sj$1...@digitalmars.com...
On 19/02/2012 03:31, Daniel Murphy wrote:
Except for this magic initialization, AAs behave the same as classes - ie
a
reference type.
That's not quite true, because 'length' is pas
"Ben Davis" wrote in message
news:jhr0qf$24sj$1...@digitalmars.com...
> On 19/02/2012 03:31, Daniel Murphy wrote:
>> Except for this magic initialization, AAs behave the same as classes - ie
>> a
>> reference type.
>
> That's not quite true, because 'length' is passed around by value
> alongsid
On 19/02/2012 03:31, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jhotcm$13ag$1...@digitalmars.com...
I've seen some line-blurring between 'null' and 'empty' for dynamic arrays
(non-associative). Specifically, I read that array.init returns null for
both static and dynamic, but I thin
On 2/19/12, Timon Gehr wrote:
> Concatenation only works if at least one of the types is an array.
Ah, good point. Still can be worked around:
struct Hash(Key, Val)
{
struct WrapVal(Val)
{
Val val;
auto opCat(Val rhs)
{
return [val] ~ rhs;
}
"Ben Davis" wrote in message
news:jhotcm$13ag$1...@digitalmars.com...
> I've seen some line-blurring between 'null' and 'empty' for dynamic arrays
> (non-associative). Specifically, I read that array.init returns null for
> both static and dynamic, but I think I also read that a dynamic array's
On 02/19/2012 12:40 AM, Andrej Mitrovic wrote:
On 2/19/12, Andrej Mitrovic wrote:
Chunk[] tempVar = chunks.get("", null) ~ new Chunk();
I've tried making a wrapper type that does this behind the scenes but
it won't work:
struct Hash(Key, Val)
{
Val[Key] aa;
Val opIndex(Key key
On 18/02/2012 23:33, Andrej Mitrovic wrote:
Well it's probably too late to change this behavior. Both the sample
on the hash page and TDPL itself shows the usage of that trick.
That's fine - but let's document it :)
A few things seem to be missing:
- You get a RangeError for reading a nonexis
On 2/19/12, Andrej Mitrovic wrote:
> Chunk[] tempVar = chunks.get("", null) ~ new Chunk();
I've tried making a wrapper type that does this behind the scenes but
it won't work:
struct Hash(Key, Val)
{
Val[Key] aa;
Val opIndex(Key key)
{
return aa.get(key, Val.init);
}
Well it's probably too late to change this behavior. Both the sample
on the hash page and TDPL itself shows the usage of that trick.
Btw, if you really want Type.init if the key doesn't exist you can use
the get method:
Chunk[] tempVar = chunks.get("", null) ~ new Chunk();
To be clear, I'm not too bothered how associative arrays work. My
proposal was merely a means by which the following currently working code:
stuff[previouslyNonexistentKey]++;
could continue to work without relying on a current implementation
quirk-possibly-bug.
If you want to change it not
On 18/02/2012 22:57, Andrej Mitrovic wrote:
Are you familiar with cases where you want regular arrays to return
Type.init when you go out of bounds?
The front page says D isn't meant to be an orthogonal language :P
If you want orthogonality, then associative arrays will have to work
something
Are you familiar with cases where you want regular arrays to return
Type.init when you go out of bounds?
On 18/02/2012 21:42, Ben Davis wrote:
On 18/02/2012 20:54, Andrej Mitrovic wrote:
Returning the default initializer of the value type when the key
doesn't exist is a bad idea. Consider an integer, it's .init value is
0. If I want to check if a value of a key is zero I could easily end
up with a
On Saturday, February 18, 2012 21:54:52 Andrej Mitrovic wrote:
> Returning the default initializer of the value type when the key
> doesn't exist is a bad idea. Consider an integer, it's .init value is
> 0. If I want to check if a value of a key is zero I could easily end
> up with a silent bug:
>
On 18/02/2012 20:54, Andrej Mitrovic wrote:
Returning the default initializer of the value type when the key
doesn't exist is a bad idea. Consider an integer, it's .init value is
0. If I want to check if a value of a key is zero I could easily end
up with a silent bug:
int[string] aa;
aa["foobar
Returning the default initializer of the value type when the key
doesn't exist is a bad idea. Consider an integer, it's .init value is
0. If I want to check if a value of a key is zero I could easily end
up with a silent bug:
int[string] aa;
aa["foobar"] = 5;
if (aa["fobar"] == 0) { } // will alw
Self-correction: I evidently didn't read that array.init returns null
for static arrays. But the point holds for dynamic ones.
On 18/02/2012 19:15, Ben Davis wrote:
On 18/02/2012 13:22, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jho2mf$2a1t$1...@digitalmars.com...
Starting with ma
On 18/02/2012 13:22, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jho2mf$2a1t$1...@digitalmars.com...
Starting with magic initialisation then...
I meant a different magic initialization:
int[int] aa = null;
aa[3] = 7; // aa is magically not null any more
I've seen some line-blurr
On 18/02/2012 13:22, Daniel Murphy wrote:
"Ben Davis" wrote in message
news:jho2mf$2a1t$1...@digitalmars.com...
Starting with magic initialisation then...
I meant a different magic initialization:
int[int] aa = null;
aa[3] = 7; // aa is magically not null any more
Is it vital that e[nonexi
"Ben Davis" wrote in message
news:jho2mf$2a1t$1...@digitalmars.com...
> Starting with magic initialisation then...
>
I meant a different magic initialization:
int[int] aa = null;
aa[3] = 7; // aa is magically not null any more
> Is it vital that e[nonexistentKey] throw a RangeError, or could it
Starting with magic initialisation then...
Is it vital that e[nonexistentKey] throw a RangeError, or could it just
always return the type's default value if the key is absent?
If you change that, then you can make assignment evaluate the RHS fully
before even creating the LHS entry, and you w
"H. S. Teoh" wrote in message
news:mailman.521.1329547094.20196.digitalmar...@puremagic.com...
>
> I agree. AA's are one of the big reasons I chose to learn D. I was very
> happy to finally have a language that has runtime speed comparable to
> C++ and has built-in AA's. Sad to say, I've been rat
On 2/18/12 12:39 AM, H. S. Teoh wrote:
On Fri, Feb 17, 2012 at 09:06:20PM -0800, Jonathan M Davis wrote:
On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
Yeah, but that requires a design that fixes everything, including
literals, template arg deduction, magic initialization etc.
O
On Fri, Feb 17, 2012 at 09:06:20PM -0800, Jonathan M Davis wrote:
> On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
> > Yeah, but that requires a design that fixes everything, including
> > literals, template arg deduction, magic initialization etc.
>
> Oh, it may not be easy, and it
On Saturday, February 18, 2012 15:13:38 Daniel Murphy wrote:
> Yeah, but that requires a design that fixes everything, including literals,
> template arg deduction, magic initialization etc.
Oh, it may not be easy, and it may take some time, but it should probably be
one of the higher priorities.
Yeah, but that requires a design that fixes everything, including literals,
template arg deduction, magic initialization etc.
"Jonathan M Davis" wrote in message
news:mailman.514.1329537168.20196.digitalmar...@puremagic.com...
> On Saturday, February 18, 2012 14:46:21 Daniel Murphy wrote:
>> Ye
On Saturday, February 18, 2012 14:46:21 Daniel Murphy wrote:
> Yes, that's the issue I'm talking about. In this case no comments means no
> disagreements. Unfortunately it requires changes to the AA api/codegen to
> fix, so it will probably be around until we move AAs completely into
> druntime.
Yes, that's the issue I'm talking about. In this case no comments means no
disagreements. Unfortunately it requires changes to the AA api/codegen to
fix, so it will probably be around until we move AAs completely into
druntime.
"bearophile" wrote in message
news:jhn604$5ur$1...@digitalmars.
Daniel Murphy:
> It's 3. It also has the nasty side effect that throwing while evaluating
> the rhs leaves the AA with a default-initialized key.
Maybe related to this thread.
A lot of time ago I have added this issue to Bugzilla, I have never received a
comment on it, so far:
http://d.puremag
It's 3. It also has the nasty side effect that throwing while evaluating
the rhs leaves the AA with a default-initialized key.
When AA[key] needs to be an lvalue, it gets translated to something like:
*_aa_get_lvalue(AA, key)
which creates the key if it doesn't exist and returns a reference to i
I can't easily see what the rules are. Specifically, I'm finding:
Chunk[][char[4]] chunks;
//chunks["DATA"] is an array of Chunk objects, where Chunk is a class.
//I'm using this structure to remember positions of chunks in a file format.
//These both work:
chunks[""]~=new Chunk();
chunks["B
32 matches
Mail list logo
