www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Access Violation when accessing Dynamic Array

reply Jack <Jackoz530 gmail.com> writes:
So yeah I've been trying to experiment with the language when I'm 
met with an Access Violation error.

So I've extracted a string from a file and used it as an index 
for a dynamic array. Stripped code sample is :

/////////////////////////////

void foo()
{
string[string] custom;
string keyword;
string script;

File file = File("read.txt", r);
while(!file.eof())
{
script ~= file.readln();
}

foreach(a; script)
{
keyword ~= a; //assuming keyword is "Mario"
}
keyword = stripLeft(keyword);
custom[keyword] = "sample string";

writeln(keyword); // Outputs "Mario"
writeln(custom[keyword]); // Works fine. Outputs "sample string".
writeln(custom["Mario"]); // First-chance exception: 0xc0000005: 
Access violation

}
/////////////////////////////

So am I doing something wrong here? Did I mess with something 
that I shouldn't have?
If it helps I'm using dmd v.2.069.2 on Win7 64-bit.
Jan 02 2016
next sibling parent tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 16:48:41 UTC, Jack wrote:
 So yeah I've been trying to experiment with the language when 
 I'm met with an Access Violation error.

 So I've extracted a string from a file and used it as an index 
 for a dynamic array. Stripped code sample is :

 /////////////////////////////

 void foo()
 {
 string[string] custom;
 string keyword;
 string script;

 File file = File("read.txt", r);
 while(!file.eof())
 {
 script ~= file.readln();
 }

 foreach(a; script)
 {
 keyword ~= a; //assuming keyword is "Mario"
 }
 keyword = stripLeft(keyword);
 custom[keyword] = "sample string";

 writeln(keyword); // Outputs "Mario"
 writeln(custom[keyword]); // Works fine. Outputs "sample 
 string".
 writeln(custom["Mario"]); // First-chance exception: 
 0xc0000005: Access violation

 }
 /////////////////////////////

 So am I doing something wrong here? Did I mess with something 
 that I shouldn't have?
 If it helps I'm using dmd v.2.069.2 on Win7 64-bit.
Your example does not compile, even after I add the required imports (std.algorithm and std.stdio): Error: template std.algorithm.mutation.stripLeft cannot deduce function from argument types !()(string) Please test your example code before asking for help.
Jan 02 2016
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 16:48:41 UTC, Jack wrote:
 [...]
Also, your sample reads from an external file, "read.txt". Either give us the contents of that file, or change the sample so that it is not required.
Jan 02 2016
parent reply Jack <Jackoz530 gmail.com> writes:
On Saturday, 2 January 2016 at 17:15:53 UTC, tsbockman wrote:
 On Saturday, 2 January 2016 at 16:48:41 UTC, Jack wrote:
 [...]
Also, your sample reads from an external file, "read.txt". Either give us the contents of that file, or change the sample so that it is not required.
Woops, sorry about that. It's about late midnight around here so I didn't really notice. I can't seem to replicate the problem with the dumbed down example(ironic yes). So I'll just send the whole file if you don't mind: http://dpaste.com/11V5BYA (Line 174-183) The contents of the .txt file is : http://dpaste.com/3FVW5QR I just checked it and it compiles but it does that strange Access Violation error.
Jan 02 2016
next sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 17:39:42 UTC, Jack wrote:
 So I'll just send the whole file if you don't mind:

 http://dpaste.com/11V5BYA (Line 174-183)

 The contents of the .txt file is :
 http://dpaste.com/3FVW5QR

 I just checked it and it compiles but it does that strange 
 Access Violation error.
By far the most likely explanation for an exception at that location, would be if `custom_keyword` really didn't contain a valid key into the `custom` associative array. So, to check I added this code: writefln("custom_keyword: \"%s\"", custom_keyword); stdout.flush(); // This may be required if you're running the code inside an IDE. readln(); Right before `custom[custom_keyword]`. This printed the following: custom_keyword: "Mario " Notice the extra space at the end. The solution is to use `strip()` rather than `stripLeft()`.
Jan 02 2016
parent Jack <Jackoz530 gmail.com> writes:
On Saturday, 2 January 2016 at 17:56:12 UTC, tsbockman wrote:
 On Saturday, 2 January 2016 at 17:39:42 UTC, Jack wrote:
 [...]
By far the most likely explanation for an exception at that location, would be if `custom_keyword` really didn't contain a valid key into the `custom` associative array. So, to check I added this code: writefln("custom_keyword: \"%s\"", custom_keyword); stdout.flush(); // This may be required if you're running the code inside an IDE. readln(); Right before `custom[custom_keyword]`. This printed the following: custom_keyword: "Mario " Notice the extra space at the end. The solution is to use `strip()` rather than `stripLeft()`.
Thank you! I can't believe I haven't noticed the whitespace. I should stop staying up late at night.
Jan 02 2016
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
On Saturday, 2 January 2016 at 17:39:42 UTC, Jack wrote:
 So I'll just send the whole file if you don't mind:

 http://dpaste.com/11V5BYA (Line 174-183)

 The contents of the .txt file is :
 http://dpaste.com/3FVW5QR
I didn't put a lot of effort into trying to actually understand what you're doing, but a couple of other issues that jumped out at me were: 1) You don't need to use `cmp` to compare strings - this isn't Java :) Just use `==` directly - in D this will compare the strings by value, not reference. (If you actually need to compare by reference, you can use `is` or compare the `.ptr` properties.) 2) `if(some_bool == true)` is redundant - just write `if(some_bool)`. Similarly, `if(some_bool == false)` can be shortened to `if(! some_bool)`. 3) Currently, there is no reason for `flags` to be an associative array; it could be replaced by a simple list of variables: bool keyword = false, initialize = false, gameObject_init = false, movement = false, playMusic = false, playSound = false; This would be *much* faster than doing an associative array lookup for every single character in `script`. 4) The value type for the string[string] fields symbol, symbol_init, and keywords could be changed to custom `enum` types, instead of `string`, which would again be much faster.
Jan 02 2016
parent reply Jack <Jackoz530 gmail.com> writes:
On Saturday, 2 January 2016 at 18:14:24 UTC, tsbockman wrote:
 On Saturday, 2 January 2016 at 17:39:42 UTC, Jack wrote:
 So I'll just send the whole file if you don't mind:

 http://dpaste.com/11V5BYA (Line 174-183)

 The contents of the .txt file is :
 http://dpaste.com/3FVW5QR
I didn't put a lot of effort into trying to actually understand what you're doing, but a couple of other issues that jumped out at me were: 1) You don't need to use `cmp` to compare strings - this isn't Java :) Just use `==` directly - in D this will compare the strings by value, not reference. (If you actually need to compare by reference, you can use `is` or compare the `.ptr` properties.)
I didn't actually knew it works that way because last time I tried using '==' directly it won't compare.
 2) `if(some_bool == true)` is redundant - just write 
 `if(some_bool)`.
 Similarly, `if(some_bool == false)` can be shortened to `if(! 
 some_bool)`.
Yeah I did that in a panic attempt to fix the problem.
 3) Currently, there is no reason for `flags` to be an 
 associative array; it could be replaced by a simple list of 
 variables:

 bool
     keyword = false,
     initialize = false,
     gameObject_init = false,
     movement = false,
     playMusic = false,
     playSound = false;

 This would be *much* faster than doing an associative array 
 lookup for every single character in `script`.
I always thought that associative arrays are much more faster and more clean than this. Thanks I'll keep that in mind
 4) The value type for the string[string] fields symbol, 
 symbol_init, and keywords could be changed to custom `enum` 
 types, instead of `string`, which would again be much faster.
And this is news to me too. I'll keep enums in mind. Overall thank you for your help and advice. I'll seriously keep these in mind.
Jan 02 2016
parent tsbockman <thomas.bockman gmail.com> writes:
On Sunday, 3 January 2016 at 03:41:12 UTC, Jack wrote:
 I didn't actually knew it works that way because last time I 
 tried using '==' directly it won't compare.
Well, there are always many ways that things can go wrong (including compiler bugs), but it SHOULD work, so ask on the forums if it doesn't.
 Yeah I did that in a panic attempt to fix the problem.
Ah yes. I've been there before, myself...
 I always thought that associative arrays are much more faster 
 and more clean than this. Thanks I'll keep that in mind
The associative array itself is quite fast, as long as the data set doesn't have too many hash collisions. But, the lookup as a whole is limited by the speed of the key type's hash code function, and of its comparison function. For, say, an integer, both the hash code and the comparison can be accomplished with about two instructions. Thus, a value_type[int] array would be very fast. However, you are using `string` values as the keys, which means that getting the hash code or doing a comparison involves looping over each character in the `string`. Obviously this is going to be slower. This is not to say it's actually *slow* - don't feel bad about using an associative array with `string` keys if that's really what you need. (And you're likely to need one for *something* since you're writing a parser.) Assuming all the key values (variable names) are known at compile time, using boolean variables directly like I suggested is (nearly) the fastest method possible, because the `string` lookup is done during compilation, and is translated into a simple memory access or register access in the generated assembly code.
 And this is news to me too. I'll keep enums in mind.

 Overall thank you for your help and advice. I'll seriously keep 
 these in mind.
You're welcome.
Jan 03 2016