On Wednesday, 17 May 2017 at 20:25:26 UTC, Stefan Koch wrote:
On Wednesday, 17 May 2017 at 19:26:32 UTC, tsbockman wrote:
On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote:
the special case it supports if cast(uint*)
and cast(ulong*)
What about casting from real* when real.sizeof
On Wednesday, 17 May 2017 at 20:25:26 UTC, Stefan Koch wrote:
On Wednesday, 17 May 2017 at 19:26:32 UTC, tsbockman wrote:
On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote:
the special case it supports if cast(uint*)
and cast(ulong*)
What about casting from real* when real.sizeof
On Wednesday, 17 May 2017 at 19:26:32 UTC, tsbockman wrote:
On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote:
the special case it supports if cast(uint*)
and cast(ulong*)
What about casting from real* when real.sizeof > double.sizeof?
unsupported. The code in ctfeExpr
On Wednesday, 17 May 2017 at 15:30:29 UTC, Stefan Koch wrote:
the special case it supports if cast(uint*)
and cast(ulong*)
What about casting from real* when real.sizeof > double.sizeof?
On 5/17/2017 8:30 AM, Stefan Koch wrote:
On Wednesday, 17 May 2017 at 15:15:04 UTC, Walter Bright wrote:
On 5/16/2017 8:02 PM, tsbockman wrote:
Such code is verbose, hard to read, and, judging by the bugs and missing
specializations I've found, hard to write correctly. It is also not
On Wednesday, 17 May 2017 at 15:15:04 UTC, Walter Bright wrote:
On 5/16/2017 8:02 PM, tsbockman wrote:
Such code is verbose, hard to read, and, judging by the bugs
and missing
specializations I've found, hard to write correctly. It is
also not compatible
with CTFE.
CTFE does support things
On 5/16/2017 8:02 PM, tsbockman wrote:
Such code is verbose, hard to read, and, judging by the bugs and missing
specializations I've found, hard to write correctly. It is also not compatible
with CTFE.
CTFE does support things like:
double d;
int i = *(cast(int*));
as a special case,
On Wednesday, 17 May 2017 at 13:09:45 UTC, Simen Kjærås wrote:
On the topic of format support: the details of ibmExtended
seems to leak a lot - would it be possible to encapsulate that
better? I realize it's a weird format and some leakage may be
unavoidable, but currently it seems basically
On Wednesday, 17 May 2017 at 03:02:02 UTC, tsbockman wrote:
std.math contains a lot of raw pointer arithmetic for accessing
the various bit fields of floating-point values (see
https://en.wikipedia.org/wiki/IEEE_754-1985). Much of this code
has several nearly-identical copies, manually
On Wed, May 17, 2017 at 03:02:02AM +, tsbockman via Digitalmars-d wrote:
> std.math contains a lot of raw pointer arithmetic for accessing the
> various bit fields of floating-point values (see
> https://en.wikipedia.org/wiki/IEEE_754-1985). Much of this code has
> several nearly-identical
std.math contains a lot of raw pointer arithmetic for accessing
the various bit fields of floating-point values (see
https://en.wikipedia.org/wiki/IEEE_754-1985). Much of this code
has several nearly-identical copies, manually specialized for
each supported floating-point format.
Such code
11 matches
Mail list logo
