Re: can't zip a char[5], string[5], real[5]

[Jonathan M Davis via Digitalmars-d-learn]

On Wednesday, October 21, 2015 14:11:20 anonymous via Digitalmars-d-learn wrote:
> On Wednesday, 21 October 2015 at 14:06:54 UTC, Shriramana Sharma
> wrote:
> > import std.stdio, std.range;
> > void mywrite(char [5] chars, real[5] vals)
> > {
> > static string [5] fmts = ["%9.4f, ", "%9.4f; ", "%3d, ",
> > "%3d, ",
> > "%3d\n"];
> > foreach (e; zip(chars, fmts, vals)) write(e[0], " = ",
> > e[1].format(e[2]));
> > }
> >
> > Compiling gives:
> [...]
> > I would have thought there would be no problem in creating a
> > zip of three arrays of equal length. What's the problem here?
>
> Static arrays are not ranges. You can't popFront them. Try
> slicing them: chars[], fmts[], vals[]

Though when you do that, be careful that you don't keep the dynamic arrays
(or any other ranges created from them) around longer than the static
arrays; otherwise, the dynamic arrays will then be referring to invalid
memory, and nasty things will happen...

But as long as the dynamic arrays don't exist longer than the static ones
that they refer to, then you're fine.

- Jonathan M Davis

Re: can't zip a char[5], string[5], real[5]

[anonymous via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 14:06:54 UTC, Shriramana Sharma 
wrote:

import std.stdio, std.range;
void mywrite(char [5] chars, real[5] vals)
{
static string [5] fmts = ["%9.4f, ", "%9.4f; ", "%3d, ", 
"%3d, ",

"%3d\n"];
foreach (e; zip(chars, fmts, vals)) write(e[0], " = ",
e[1].format(e[2]));
}

Compiling gives:

[...]
I would have thought there would be no problem in creating a 
zip of three arrays of equal length. What's the problem here?


Static arrays are not ranges. You can't popFront them. Try 
slicing them: chars[], fmts[], vals[]

Re: toString"z"?

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

On Wednesday, 21 October 2015 at 14:27:52 UTC, Shriramana Sharma 
wrote:
std.string.toStringz – why the strange name with z instead of 
toString0 or toCString?


`stringz` is a traditional name for a Zero terminated string.

toString"z"?

[Shriramana Sharma via Digitalmars-d-learn]

std.string.toStringz – why the strange name with z instead of toString0 or 
toCString?

-- 
Shriramana Sharma, Penguin #395953

Re: What's wrong in this templatized operator overload ?

[MobPassenger via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 04:01:16 UTC, Mike Parker wrote:
On Thursday, 22 October 2015 at 03:19:49 UTC, MobPassenger 
wrote:

code:
---
struct Foo
{
bool opIn_r(T)(T t){return false;}
}



This needs to be marked with const:

struct Foo
{
bool opIn_r(T)(T t) const {return false;}
}


what's the rationale ? what's guaranteed by the qualifier that's 
not already true without const ?

Re: What's wrong in this templatized operator overload ?

[Cauterite via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 04:25:01 UTC, MobPassenger wrote:

On Thursday, 22 October 2015 at 04:01:16 UTC, Mike Parker wrote:
On Thursday, 22 October 2015 at 03:19:49 UTC, MobPassenger 
wrote:

code:
---
struct Foo
{
bool opIn_r(T)(T t){return false;}
}



This needs to be marked with const:

struct Foo
{
bool opIn_r(T)(T t) const {return false;}
}


what's the rationale ? what's guaranteed by the qualifier 
that's not already true without const ?


`const` just means the function won't mutate the object. `const` 
functions can be safely called on mutable, const and immutable 
objects. Non-`const` functions can only be called on mutable 
objects.

Re: What's wrong in this templatized operator overload ?

[Mike Parker via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 03:19:49 UTC, MobPassenger wrote:

code:
---
struct Foo
{
bool opIn_r(T)(T t){return false;}
}



This needs to be marked with const:

struct Foo
{
bool opIn_r(T)(T t) const {return false;}
}

Re: What's wrong in this templatized operator overload ?

[Vladimir Panteleev via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 03:21:35 UTC, MobPassenger wrote:
On Thursday, 22 October 2015 at 03:18:25 UTC, MobPassenger 
wrote:

code:


Plz don't reply, there's been a forum bug while posting.


What forum bug would that be?

Re: Implicit conversion rules

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 19:49:35 UTC, Ali Çehreli wrote:

On 10/21/2015 12:37 PM, Sigg wrote:

> cause at least few more "fun" side effects.

One of those side effects would be function calls binding 
silently to another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

  auto a = 0;  // If the type were deduced by the value,
  foo(a);  // then this would be a call to foo(bool)...
   // until someone changed the value to 2. :)

Ali


Actually 'a' is deduced to be int, so int version is called (as 
expected?). See my example above for the VRO overload issue.

can't zip a char[5], string[5], real[5]

[Shriramana Sharma via Digitalmars-d-learn]

import std.stdio, std.range;
void mywrite(char [5] chars, real[5] vals)
{
static string [5] fmts = ["%9.4f, ", "%9.4f; ", "%3d, ", "%3d, ", 
"%3d\n"];
foreach (e; zip(chars, fmts, vals)) write(e[0], " = ", 
e[1].format(e[2]));
}

Compiling gives:

zip_string.d(5): Error: template std.range.zip cannot deduce function from 
argument types !()(char[5], string[5], real[5]), candidates are:
/usr/include/dmd/phobos/std/range/package.d(3678):
std.range.zip(Ranges...)(Ranges ranges) if (Ranges.length && allSatisfy!
(isInputRange, Ranges))
/usr/include/dmd/phobos/std/range/package.d(3711):
std.range.zip(Ranges...)(StoppingPolicy sp, Ranges ranges) if (Ranges.length 
&& allSatisfy!(isInputRange, Ranges))

I would have thought there would be no problem in creating a zip of three 
arrays of equal length. What's the problem here?

-- 
Shriramana Sharma, Penguin #395953

How to install DMD 64bit on Windows?

[Gary Willoughby via Digitalmars-d-learn]

How to install DMD 64bit on Windows? Is it just a case of 
downloading from here and it just works?


http://dlang.org/download.html

Or do I need Visual Studio installed?

Implicit conversion rules

[Sigg via Digitalmars-d-learn]

I started reading "The D programming Language" earlier, and came 
to the "2.3.3 Typing of Numeric Operators" section which claims 
that "if at least one participant has type ulong, the other is 
implicitly converted to ulong prior to the application and the 
result has type ulong.".


Now I understand reasoning behind it, and know that adding any 
sufficiently negative value to a ulong/uint/ushort will cause an 
underflow as in following example:


void func() {
int a = -10;
ulong b = 0;
ulong c = a + b;
writefln("%s", c);
}

out: 18446744073709551574

But shouldn't declaring c as auto force compiler to go extra step 
and "properly" deduce result of the "a + b" expression, since its 
already as far as I understand doing magic in the background? 
Basically try to cast rvalues to narrowest type without losing 
precision before evaluating expression.


Or is there a proper way to do math with unsigned and signed 
primitives that I'm not aware of?

Re: How to install DMD 64bit on Windows?

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

Use the .exe installer and it will offer to download and install 
visual studio for you as part for its process.

Re: Overloading an imported function

[Shriramana Sharma via Digitalmars-d-learn]

anonymous wrote:

> Huh. I can't find any specification on this, but apparently the local
> overload set shadows any imported overload sets completely.

Should I file a bug on this then?

-- 
Shriramana Sharma, Penguin #395953

Re: Overloading an imported function

[anonymous via Digitalmars-d-learn]

On Wednesday, October 21, 2015 08:28 PM, Shriramana Sharma wrote:

> Kagamin wrote:
> 
>> http://dlang.org/hijack.html
> 
> Thanks people, but even as per the rules:
> 
> 1. Perform overload resolution independently on each overload set
> 2. If there is no match in any overload set, then error
> 3. If there is a match in exactly one overload set, then go with that
> 4. If there is a match in more than one overload set, then error
> 
> Here there is only one round(real, int) i.e. in the current module and
> only one round(real) i.e. in the imported module, so as per rule 3, there
> should be a clear resolution.
> 
> So why the conflict then?

Huh. I can't find any specification on this, but apparently the local 
overload set shadows any imported overload sets completely.

I don't know if there's a good reason for this. All I can think of is I 
don't want some local `write` function to conflict with std.stdio.write. But 
the local overload set wouldn't need to shadow the others completely for 
that. It would be enough if it took precedence on conflict.

Re: Implicit conversion rules

[Ali Çehreli via Digitalmars-d-learn]

On 10/21/2015 12:37 PM, Sigg wrote:

> cause at least few more "fun" side effects.

One of those side effects would be function calls binding silently to 
another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

  auto a = 0;  // If the type were deduced by the value,
  foo(a);  // then this would be a call to foo(bool)...
   // until someone changed the value to 2. :)

Ali

Re: How to install DMD 64bit on Windows?

[Brad Anderson via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 18:50:08 UTC, Adam D. Ruppe 
wrote:
Use the .exe installer and it will offer to download and 
install visual studio for you as part for its process.


I don't know if that feature has made it into a release yet. I 
don't think Vc2015 is supported yet either in a released version 
of DMD. I could be mistaken on both of these.


If you want to play it say just install VS2013 Community Edition 
then install DMD and everything should just work.

Re: Implicit conversion rules

[anonymous via Digitalmars-d-learn]

On Wednesday, October 21, 2015 07:53 PM, Sigg wrote:

>  void func() {
>  int a = -10;
>  ulong b = 0;
>  ulong c = a + b;
>  writefln("%s", c);
>  }
> 
>  out: 18446744073709551574
> 
> But shouldn't declaring c as auto force compiler to go extra step
> and "properly" deduce result of the "a + b" expression, since its
> already as far as I understand doing magic in the background?
> Basically try to cast rvalues to narrowest type without losing
> precision before evaluating expression.

The problem is of course that int and ulong have no common super type, at 
least not in the primitive integer types. int supports negative values, 
ulong supports values greater than long.max.

As far as I understand, you'd like the compiler to see the values of `a` and 
`b` (-10, 0), figure out that the result is negative, and then make `c` 
signed based on that. That's not how D rolls. The same code must compile 
when the values in `a` and `b` come from run time input. So the type of the 
addition cannot depend on the values of the operands, only on their types.

Or maybe you'd expect an `auto` variable to be able to hold both negative 
and very large values? But `auto` is not a special type, it's just a 
shorthand for typeof(right-hand side). That means, `auto` variables still 
get one specific static type, like int or ulong.

std.bigint and core.checkedint may be of interest to you, if you prefer 
safer operations over faster ones.

http://dlang.org/phobos/std_bigint.html
http://dlang.org/phobos/core_checkedint.html

Re: Implicit conversion rules

[Sigg via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 19:07:24 UTC, anonymous wrote:

The problem is of course that int and ulong have no common 
super type, at least not in the primitive integer types. int 
supports negative values, ulong supports values greater than 
long.max.


Yes, I'm well aware of that. I was under the (wrongful)impression 
that auto was doing much more under the hood and that it was more 
safety oriented, I've prolly mixed it with something else while 
reading some article.


As far as I understand, you'd like the compiler to see the 
values of `a` and `b` (-10, 0), figure out that the result is 
negative, and then make `c` signed based on that. That's not 
how D rolls. The same code must compile when the values in `a` 
and `b` come from run time input. So the type of the addition 
cannot depend on the values of the operands, only on their 
types.


Or maybe you'd expect an `auto` variable to be able to hold 
both negative and very large values? But `auto` is not a 
special type, it's just a shorthand for typeof(right-hand 
side). That means, `auto` variables still get one specific 
static type, like int or ulong.


Ima clarify what I expected using my previous example:

ulong a = 0;
int b = -10;
auto c = a + b;

a gets cast to narrowest primitive type that can hold its value, 
in this case bool since bool can hold 0 value resulting in c 
having value of -10. If a was bigger than max long I'd expect an 
error/exception. Now on the other hand I can see why something 
like this would not be implemented since it would ignore implicit 
conversion table and prolly cause at least few more "fun" side 
effects.


std.bigint and core.checkedint may be of interest to you, if 
you prefer safer operations over faster ones.


http://dlang.org/phobos/std_bigint.html 
http://dlang.org/phobos/core_checkedint.html


This is exactly what I was looking for. Thanks!

Re: Implicit conversion rules

[Marco Leise via Digitalmars-d-learn]

Am Wed, 21 Oct 2015 12:49:35 -0700
schrieb Ali Çehreli :

> On 10/21/2015 12:37 PM, Sigg wrote:
> 
>  > cause at least few more "fun" side effects.
> 
> One of those side effects would be function calls binding silently to 
> another overload:
> 
> void foo(bool){/* ... */}
> void foo(int) {/* ... */}
> 
>auto a = 0;  // If the type were deduced by the value,
>foo(a);  // then this would be a call to foo(bool)...
> // until someone changed the value to 2. :)
> 
> Ali

God forbid anyone implement such nonsense into D !
That would be the last thing we need that we cannot rely on
the overload resolution any more. It would be as if making 'a'
const would change the overload resolution when none of the
overloads deal with constness...

import std.format;
import std.stdio;

string foo(bool b) { return format("That's a boolean %s!", b); }
string foo(uint u) { return format("Thats an integral %s!", u); }

void main()
{
  int a = 2497420, b = 2497419;
const int c = 2497420, d = 2497419;
writeln(foo(a-b));
writeln(foo(c-d));
writeln("WAT?!");
}

-- 
Marco

Re: std.uni general character category

[Charles Hixson via Digitalmars-d-learn]

On 10/20/2015 10:38 AM, Charles Hixson via Digitalmars-d-learn wrote:
In std.uni (D Lib 2.068.2) I can no longer see how to get the general 
category code for a character.  Does anyone know what the currently 
supported way to do that is?


I thought I remembered that I used to be able to directly get the 
general character category, but as a crutch this is what I'm using (and 
checking back to 2012 I apparently couldn't do better then):

charcharCat (dchar ch)
{  if(isAlpha (ch) )return'L';
if(isNumber (ch) )return'N';
if(isWhite (ch) )return'Z';
if(isControl (ch) ) return'C';
if(isPunctuation (ch) )  return'P';
else  return'?';// Includes 
not a character

}

This suffices for my current needs, but it clearly a lot less 
information than the two letter code would be, and sometimes that's what 
I need.

Re: Overloading an imported function

[Shriramana Sharma via Digitalmars-d-learn]

Kagamin wrote:

> http://dlang.org/hijack.html

Thanks people, but even as per the rules:

1. Perform overload resolution independently on each overload set
2. If there is no match in any overload set, then error
3. If there is a match in exactly one overload set, then go with that
4. If there is a match in more than one overload set, then error

Here there is only one round(real, int) i.e. in the current module and only 
one round(real) i.e. in the imported module, so as per rule 3, there should 
be a clear resolution.

So why the conflict then?

-- 
Shriramana Sharma, Penguin #395953

Re: Implicit conversion rules

[Maxim Fomin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 22:49:16 UTC, Marco Leise wrote:

Am Wed, 21 Oct 2015 12:49:35 -0700
schrieb Ali Çehreli :


On 10/21/2015 12:37 PM, Sigg wrote:

 > cause at least few more "fun" side effects.

One of those side effects would be function calls binding 
silently to another overload:


void foo(bool){/* ... */}
void foo(int) {/* ... */}

   auto a = 0;  // If the type were deduced by the value,
   foo(a);  // then this would be a call to foo(bool)...
// until someone changed the value to 2. :)

Ali


God forbid anyone implement such nonsense into D !
That would be the last thing we need that we cannot rely on
the overload resolution any more. It would be as if making 'a'
const would change the overload resolution when none of the
overloads deal with constness...



AFAIK it was implemented long time ago and discussed last time 
couple of years ago with example similar to Ali's.


void foo(bool)
void foo(int)

foo(0); // bool
foo(1); // bool
foo(2); // int

error detected at """ ch in unicode.C """ Library error?

[Charles Hixson via Digitalmars-d-learn]

To me this looks like a library error, but I'm not sure.  Any suggestions
importstd.uni;

chargcCat1(dchar ch)
{  if(ch in unicode.L)return'L';//Letter
if(ch in unicode.M)return'M';//Mask
if(ch in unicode.C)return'C';//  Control
<<== error here!

if(ch in unicode.N)return'N';//  Numeric
if(ch in unicode.P)return'P';//  Punctuation
if(ch in unicode.S)return'S';//  Symbol
if(ch in unicode.Z)return'Z';//  Separator

return'?';
}

$ rdmd --main -unittest test2.d
/usr/include/dmd/phobos/std/uni.d(6220): Error: slice [0..2] exceeds 
array bounds [0..1]
/usr/include/dmd/phobos/std/uni.d(6220):called from here: 
comparePropertyName(name[0..2], "In")
/usr/include/dmd/phobos/std/uni.d(6119):called from here: 
findAny("C")
/usr/include/dmd/phobos/std/uni.d(6122): Error: static assert  "No 
unicode set by name C was found."

test2.d(7):instantiated from here: opDispatch!"C"
Failed: ["dmd", "-unittest", "-v", "-o-", "test2.d", "-I."]


$ dmd
DMD64 D Compiler v2.068.2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
Config file: /etc/dmd.conf
...

What's wrong in this templatized operator overload ?

[MobPassenger via Digitalmars-d-learn]

code:
---
struct Foo
{
bool opIn_r(T)(T t){return false;}
}

static immutable Foo foo; // ouch
//static Foo foo; // OK

void main()
{
assert("a" !in foo);
}
---

output:
---
Error: template Foo.opIn_r cannot deduce function from argument 
types !()(string) immutable, candidates are:

runnable.Foo.opIn_r(T)(T t)
---

What's wrong in this templatized operator overload ?

[MobPassenger via Digitalmars-d-learn]

code:
---
struct Foo
{
bool opIn_r(T)(T t){return false;}
}

static immutable Foo foo; // ouch
//static Foo foo; // OK

void main()
{
assert("a" !in foo);
}

Re: What's wrong in this templatized operator overload ?

[MobPassenger via Digitalmars-d-learn]

On Thursday, 22 October 2015 at 03:18:25 UTC, MobPassenger wrote:

code:


Plz don't reply, there's been a forum bug while posting. Full 
post is here: 
http://forum.dlang.org/thread/kaqyeiakjunqoexos...@forum.dlang.org

Re: Overloading an imported function

[Kagamin via Digitalmars-d-learn]

http://dlang.org/hijack.html

Re: Overloading an imported function

[John Colvin via Digitalmars-d-learn]

On Wednesday, 21 October 2015 at 12:05:27 UTC, Shriramana Sharma 
wrote:

import std.math;
real round(real val, int prec)
{
real pow = 10 ^^ prec;
return round(val * pow) / pow;
}

Trying to compile this I get:

foo.d(5): Error: function foo.round (real val, int prec) is not 
callable using argument types (real)


When I've imported std.math which contains round(real), why is 
the compiler complaining about not being able to call the 
overload function defined in *this* module?


I don't see anything in http://dlang.org/module.html that says 
I cannot define an overload of an imported function. Did I miss 
something?


You might find something useful in section 2 of 
https://github.com/DlangScience/design/blob/master/design.pdf and 
also somewhat related: 
http://arsdnet.net/this-week-in-d/sep-27.html

Re: kxml - parsing AWS API xml respond

[opticron via Digitalmars-d-learn]

On Tuesday, 20 October 2015 at 16:53:19 UTC, holo wrote:

When im checking instance name with such code:

auto test = 
list.parseXPath(`//tagSet/item[key="Name"]/value`)[0].goCData;


it is compiling properly but it is breaking program when is no 
name set.


I make quick workaround:

auto tmp = 
list.parseXPath(`//tagSet/item[key="Name"]/value`);

if(tmp == null)
{
instances[tmpinst].instanceName = "";
}
else
{
auto instances[tmpinst].instanceName = 
tmp[0].getCData;

}


but is there any reason why it is not taken into consideration 
in "getCData" method?


The issue you're running into is that parseXPath always returns 
an array of results, even when there are zero or only 1 result. 
kxml can't know in advance how many results there will be for the 
given query, so it will always return an array no matter how many 
results are found.


To work around this issue, you could define a function like so:

string getCData(XmlNode[]nodes) {
  if (!nodes.length) return "";
  return nodes[0].getCData();
}

and in use:

auto test = 
list.parseXPath(`//tagSet/item[key="Name"]/value`).getCData();


This takes advantage of UFCS to keep the call chaining and hide 
[0] while handling the possibility of an empty list.

Overloading an imported function

[Shriramana Sharma via Digitalmars-d-learn]

import std.math;
real round(real val, int prec)
{
real pow = 10 ^^ prec;
return round(val * pow) / pow;
}

Trying to compile this I get:

foo.d(5): Error: function foo.round (real val, int prec) is not callable 
using argument types (real)

When I've imported std.math which contains round(real), why is the compiler 
complaining about not being able to call the overload function defined in 
*this* module?

I don't see anything in http://dlang.org/module.html that says I cannot 
define an overload of an imported function. Did I miss something?

-- 
Shriramana Sharma, Penguin #395953

Re: Just one time

[Andrea Fontana via Digitalmars-d-learn]

On Tuesday, 20 October 2015 at 18:08:33 UTC, Ali Çehreli wrote:

On 10/20/2015 08:48 AM, Andrea Fontana wrote:
It happens I need to perform an operation just one time 
(inside a

function, a loop...)


An idea that uses a function pointer where the first step does 
its task and then sets the stage for the following steps:


import std.stdio;
import std.range;
import std.algorithm;

void firstStep() {
writeln("First call!");
takeAStep = 
}

void followingSteps() {
writeln("Just another call");
}

auto takeAStep = 

void main() {
3.iota.each!(_ => takeAStep());
}

First call!
Just another call
Just another call

Ali


Nice idea, but I can't "reuse" it :)