Re: CTFE output is kind of weired

2017-07-08 Thread H. S. Teoh via Digitalmars-d-learn
On Sat, Jul 08, 2017 at 03:09:09PM -0700, Ali Çehreli via Digitalmars-d-learn 
wrote:
> On 07/08/2017 02:29 PM, Andre Pany wrote:
> 
> > I use assert(false, tmp) to see the content of variable tmp as it
> > seems there is no other way in CTFE.
> 
> A more natural way is pragma(msg), which you can use in main in this
> case:
[...]

Unfortunately, pragma(msg) can only be used *after* CTFE has finished.
It's not possible to print the message *during* CTFE.

Stefan Koch allegedly will add a ctfeWriteln to his new CTFE engine that
should alleviate this limitation.


T

-- 
There is no gravity. The earth sucks.


Re: rdmd vs dmd WRT static constructors

2017-07-08 Thread Andrew Edwards via Digitalmars-d-learn

On Sunday, 9 July 2017 at 03:11:17 UTC, Mike Parker wrote:

On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:

To include stat1.d and stat2.d in the compilation, you'll 
either have to import them in statmain.d or use the 
--extra-file command line switch:


rdmd --extra-file=stat1.d --extra-file=stat2.d statmain.d


Okay, got it... thanks Mike.


Re: rdmd vs dmd WRT static constructors

2017-07-08 Thread Mike Parker via Digitalmars-d-learn

On Sunday, 9 July 2017 at 02:57:54 UTC, Andrew Edwards wrote:



$ rdmd statmain.d stat1.d stat2.d
// outputs nothing...


Bug or intended behaviour?



rdmd takes the first D file you give it, follows its import tree, 
and compiles all the modules found there. Anything on the command 
line after the first source file is treated as a command line 
argument to the generated program. So stat1.d and stat2.d are 
never compiled. You'll see if you modify your main function to 
output the args that it will print the file names you passed.


To include stat1.d and stat2.d in the compilation, you'll either 
have to import them in statmain.d or use the --extra-file command 
line switch:


rdmd --extra-file=stat1.d --extra-file=stat2.d statmain.d


rdmd vs dmd WRT static constructors

2017-07-08 Thread Andrew Edwards via Digitalmars-d-learn
RDMD does not behave the same as DMD WRT static constructors. The 
following example, extracted form Mike Parker's "Learning D", 
does not produce the same result:


// stat1.d
module stat1;
import std.stdio;
static this() { writeln("stat1 constructor"); }

// stat2.d
module stat2;
import std.stdio;
static this() { writeln("stat2 constructor"); }

// statmain.d
void main() { }

$ rdmd statmain.d stat1.d stat2.d
// outputs nothing...

$ dmd statmain.d stat1 stat2
$ ./statmain
// outputs...
stat1 constructor
stat2 constructor

Bug or intended behaviour?

Thanks,
Andrew


Re: CTFE output is kind of weired

2017-07-08 Thread Jonathan M Davis via Digitalmars-d-learn
On Saturday, July 8, 2017 10:12:29 PM MDT Era Scarecrow via Digitalmars-d-
learn wrote:
> On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:
> > app.d(17):called from here: test("1234\x0a5678\x0a")
> >
> > I wrote the source code on windows with a source file with \r\n
> > file endings.
> > But the console output has only the character X0a. In addition
> > not the content of tmp is shown but the full content with the
> > slice information [4..10].
> >
> > Is this the intended behavior?
>
>   The escape sequence says it's hex, and 0a translates to 10, and
> 0d is 13; \r\n is usually a 13,10 sequence. So from the looks of
> it the \r is getting stripped out.
>
>   Funny story as i understand it, \r and \n both have very
> specific meanings to old printers in the old days. \r for
> carriage-Return, and \n for New-line. DOS may have used it, but
> \r more-or-less has no use for newlines and printers today.

It used to matter for terminals as well. With respect to those ancient time,
what Windows does with line endings with \r\n is the most correct, but at
this point, it's just a pointless extra character. AFAIK, no other OS
expects \r\n now. Everything that's *nix-based uses only \n. Unfortunately,
web formats such as http still use \r\n though, because they're based on the
original Internet Message Fomat standard (e-mail really), and it's old
enough that it mattered when it was written.

LOL. As I understand it, the old Macs before Mac OS X actually just used \r,
so twent years ago, depending on your OS, you had to deal with \n, \r, or
\r\n for line endings. Yuck.

>   Curious when using writeln, all newlines seem to have \r
> sequences added. So i suppose it's one of those things that i
> never needed to think about really.

Only if you're on Windows. It's what printf and friends do there too (and
IIRC, writeln still uses printf underneath the hood). C and UNIX pretty much
came into being together, and thus both use \n as the line ending - though
given when they were created, I expect that the distinction between \n and
\r\n still mattered on UNIX systems occasionally. I don't know though. Now
though, no *nix system is going to be doing anything with \r for line
endings.

- Jonathan M Davis



Re: The Nullity Of strings and Its Meaning

2017-07-08 Thread kdevel via Digitalmars-d-learn

Just saw that my first example was wrong, it should read

  1 void main ()
  2 {
  3import std.uri;
  4string a = "";
  5assert (a);
  6auto s = a.decodeComponent;
  7assert (s);
  8 }

The non-nullity was not preserved. Only the second assert fails.

On Saturday, 8 July 2017 at 18:39:47 UTC, ag0aep6g wrote:

On 07/08/2017 07:16 PM, kdevel wrote:


null is one specific array. It happens to be empty, but that 
doesn't really matter. `foo is null` compares with the null 
array. It doesn't check for emptiness. Conversion to bool also 
compares with null. The concept of emptiness is unrelated.


But why? What is the intended use of converting a string (or any 
other dynamic array) to bool?


In Issue 17623 Vladimir pointed out, that in the case of strings 
there may be a need to store an empty D-string which also is a 
NUL-terminated C-String. It would be sufficient if the ptr-Value 
would convert for checking if there is a valid part of memory 
containing the NUL byte.


Moreover everything I've written about strings is also valid for 
e.g. dynamic arrays of doubles. Here there are also two different 
kinds of empty arrays which compare equal but are not identical. 
I see no purpose for that.


I wonder if this distinction is meaningful and---if not---why 
it is

exposed to the application programmer so prominently.


"Prominently"? It only shows up when you convert to bool.


The conversion to bool (in a bool context) is part of the 
interface of the type. The interface of a type *is* prominently 
exposed.


You only get surprised if you expect that to check for 
emptiness (or something else entirely).


As mentioned I was surprised, that the non-nullity did not pass 
thru decodeComponent.


The spec isn't very clear there. What does "the same array 
elements" mean for empty arrays?


Mathematically that's easily answered: 
https://en.wikipedia.org/wiki/Universal_quantification#The_empty_set


(mkdir)
Using DMD v2.073.2 the first expression terminates the 
programm with a

segmentation fault. With 2.074.1 the program prints

: Bad address
: No such file or directory

I find that a bit confusing.


That looks like a bug/oddity in mkdir. null is as valid a 
string as "". It shouldn't give a worse exception message.


But the message for `""` isn't exactly good, either. Of course 
the directory doesn't exist, yet; I'm trying to create it!


I would expect the same error message (ENOENT) in both cases. The 
EFAULT in
the first case occurs if you invoke POSIX mkdir with NULL as 
first argument.


Re: The Nullity Of strings and Its Meaning

2017-07-08 Thread Jonathan M Davis via Digitalmars-d-learn
On Saturday, July 8, 2017 5:16:51 PM MDT kdevel via Digitalmars-d-learn 
wrote:
> Yesterday I noticed that std.uri.decodeComponent does not
> 'preserve' the
> nullity of its argument:
>
> 1 void main ()
> 2 {
> 3import std.uri;
> 4string s = null;
> 5assert (s is null);
> 6assert (s.decodeComponent);
> 7 }
>
> The assertion in line 6 fails. This failure gave rise to a more
> general
> investigation on strings. After some research I found that one
> "cannot implicitly convert expression (s) of type string to bool"
> as in
>
> 1 void main ()
> 2 {
> 3string s;
> 4bool b = s;
> 5 }
>
> Nonetheless in certain boolean contexts strings convert to bool
> as here:
>
> 1 void main ()
> 2 {
> 3import std.stdio;
> 4string s; // equivalent to s = null
> 5writeln (s ? true : false);
> 6s = "";
> 7writeln (s ? true : false);
> 8 }
>
> The code prints
>
> false
> true
>
> to the console. This lead me to the insight, that in D there are
> two
> distinct kinds of empty strings: Those having a ptr which is null
> and
> the other. It seems that this ptr nullity not only determines
> whether
> the string compares equal to null in an IdentityExpression [1]
> but also
> the result of the above mentioned conversion in the boolean
> context.
>
> I wonder if this distinction is meaningful and---if not---why it
> is
> exposed to the application programmer so prominently.
>
> Then today I found this piece of code
>
> 1 void main ()
> 2 {
> 3string s = null;
> 4string t = "";
> 5assert (s is t);
> 6 }
>
> which, according to the wording in [1]
>
>"For static and dynamic arrays, identity is defined as
> referring to
> the same array elements and the same number of elements."
>
> shall succeed but its assertion fails [2]. I anticipate the
> implementation compares the ptrs even in the case of zero
> elements.
>
> A last example of 'deviant behavior' I found is this:
>
>  1 import std.stdio;
>  2 import std.file;
>  3 void main ()
>  4 {
>  5string s = null;
>  6try
>  7   mkdir (s);
>  8catch (Exception e)
>  9   e.msg.writeln;
> 10
> 11s = "";
> 12try
> 13   mkdir (s);
> 14catch (Exception e)
> 15   e.msg.writeln;
> 16 }
>
> Using DMD v2.073.2 the first expression terminates the programm
> with a
> segmentation fault. With 2.074.1 the program prints
>
> : Bad address
> : No such file or directory
>
> I find that a bit confusing.
>
> [1] https://dlang.org/spec/expression.html#identity_expressions
> [2] https://issues.dlang.org/show_bug.cgi?id=17623

A dynamic array in D is essentially

struct DynamicArray(T)
{
size_t length;
T* ptr;
}

That's not _exactly_ what it is at the moment (it actually does stuff with
void* rather than templates unfortunately), but essentially, that's what it
is and what it behaves like.

In the case of dyanamic arrays, null is a dynamic array whose ptr is null
and whose length is 0.

The empty property for arrays checks whether the length of the array is 0.
So, any array with a length of 0 (regardless of its ptr) is considered
empty.

The is expression checks for bitwise equality. So,

arr is null

checks for whether the array has a null ptr and a 0 length. In _most_
circumstances, that's equvialent to checking that the array's ptr is null,
but if you do something screwy with unitialized memory, then you could end
up with a ptr value of null and a non-zero length, and

arr is null

would be false. The == expression, on the other, hand checks that the
elements are equal. So, it does something similar to

if(lhs.length != rhs.length)
return false;
for(size_t i = 0; i < lhs.length; ++i)
{
if(lhs.ptr[i] != rhs.ptr[i])
return false;
}
return true;

So, if the lengths are 0, no iterating happens, and the two arrays are
considered equal. This means that a null array is equal to any other empty
array, regardless of the value of ptr. It's also why I would consider

arr == null

to be a code smell. IMHO, if you want to check for empty, then you should
use the empty property or check length directly, since those are clear about
your intent, whereas with

arr == null

you always have the question of whether they should have used an is
expression or whether they were simpy checking for an empty array.

If you understand all of this, it is perfectly possible to write code which
treats null arrays as distinct from empty arrays. However, it's _very_ easy
to get into a situation where you have an empty array rather than a null
one.  Pretty much as soon as you do anything to a null array other than pass
it around or compare it, trusting that it's still null can get error-prone.
And that's why a number of folks think that it's just plain error-prone to
try and treat null arrays as special - but some folks who understand 

Re: CTFE output is kind of weired

2017-07-08 Thread Era Scarecrow via Digitalmars-d-learn

On Saturday, 8 July 2017 at 21:29:10 UTC, Andre Pany wrote:

app.d(17):called from here: test("1234\x0a5678\x0a")

I wrote the source code on windows with a source file with \r\n 
file endings.
But the console output has only the character X0a. In addition 
not the content of tmp is shown but the full content with the 
slice information [4..10].


Is this the intended behavior?


 The escape sequence says it's hex, and 0a translates to 10, and 
0d is 13; \r\n is usually a 13,10 sequence. So from the looks of 
it the \r is getting stripped out.


 Funny story as i understand it, \r and \n both have very 
specific meanings to old printers in the old days. \r for 
carriage-Return, and \n for New-line. DOS may have used it, but 
\r more-or-less has no use for newlines and printers today.


 Curious when using writeln, all newlines seem to have \r 
sequences added. So i suppose it's one of those things that i 
never needed to think about really.


Re: CTFE output is kind of weired

2017-07-08 Thread Ali Çehreli via Digitalmars-d-learn

On 07/08/2017 02:29 PM, Andre Pany wrote:

> I use assert(false, tmp) to see the content of variable tmp as it seems
> there is no other way in CTFE.

A more natural way is pragma(msg), which you can use in main in this case:

string test(string s)
{
string tmp = s;
tmp = tmp[4..$];
return tmp;
}

enum foo =
`1234
5678
`;

void main()
{
enum bar = test(foo);
pragma(msg, bar);
}

> The output is kind of weired:
> app.d(6): Error: "1234\x0a5678\x0a"[4..10]
> app.d(17):called from here: test("1234\x0a5678\x0a")

Yes, looks pretty weird. :) I remember issues related to Unicode 
characters, which may be fixed by now, but the [4..10] part is news to me.


Ali



CTFE output is kind of weired

2017-07-08 Thread Andre Pany via Digitalmars-d-learn

Hi,

I use assert(false, tmp) to see the content of variable tmp as it 
seems there is no other way in CTFE.


The output is kind of weired:
app.d(6): Error: "1234\x0a5678\x0a"[4..10]
app.d(17):called from here: test("1234\x0a5678\x0a")

I wrote the source code on windows with a source file with \r\n 
file endings.

But the console output has only the character X0a.
In addition not the content of tmp is shown but the full content 
with the slice information [4..10].


Is this the intented behavior?

string test(string s)
{
string tmp = s;
tmp = tmp[4..$];
assert(false, tmp);
return tmp;
}

enum foo =
`1234
5678
`;

void main()
{
enum bar = test(foo);
}

Kind regards
André


Re: Application settings

2017-07-08 Thread Timothee Cour via Digitalmars-d-learn
I use protocol buffers (using dproto) for this, storing my settings in
either text or wire format. Advantages: type-safety with fwd/backward
compatibility (unlike json which requires dynamic field access, eg
with dproto you get errors at compile time instead of runtime),
supports comments (although can be done w preprocessor on json config
file), supports more types than json (especially binary without
needing to base64 encode).


On Sat, Jul 8, 2017 at 11:35 AM, Seb via Digitalmars-d-learn
 wrote:
> On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote:
>>
>> On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote:
>>>
>>> On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote:

 On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:
>
> [...]


 "best" always depends on your specific use case. I use json files via
 asdf [1]

 [1] https://github.com/tamediadigital/asdf
>>>
>>>
>>>
>>> Seems like quite a heavy package for what I need. I just want to write a
>>> AA to disk and load it, ultimately.
>>
>>
>> Then I would go with INI, because you'll ultimately just have key-value
>> pairs.
>>
>> https://code.dlang.org/packages/baussini (Pretty old but should still work
>> just fine.)
>
>
> There is also inifiled: https://github.com/burner/inifiled (used for
> Dscanner for example)


Faster alternatives to std.xml

2017-07-08 Thread Nordlöw via Digitalmars-d-learn

What's the fastest XML-parser on code.dlang.org?

Are there any benchmarks that show performance improvements 
compared to std.xml?


Re: The Nullity Of strings and Its Meaning

2017-07-08 Thread ag0aep6g via Digitalmars-d-learn

On 07/08/2017 07:16 PM, kdevel wrote:


The assertion in line 6 fails. This failure gave rise to a more general
investigation on strings. After some research I found that one
"cannot implicitly convert expression (s) of type string to bool" as in

[...]

Nonetheless in certain boolean contexts strings convert to bool as here:

1 void main ()
2 {
3import std.stdio;
4string s; // equivalent to s = null
5writeln (s ? true : false);
6s = "";
7writeln (s ? true : false);
8 }


Yeah, that's considered "explicit". Also happens with `if (s)`.


The code prints

false
true

to the console. This lead me to the insight, that in D there are two
distinct kinds of empty strings: Those having a ptr which is null and
the other. It seems that this ptr nullity not only determines whether
the string compares equal to null in an IdentityExpression [1] but also
the result of the above mentioned conversion in the boolean context.


Yup. Though I'd say the distinction is null vs every other array, not 
null vs other empty arrays.


null is one specific array. It happens to be empty, but that doesn't 
really matter. `foo is null` compares with the null array. It doesn't 
check for emptiness. Conversion to bool also compares with null. The 
concept of emptiness is unrelated.


Maybe detecting empty arrays would be more useful. As far as I know, 
there's no killer argument either way. Changing it now would break code, 
of course.


Personally, I wouldn't mind if those conversions to bool just went away. 
It's not obvious what exactly is being checked, and it's not hard to be 
explicit about it with .ptr and/or .length. But as Timon notes, that has 
been attempted, and it broke code. So it was reverted, and that's that.



I wonder if this distinction is meaningful and---if not---why it is
exposed to the application programmer so prominently.


"Prominently"? It only shows up when you convert to bool. You only get 
surprised if you expect that to check for emptiness (or something else 
entirely). And you don't really have a reason to expect that. You can 
easily avoid the issue by being more explicit in your code (`arr.ptr is 
null`, `arr.length == 0`/`arr.empty`).



Then today I found this piece of code

1 void main ()
2 {
3string s = null;
4string t = "";
5assert (s is t);
6 }

which, according to the wording in [1]

   "For static and dynamic arrays, identity is defined as referring to
the same array elements and the same number of elements."

shall succeed but its assertion fails [2]. I anticipate the
implementation compares the ptrs even in the case of zero elements.


The spec isn't very clear there. What does "the same array elements" 
mean for empty arrays? Can two arrays refer to "the same array elements" 
but have different lengths? It seems like "referring to the same array 
elements" is supposed to mean "having the same value in .ptr" without 
mentioning .ptr.


The implementation obviously compares .ptr and .length.


A last example of 'deviant behavior' I found is this:

 1 import std.stdio;
 2 import std.file;
 3 void main ()
 4 {
 5string s = null;
 6try
 7   mkdir (s);
 8catch (Exception e)
 9   e.msg.writeln;
10
11s = "";
12try
13   mkdir (s);
14catch (Exception e)
15   e.msg.writeln;
16 }

Using DMD v2.073.2 the first expression terminates the programm with a
segmentation fault. With 2.074.1 the program prints

: Bad address
: No such file or directory

I find that a bit confusing.


That looks like a bug/oddity in mkdir. null is as valid a string as "". 
It shouldn't give a worse exception message.


But the message for `""` isn't exactly good, either. Of course the 
directory doesn't exist, yet; I'm trying to create it!


Re: Application settings

2017-07-08 Thread Seb via Digitalmars-d-learn

On Saturday, 8 July 2017 at 05:00:45 UTC, bauss wrote:

On Friday, 7 July 2017 at 22:52:22 UTC, FoxyBrown wrote:

On Friday, 7 July 2017 at 20:45:36 UTC, Moritz Maxeiner wrote:

On Friday, 7 July 2017 at 19:40:35 UTC, FoxyBrown wrote:

[...]


"best" always depends on your specific use case. I use json 
files via asdf [1]


[1] https://github.com/tamediadigital/asdf



Seems like quite a heavy package for what I need. I just want 
to write a AA to disk and load it, ultimately.


Then I would go with INI, because you'll ultimately just have 
key-value pairs.


https://code.dlang.org/packages/baussini (Pretty old but should 
still work just fine.)


There is also inifiled: https://github.com/burner/inifiled (used 
for Dscanner for example)


Re: The Nullity Of strings and Its Meaning

2017-07-08 Thread Timon Gehr via Digitalmars-d-learn

On 08.07.2017 19:16, kdevel wrote:


I wonder if this distinction is meaningful


Not nearly as much as it would need to be to justify the current 
behavior. It's mostly a historical accident.



and---if not---why it is
exposed to the application programmer so prominently.


I don't think there is a good reason except backwards-compatibility.
Also see: https://github.com/dlang/dmd/pull/4623
(This is the pull request that restored the bad behaviour after it had 
been fixed.)


The Nullity Of strings and Its Meaning

2017-07-08 Thread kdevel via Digitalmars-d-learn
Yesterday I noticed that std.uri.decodeComponent does not 
'preserve' the

nullity of its argument:

   1 void main ()
   2 {
   3import std.uri;
   4string s = null;
   5assert (s is null);
   6assert (s.decodeComponent);
   7 }

The assertion in line 6 fails. This failure gave rise to a more 
general

investigation on strings. After some research I found that one
"cannot implicitly convert expression (s) of type string to bool" 
as in


   1 void main ()
   2 {
   3string s;
   4bool b = s;
   5 }

Nonetheless in certain boolean contexts strings convert to bool 
as here:


   1 void main ()
   2 {
   3import std.stdio;
   4string s; // equivalent to s = null
   5writeln (s ? true : false);
   6s = "";
   7writeln (s ? true : false);
   8 }

The code prints

   false
   true

to the console. This lead me to the insight, that in D there are 
two
distinct kinds of empty strings: Those having a ptr which is null 
and
the other. It seems that this ptr nullity not only determines 
whether
the string compares equal to null in an IdentityExpression [1] 
but also
the result of the above mentioned conversion in the boolean 
context.


I wonder if this distinction is meaningful and---if not---why it 
is

exposed to the application programmer so prominently.

Then today I found this piece of code

   1 void main ()
   2 {
   3string s = null;
   4string t = "";
   5assert (s is t);
   6 }

which, according to the wording in [1]

  "For static and dynamic arrays, identity is defined as 
referring to

   the same array elements and the same number of elements."

shall succeed but its assertion fails [2]. I anticipate the
implementation compares the ptrs even in the case of zero 
elements.


A last example of 'deviant behavior' I found is this:

1 import std.stdio;
2 import std.file;
3 void main ()
4 {
5string s = null;
6try
7   mkdir (s);
8catch (Exception e)
9   e.msg.writeln;
   10
   11s = "";
   12try
   13   mkdir (s);
   14catch (Exception e)
   15   e.msg.writeln;
   16 }

Using DMD v2.073.2 the first expression terminates the programm 
with a

segmentation fault. With 2.074.1 the program prints

   : Bad address
   : No such file or directory

I find that a bit confusing.

[1] https://dlang.org/spec/expression.html#identity_expressions
[2] https://issues.dlang.org/show_bug.cgi?id=17623


problem overloading functions with complex enum type

2017-07-08 Thread Eric via Digitalmars-d-learn

import std.stdio;

enum A : int { a, b };
enum B : int { a, b };
enum AS : string[2] { a = ["1","2"], b = ["3","4"] };
enum BS : string[2] { a = ["5","6"], b = ["7","8"] };

void func(A a)   { writeln("A");  }
void func(B b)   { writeln("B");  }
void funcs(AS a) { writeln("AS"); }
void funcs(BS b) { writeln("BS"); }

void test()
{
func(A.a); // no compiler error
funcs(AS.a); // compiler error: matches both funcs(AS) and 
funcs(BS)

}

void main(string[] args) { }

In the above code, the function with the simple enum type 
argument can
be overloaded, but the function with the complex enum type 
argument cannot be overloaded.

Is this a bug?

Thx.
Eric


Re: Finding source of typeid use

2017-07-08 Thread Nicholas Wilson via Digitalmars-d-learn

On Saturday, 8 July 2017 at 08:56:17 UTC, Rainer Schuetze wrote:



On 08.07.2017 07:55, Nicholas Wilson wrote:
On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole 
wrote:

On 08/07/2017 2:35 AM, Nicholas Wilson wrote:
On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson 
wrote:

My library is generating a typeid from somewhere.
e.g.
typeid(const(Pointer!(cast(AddrSpace)1u, float)))

[...]


It seems to be coming from the need to hash the type, 
goodness knows why, which explains why I only get the const 
variety.


https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe?


No, the culprit is
https://github.com/dlang/druntime/blob/master/src/object.d#L1128
but IDK why it is being generated in the first place since 
nothing I wrote relies on being able to hash it.


I suspect this is generated while building the hash function 
for your Pointer struct in buildXtoHash in ddmd/clone.d.


Hmm, I found needToHash(StructDeclaration sd) which enumerates 
the fields

If a field is a struct
recurse, makes sense
if the struct has an alias this, which Pointer does, generate 
a typeinfo, with a note to see 
https://issues.dlang.org/show_bug.cgi?id=14948 / dmdPR 5001.




Re: Finding source of typeid use

2017-07-08 Thread Rainer Schuetze via Digitalmars-d-learn



On 08.07.2017 07:55, Nicholas Wilson wrote:

On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote:

On 08/07/2017 2:35 AM, Nicholas Wilson wrote:

On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:

My library is generating a typeid from somewhere.
e.g.
typeid(const(Pointer!(cast(AddrSpace)1u, float)))

[...]


It seems to be coming from the need to hash the type, goodness knows 
why, which explains why I only get the const variety.


https://github.com/dlang/druntime/blob/master/src/object.d#L253 Maybe?


No, the culprit is
https://github.com/dlang/druntime/blob/master/src/object.d#L1128
but IDK why it is being generated in the first place since nothing I 
wrote relies on being able to hash it.


I suspect this is generated while building the hash function for your 
Pointer struct in buildXtoHash in ddmd/clone.d.


Re: Double value is rounded to unexpected value: 2.5 -> 2 instead of 3

2017-07-08 Thread alex_ca via Digitalmars-d-learn

Thanks, that was what was happening.



Re: Finding source of typeid use

2017-07-08 Thread Nicholas Wilson via Digitalmars-d-learn

On Saturday, 8 July 2017 at 05:36:49 UTC, rikki cattermole wrote:

On 08/07/2017 2:35 AM, Nicholas Wilson wrote:

On Friday, 7 July 2017 at 08:49:58 UTC, Nicholas Wilson wrote:

My library is generating a typeid from somewhere.
e.g.
typeid(const(Pointer!(cast(AddrSpace)1u, float)))

[...]


It seems to be coming from the need to hash the type, goodness 
knows why, which explains why I only get the const variety.


https://github.com/dlang/druntime/blob/master/src/object.d#L253 
Maybe?


No, the culprit is
https://github.com/dlang/druntime/blob/master/src/object.d#L1128
but IDK why it is being generated in the first place since 
nothing I wrote relies on being able to hash it.