Re: Mapping float to ulong in CTFE

2019-12-12 Thread Petar via Digitalmars-d-learn

On Thursday, 12 December 2019 at 19:21:22 UTC, berni44 wrote:
Is it possible to get to the bits of a float in CTFE? I tried 
the following, but this doesn't work:


```
import std.stdio;

union FloatBits
{
float floatValue;
ulong ulongValue;
}

ulong test(float f)
{
FloatBits fb;
fb.floatValue = f;
return fb.ulongValue;
}

void main()
{
static assert(test(3.0) == 1077936128);
}
```

test.d(13): Error: reinterpretation through overlapped field 
ulongValue is not allowed in CTFE

test.d(18):called from here: test(3.0F)
test.d(18):while evaluating: static 
assert(test(3.0F) == 1077936128LU)


You can use a C-style pointer reinterpret cast like this:

uint test(float f) { return *cast(uint*) }

Make sure that source and destination types have the same size.

Or more generally:

IntegerOfSize!T bitRepresentation(T)(T f)
{
return *cast(IntegerOfSize!T*)
}

pragma (msg, bitRepresentation(3.0f)); // 1077936128u
pragma (msg, bitRepresentation(3.0));  // 4613937818241073152LU

void main()
{
static assert(bitRepresentation(3.0f) == 1077936128);
}

template IntegerOfSize(T)
{
static if (T.sizeof == 1)
alias IntegerOfSize = ubyte;
else static if (T.sizeof == 2)
alias IntegerOfSize = ushort;
else static if (T.sizeof == 4)
alias IntegerOfSize = uint;
else static if (T.sizeof == 8)
alias IntegerOfSize = ulong;
else
static assert(0);
}


Mapping float to ulong in CTFE

2019-12-12 Thread berni44 via Digitalmars-d-learn
Is it possible to get to the bits of a float in CTFE? I tried the 
following, but this doesn't work:


```
import std.stdio;

union FloatBits
{
float floatValue;
ulong ulongValue;
}

ulong test(float f)
{
FloatBits fb;
fb.floatValue = f;
return fb.ulongValue;
}

void main()
{
static assert(test(3.0) == 1077936128);
}
```

test.d(13): Error: reinterpretation through overlapped field 
ulongValue is not allowed in CTFE

test.d(18):called from here: test(3.0F)
test.d(18):while evaluating: static assert(test(3.0F) 
== 1077936128LU)


Re: needing to change the order of things at module level = compiler bug, right?

2019-12-12 Thread DanielG via Digitalmars-d-learn

On Thursday, 12 December 2019 at 06:23:31 UTC, Basile B. wrote:

Still worth opening an issue.

https://issues.dlang.org/show_bug.cgi?id=20443


Thanks, Basile. I've added additional information from the github 
thread where the sumtype author helpfully looked into the problem.