Re: foreach multiple loop sugar

2015-08-18 Thread Brandon Ragland via Digitalmars-d-learn

On Tuesday, 18 August 2015 at 17:44:00 UTC, Xinok wrote:

On Tuesday, 18 August 2015 at 15:51:55 UTC, ixid wrote:
Though sugar seems to be somewhat looked down upon I thought 
I'd suggest this- having seen the cartesianProduct function 
from std.algorithm in another thread I thought it would be an 
excellent piece of sugar in the language. It's not an earth 
shattering change but it makes something very common more 
elegant and reduces indentation significantly for multiple 
nested loops. Braces make nested loops very messy and any 
significant quantity of code in the loop body benefits from 
not being in a messy nesting.


...


What's wrong with just putting all the foreach statements on a 
single line?


foreach(i; 0..10) foreach(j; 0..10) foreach(k; 0..10)
{
writeln(i, j, k);
}


This.

And it's more obvious what you're trying to do.


Re: Pointers to Dynamic Arrays

2015-08-17 Thread Brandon Ragland via Digitalmars-d-learn

On Monday, 17 August 2015 at 03:07:26 UTC, Adam D. Ruppe wrote:
On Monday, 17 August 2015 at 02:45:22 UTC, Brandon Ragland 
wrote:

[...]


Short answer: pointers to slices are usually a mistake, you 
probably don't actually want it, but rather should be using a 
regular slice instead.



[...]


Here, for example, you've accidentally escaped slice land and 
are unto unchecked pointer arithmetic.


Since file is declared char[]* instead of char[], indexing it 
works C style: it at the index as an offset from the base 
char[].


In other words, it works more as if you wrote `char** file` in 
C. (still not identically, a D slice is different than a C 
char*, but same idea).


The above will only really work fine for index 0. Anything else 
would be a wild pointer. If this didn't crash on you, you just 
got kinda lucky with the index.


The append compiles because dereferencing a `char[]*` yields a 
`char[]`, which D can append normally.




[...]


This errors for the same reason the top one succeeded: what's 
pointed to by a char[]* is char[], not char. So you are trying 
to compare a string on the left hand side to an individual 
character on the right hand side.


In other words, what your error message told :)


[...]


char[] in D is like:

struct char_array {
size_t length;
char* ptr;
}

in C. Since there's already a pointer in there, you typically 
don't want the address of this struct, you just want to pass it 
right down by value and let the pointer be copied (it still 
points to the same actual data).


BTW you can access those .length and .ptr values in D:

char[] slice;
char* a = slice.ptr; // works

The only time you'd actually want a char[]* in D is if you need 
to write back to the original *variable* once you append or 
shrink it. (The contents are fine, they can be modified through 
the slice with no special effort.)



Bottom line again is char[] in D is like char* in C. So char[]* 
in D is more like char** in C.


Thanks Adam.

I keep getting myself confused with D, when I'm thinking in C 
land. Breaking it down like that is extremely helpful.


Going off what you're saying, this signature:

method(char[] file)

Would only copy the _pointer_, as this is similar to the C style 
struct you mentioned:


struct char_array {
size_t len;
char* index;
}

If that is true, than passing it as _char[] file_ makes the most 
sense to me. A pointer copy doesn't hurt as bad as an array copy, 
of say, 100Kibibytes...


-Brandon


D Classes Passed By Reference or Value?

2015-08-16 Thread Brandon Ragland via Digitalmars-d-learn
Hi All, I'm a bit confused as to how Classes in D are passed in 
arguments and returns.


Take this for example:

class MyClass{
int x = 2;
}

And then in app.d

ref MyClass doStuff(){
MyClass mc = new MyClass() // Heap allocation, using new
return mc;
}

The above fails, as escaping reference to local variable 
however, this was created using new Not understanding what 
the deal is, this should be a valid heap allocated object, and 
therefore, why can I not pass this by reference? I don't want 
this to be a local variable...


So this begs the question: Are Classes (Objects) passed by 
reference already?


-Brandon


Re: D Classes Passed By Reference or Value?

2015-08-16 Thread Brandon Ragland via Digitalmars-d-learn

On Sunday, 16 August 2015 at 22:35:15 UTC, Alex Parrill wrote:
On Sunday, 16 August 2015 at 22:31:02 UTC, Brandon Ragland 
wrote:
Hi All, I'm a bit confused as to how Classes in D are passed 
in arguments and returns.


Take this for example:

class MyClass{
int x = 2;
}

And then in app.d

ref MyClass doStuff(){
MyClass mc = new MyClass() // Heap allocation, using new
return mc;
}

The above fails, as escaping reference to local variable 
however, this was created using new Not understanding what 
the deal is, this should be a valid heap allocated object, and 
therefore, why can I not pass this by reference? I don't want 
this to be a local variable...


So this begs the question: Are Classes (Objects) passed by 
reference already?


-Brandon


Classes are reference types, a la Java/C#.

class MyClass {
int x = 5;
}

void main() {
auto c1 = new MyClass();
auto c2 = c1;
c1.x = 123;
assert(c2.x == 123);
}


Thanks,

That makes more sense. Though it does make the ref method 
signature unclear, as it only applies to literals at this point?


Would you still need the ref signature for method parameters for 
classes to avoid a copy? Such that I could work on the class 
itself, and not a copy.



//This is reference?
void doStuff(ref MyClass mc){
return;
}

or would this also be a valid reference type:

//This is a copy?
void doStuff(MyClass mc){
return;
}


Re: D Classes Passed By Reference or Value?

2015-08-16 Thread Brandon Ragland via Digitalmars-d-learn

On Sunday, 16 August 2015 at 23:31:46 UTC, Ali Çehreli wrote:

On 08/16/2015 04:13 PM, Brandon Ragland wrote:

 That makes more sense. Though it does make the ref method
 signature unclear, as it only applies to literals at this
 point?

As long as the returned object will be valid after the function 
leaves, it can be anything: one of the ref parameters, a 
module-level variable, etc.


 Would you still need the ref signature for method parameters
 for classes to avoid a copy? Such that I could work on the
 class itself, and not a copy.

Obviously, you meant the object itself.

 //This is reference?
 void doStuff(ref MyClass mc){
 return;
 }

Yes, that's a reference to a class variable. Since class 
variables are references anyway, unless intended, there is one 
too many level of indirection there. (Although, it is valid and 
it may exactly be what is needed.)


 or would this also be a valid reference type:

 //This is a copy?
 void doStuff(MyClass mc){
 return;
 }

That's the normal way of doing it. mc is class reference to an 
object that was presumably created somewhere else.


Ali


If I understand you correctly than:

void doStuff(MyClass mc){
mc.x = 7;
}

Would be working with the reference to the object instantiated 
elsewhere. This would NOT be a copy of the object.


That would mean that (ref MyClass mc) is the equivalent to a 
pointer to a pointer (sorta, though these are references, same 
idea follows).


-Brandon


Pointers to Dynamic Arrays

2015-08-16 Thread Brandon Ragland via Digitalmars-d-learn

Howdy,

Since Dynamic Arrays / Slices are a D feature, using pointers to 
these has me a bit confused...


Consider:

string c2s(int* pos, char[]* file, int l){
char[] s;
for(int i = 0; i  l; i++){
s ~= file[(*pos + i)];
}
return s.dup;
}

Now what is especially confusing about this, is that the above 
seems to works fine, while this does not:


if(file[(*pos + i)] == '}'){
*pos += i;
return;
}

This fails with this error:
Error: incompatible types for ((file[cast(ulong)(*pos + i)]) == 
('}')): 'char[]' and 'char'


Now what I do not understand, is if the above works, by appending 
come chars gathered from the dynamic array via pointer to me new 
dynamic array named s, and the below does not seem to work on 
comparison of two chars, what is really going on?


I can no longer assume that using the dynamic array pointer works 
anything like a standard pointer to an array, or a pointer to a 
dynamic array.


Is there something I'm missing?

Remember, that de-referencing a dynamic array was deprecated. So 
what I would normally have done: dynamic_array_pntr does not 
work any longer, and there is no new spec on what to do...


-Brandon