Re: Doubt - Static multidimension arrays

[Nemo via Digitalmars-d-learn]

On Tuesday, 19 January 2016 at 20:39:37 UTC, tsbockman wrote:

On Tuesday, 19 January 2016 at 19:14:30 UTC, alb wrote:

   [...]


One other thing you may want to keep in mind when working on 
this kind of thing - when you loop over a multi-dimensional 
array, the order matters.


For large arrays, this:

int[c_max][r_max] arr;

foreach(r; 0 .. r_max)
{
foreach(c; 0 .. c_max)
{
// do something with arr[r][c] here
}
}

Can be *much* faster than this:

int[c_max][r_max] arr;

foreach(c; 0 .. c_max)
{
foreach(r; 0 .. r_max)
{
// do something with arr[r][c] here
}
}

The reason is that the first version access the elements in the 
order that they are actually stored in memory, whereas the 
second forces the CPU to jump between rows for each element.



[...]


You're welcome.

And yes, it can definitely be confusing. I understand why the 
array syntax in D is the way it is, but that still doesn't 
always save me from mixing things up once in a while anyway.


I don't remember where I saw it, but actually, in static 
multi-dimensional arrays, arr[0][1] is next to arr[0][0] in 
memory. You can see it with:


void main () {
  ubyte [7][5] arr;
  import std.stdio : writeln;
  writeln ( & arr[0][0], " ", & arr[0][1], " ", & arr [1][0] );
}

Re: Functions that return type

[thedeemon via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote:

I guess the constraints are that of a static language.


(This is not true.)


I'm playing with the design of such a language myself. 
Basically, anything can create/use/return type objects


This is usually possible in dependently typed languages such as 
Idris, Agda or Coq. Check out Idris, it's rather small but very 
nice and interesting.

Re: Distribution of D apps

[Rikki Cattermole via Digitalmars-d-learn]

On 21/01/16 5:01 AM, Dibyendu Majumdar wrote:

Hi,

I am trying to understand the options for distributing a D app to users.
My assumption is that only the shared libraries and binaries need to be
distributed, and I need to include the D libraries. Is this correct?

Thanks and Regards
Dibyendu


Binaries such as such as shared libraries do indeed need to be packaged 
in the distribution.


Static library files do not need to be distributed however.

Distribution of D apps

[Dibyendu Majumdar via Digitalmars-d-learn]

Hi,

I am trying to understand the options for distributing a D app to 
users. My assumption is that only the shared libraries and 
binaries need to be distributed, and I need to include the D 
libraries. Is this correct?


Thanks and Regards
Dibyendu

Re: How to know if opSlice is defined for a type (including built-in types)?

[chardetm via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 15:25:10 UTC, Jonathan M Davis 
wrote:
On Wednesday, January 20, 2016 13:06:00 chardetm via 
Digitalmars-d-learn wrote:
Anyone who has the same problem: I found 
std.range.primitives.hasSlicing 
(https://dlang.org/phobos/std_range_primitives.html#hasSlicing) which does exactly what I want!


Note that because strings are treated as ranges of dchar 
regardless of what their actual character type is, arrays of 
char and wchar (so-called "narrow" strings) are not consider to 
have slicing or random access by the traits in std.range. So, 
hasSlicing!string is false, though for anything other than an 
array of char or wchar, it will do what you're looking for, 
whereas for arrays of char or wchar, you really shouldn't be 
using the slice operator on them without knowing that they're 
what you're operating on so that you take the Unicode issues 
into account correctly.


- Jonathan M Davis


Yes and that was the next step of my problem, it turned out that 
it was already taken into account by hasSlicing!


Thank you very much!

Re: Mixin Template Function Attributes

[Marc Schütz via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


I believe, however, that it _is_ a bug that the imported symbols 
are visible outside the template. Most likely related to the 
infamous https://issues.dlang.org/show_bug.cgi?id=314

Re: Mixin Template Function Attributes

[Marc Schütz via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


It's not a bug. The `@attribute:` syntax applies to all following 
declarations _inside the current scope_, i.e. until your mixin 
templates closing `}`.

Re: Mixin Template Function Attributes

[jmh530 via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 19:19:04 UTC, Marc Schütz wrote:

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


I believe, however, that it _is_ a bug that the imported 
symbols are visible outside the template. Most likely related 
to the infamous https://issues.dlang.org/show_bug.cgi?id=314


Thanks. The fact that one worked and the other didn't was what I 
found weird.

Re: Mixin Template Function Attributes

[jmh530 via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 19:48:04 UTC, jmh530 wrote:
On Wednesday, 20 January 2016 at 19:19:04 UTC, Marc Schütz 
wrote:

On Wednesday, 20 January 2016 at 16:37:31 UTC, jmh530 wrote:
I'm not sure if this is how the behavior is supposed to be or 
if it is a bug.


I believe, however, that it _is_ a bug that the imported 
symbols are visible outside the template. Most likely related 
to the infamous https://issues.dlang.org/show_bug.cgi?id=314


Thanks. The fact that one worked and the other didn't was what 
I found weird.


It looks like this issue covers it
https://issues.dlang.org/show_bug.cgi?id=12735

It appears that there is a pull request in the works to fix the 
behavior.

Re: How to know if opSlice is defined for a type (including built-in types)?

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, January 20, 2016 13:06:00 chardetm via Digitalmars-d-learn wrote:
> Anyone who has the same problem: I found
> std.range.primitives.hasSlicing
> (https://dlang.org/phobos/std_range_primitives.html#hasSlicing)
> which does exactly what I want!

Note that because strings are treated as ranges of dchar regardless of what
their actual character type is, arrays of char and wchar (so-called "narrow"
strings) are not consider to have slicing or random access by the traits in
std.range. So, hasSlicing!string is false, though for anything other than an
array of char or wchar, it will do what you're looking for, whereas for
arrays of char or wchar, you really shouldn't be using the slice operator on
them without knowing that they're what you're operating on so that you take
the Unicode issues into account correctly.

- Jonathan M Davis

Mixin Template Function Attributes

[jmh530 via Digitalmars-d-learn]

I was thinking about using mixin templates to put some 
module-level default information in a single file so that it 
doesn't clutter up other files. It works for imports, but it 
doesn't seem to propagate for function attributes.


module_default.d
---
module module_default;

mixin template module_default()
{
import std.traits : functionAttributes;
import std.stdio : writeln;

@safe:
}

app.d
---
import module_default;

mixin module_default;

int foo(int x)
{
return x;
}

void main() {

writeln(functionAttributes!foo);
}

Compiled with dmd app.d module_default.d on Windows 7 64bit. The 
output is system, when I would expect it to be safe.


I'm not sure if this is how the behavior is supposed to be or if 
it is a bug.

Re: Functions that return type

[BLM768 via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 10:04:03 UTC, burjui wrote:
That's alright. Parsing and AST construction are trivial with 
S-expressions (Lisp-like syntax), so if you use them for the 
early stages of development, you can focus on the type system. 
When you're done with types, you can switch to making a better 
grammar for your language.


True. I'd been playing with the idea of having multiple syntactic 
"front-ends" anyway (mainly for the purpose of making DSLs), so 
it wouldn't be too much of a stretch to use an S-expression 
syntax. One problem, though, is that I'd either have to extend 
that syntax to support some of the constructs I want (i.e array 
literals) or create a bunch of variadic constructor functions 
(which could be evaluated at compile time). Of course, 
S-expression syntax is kind of designed to be extensible...


That's all off-topic, though. ;)

Re: Distribution of D apps

[Adam D. Ruppe via Digitalmars-d-learn]

By default, a binary compiled with D will have the standard 
library statically linked in, so all you need to distribute are 
other shared libs you choose to use (which might include curl btw 
if you use the std.net.curl functions).


But many .exes from D can be distributed alone and expected to 
work.

Re: Partial application of compile time args type deduction

[QAston via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 00:50:49 UTC, Ali Çehreli wrote:

On 01/19/2016 04:22 PM, QAston wrote:

[...]


Is this it? If so, is it already in std.functional? (I could 
not find it. :) )


auto appendMapped(alias f, R, T)(R r, T elem) {
r ~= f(elem);
return r;
}

int minus(int i) {
return -i;
}

unittest {
int[] ar;

template bindFirstParam(alias original, alias func, 
Args...) {

auto bindFirstParam(Args...)(Args args) {
return original!(func, Args)(args);
}
}

alias appendMinus = bindFirstParam!(appendMapped, minus);

assert (appendMinus!(int[], int)(ar, 10) == [-10]); // 
compiles

assert (appendMinus(ar, 10) == [-10]); // doesn't compile
}

void main() {
}

Ali


Works, thanks!

Re: Functions that return type

[burjui via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 04:27:27 UTC, blm768 wrote:
It's not very far along, though. Right now, I have a "compiler" 
that parses integers and parentheses. ;)


That's alright. Parsing and AST construction are trivial with 
S-expressions (Lisp-like syntax), so if you use them for the 
early stages of development, you can focus on the type system. 
When you're done with types, you can switch to making a better 
grammar for your language.

Re: How to know if opSlice is defined for a type (including built-in types)?

[Rikki Cattermole via Digitalmars-d-learn]

On 20/01/16 11:41 PM, chardetm wrote:

Hi everyone,

I was wondering if it was possible to know at compile time if opSlice is
defined for a type, including built-in types like "string". Here is the
code I have:


import std.stdio;

struct Test {
 Test opSlice(size_t i, size_t j) {
 return this; // We don't care what it returns
 }
}

void main () {
 string s = "Hello";
 auto s2 = s[0..2];
 static if (is(typeof())) writeln("Ok string");

 Test t;
 auto t2 = t[0..2];
 static if (is(typeof())) writeln("Ok Test");
}

Output:
Ok Test


How to make it work for "string" too (if possible)? And is there a way
to differentiate "opSlice()" from "opSlice(size_t, size_t)" (or
"opSlice(T, T)" for any T)?

Thank you in advance!


template CanSlice(T) {
	enum CanSlice = __traits(compiles, {T t; auto v = t[0 .. 1];}) || 
__traits(compiles, {T t; auto v = t.opSlice();});

}

Should work.

Re: How to know if opSlice is defined for a type (including built-in types)?

[chardetm via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 10:44:36 UTC, Rikki Cattermole 
wrote:


template CanSlice(T) {
	enum CanSlice = __traits(compiles, {T t; auto v = t[0 .. 1];}) 
|| __traits(compiles, {T t; auto v = t.opSlice();});

}

Should work.


Thanks it works just fine!

How to know if opSlice is defined for a type (including built-in types)?

[chardetm via Digitalmars-d-learn]

Hi everyone,

I was wondering if it was possible to know at compile time if 
opSlice is defined for a type, including built-in types like 
"string". Here is the code I have:



import std.stdio;

struct Test {
Test opSlice(size_t i, size_t j) {
return this; // We don't care what it returns
}
}

void main () {
string s = "Hello";
auto s2 = s[0..2];
static if (is(typeof())) writeln("Ok string");

Test t;
auto t2 = t[0..2];
static if (is(typeof())) writeln("Ok Test");
}

Output:
Ok Test


How to make it work for "string" too (if possible)? And is there 
a way to differentiate "opSlice()" from "opSlice(size_t, size_t)" 
(or "opSlice(T, T)" for any T)?


Thank you in advance!

Re: Function accepting variadic arguments

[Ali Çehreli via Digitalmars-d-learn]

On 01/20/2016 04:38 AM, pineapple wrote:

I'd like to make a constructor which takes a variable list of arguments,
of a short list of possible types, with different handling depending on
the type. I haven't been able to find any documentation or examples that
did quite what I'm trying to. Help?

A fun pseudocode example of what I'm trying to do:

this(...){
 foreach(argument){
 if(argument is a number){
 do stuff with it;
 }else if(argument is of type A){
 do other stuff;
 }else if(argument is of type B){
 yet more stuff;
 }
 }
}



import std.stdio;

struct A {
double d;
}

struct B {
string s;
}

struct C {
this(T...)(T args) {
foreach (arg; args) {
static if (is (typeof(arg) == int)) {
writefln("int: %s", arg);

} else static if (is (typeof(arg) == A) ) {
writefln("A: %s", arg);

} else static if (is (typeof(arg) == B)) {
writefln("B: %s", arg);
}
}
}
}

void main() {
auto c = C(42, A(1.5), B("hello"));
}

Prints:

int: 42
A: A(1.5)
B: B("hello")

And there is another example here:


http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter

Ali

Function accepting variadic arguments

[pineapple via Digitalmars-d-learn]

I'd like to make a constructor which takes a variable list of 
arguments, of a short list of possible types, with different 
handling depending on the type. I haven't been able to find any 
documentation or examples that did quite what I'm trying to. Help?


A fun pseudocode example of what I'm trying to do:

this(...){
foreach(argument){
if(argument is a number){
do stuff with it;
}else if(argument is of type A){
do other stuff;
}else if(argument is of type B){
yet more stuff;
}
}
}

Re: Function accepting variadic arguments

[Daniel Kozak via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 13:06:14 UTC, pineapple wrote:
On Wednesday, 20 January 2016 at 12:56:51 UTC, Ali Çehreli 
wrote:

And there is another example here:


http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter

Ali


Thank you!

What's the purpose of "is" in the type checks?


is is use for compare types



Also, how would I utilize isNumeric from std.traits here, in 
place of checking only for ints?



struct S
 {
 this(Args...)(Args args)
 {
 foreach(Index, Value;args)
 {
 if (isNumeric!(Args[index]))
 {
 ...
 }
 }
 }
 }

Re: Function accepting variadic arguments

[pineapple via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 12:56:51 UTC, Ali Çehreli wrote:

And there is another example here:


http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter

Ali


Thank you!

What's the purpose of "is" in the type checks?

Also, how would I utilize isNumeric from std.traits here, in 
place of checking only for ints?

Re: Function accepting variadic arguments

[Daniel Kozak via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 13:04:23 UTC, Daniel Kozak wrote:

V Wed, 20 Jan 2016 12:38:20 +
pineapple via Digitalmars-d-learn 


napsáno:


import std.stdio;

struct S
{
this(Args...)(Args args)
{
foreach(Type, Value;args)
{
writefln("Type: %s value: %s", Args[Type].stringof, 
Value);

}
}
}

void main()
{
auto s = S(1, "string");
}


Type should be named Index :)

Re: Function accepting variadic arguments

[Daniel Kozak via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 13:09:13 UTC, Daniel Kozak wrote:

On Wednesday, 20 January 2016 at 13:06:14 UTC, pineapple wrote:
On Wednesday, 20 January 2016 at 12:56:51 UTC, Ali Çehreli 
wrote:

And there is another example here:


http://ddili.org/ders/d.en/templates_more.html#ix_templates_more.tuple%20template%20parameter

Ali


Thank you!

What's the purpose of "is" in the type checks?


is is use for compare types



Also, how would I utilize isNumeric from std.traits here, in 
place of checking only for ints?



struct S
 {
 this(Args...)(Args args)
 {
 foreach(Index, Value;args)
 {
 if (isNumeric!(Args[index]))
 {
 ...
 }
 }
 }
 }


isNumeric!(Args[index] should be:
isNumeric!(Args[Index]

Re: Function accepting variadic arguments

[Daniel Kozak via Digitalmars-d-learn]

V Wed, 20 Jan 2016 12:38:20 +
pineapple via Digitalmars-d-learn 
napsáno:

> I'd like to make a constructor which takes a variable list of 
> arguments, of a short list of possible types, with different 
> handling depending on the type. I haven't been able to find any 
> documentation or examples that did quite what I'm trying to. Help?
> 
> A fun pseudocode example of what I'm trying to do:
> 
> this(...){
>  foreach(argument){
>  if(argument is a number){
>  do stuff with it;
>  }else if(argument is of type A){
>  do other stuff;
>  }else if(argument is of type B){
>  yet more stuff;
>  }
>  }
> }
> 

import std.stdio;

struct S
{
this(Args...)(Args args)
{
foreach(Type, Value;args)
{
writefln("Type: %s value: %s", Args[Type].stringof, Value);
}
}
}

void main()
{
auto s = S(1, "string");
}

Re: How to know if opSlice is defined for a type (including built-in types)?

[chardetm via Digitalmars-d-learn]

Anyone who has the same problem: I found 
std.range.primitives.hasSlicing 
(https://dlang.org/phobos/std_range_primitives.html#hasSlicing) 
which does exactly what I want!

Re: Overload dispatch by templated interface type doesn't seem to work

[QAston via Digitalmars-d-learn]

On Wednesday, 20 January 2016 at 14:01:23 UTC, QAston wrote:
To me this suggests that the dispatch by templated interface 
type Visitor!(RETURN) doesn't work. IMO the order of interfaces 
shouldn't matter here and the code should simply work.


Any ideas?


I'm on 2069.2 and when i remove one of the offending classes 
(Print or Eval) class the other compiles and works.

Overload dispatch by templated interface type doesn't seem to work

[QAston via Digitalmars-d-learn]

Hi,

I have the following code:

interface Visitable(RETURN) {
RETURN accept(Visitor!RETURN);
}

interface Exp :  Visitable!string,  Visitable!int {

}

interface Visitor(RETURN) {
RETURN visitLit(Lit e);
RETURN visitAdd(Add e);
}

class Lit : Exp {
int val;
this(int val) {
this.val = val;
}
override int accept(Visitor!int v) {
return v.visitLit(this);
}
override string accept(Visitor!string v) {
return v.visitLit(this);
}
}
class Add : Exp {
Exp lhs, rhs;
this(Exp lhs, Exp rhs) {
this.lhs = lhs;
this.rhs = rhs;
}
override int accept(Visitor!int v) {
return v.visitAdd(this);
}
override string accept(Visitor!string v) {
return v.visitAdd(this);
}
}

class Eval : Visitor!int {
override int visitLit(Lit e) {
return e.val;
}
override int visitAdd(Add e) {
return e.lhs.accept(this) + e.rhs.accept(this);
}
}

class Print : Visitor!string {
override string visitLit(Lit e) {
return to!string(e.val);
}
override string visitAdd(Add e) {
		return "(" ~ e.lhs.accept(this) ~ " + " ~ e.rhs.accept(this) ~ 
")";

}
}

unittest {
auto val = new Add(new Lit(1), new Lit(6)).accept(new Eval());
assert(val == 7);
auto s = new Add(new Lit(1), new Lit(6)).accept(new Print());
assert(s == "(1 + 6)");
}

Which is a dummy AST. It's an example of a visitor pattern. The 
compiler gives the following error for this code:


 Error: function Visitable!string.Visitable.accept 
(Visitor!string) is not callable using argument types (Eval)
 Error: function Visitable!string.Visitable.accept 
(Visitor!string) is not callable using argument types (Eval)


in Eval.visitAdd.

When i swap the order of implemented interfaces in Exp, there's a 
symmetrical error in Print.visitAdd with Visitor!int.


To me this suggests that the dispatch by templated interface type 
Visitor!(RETURN) doesn't work. IMO the order of interfaces 
shouldn't matter here and the code should simply work.


Any ideas?