Jump to page: 1 24  
Page
Thread overview
Why is it that no one writes with portability in mind in druntime?
Nov 24, 2013
Iain Buclaw
Nov 24, 2013
Shammah Chancellor
Nov 24, 2013
Johannes Pfau
Nov 24, 2013
Andrej Mitrovic
Nov 24, 2013
Shammah Chancellor
Nov 24, 2013
Walter Bright
Nov 24, 2013
Jonathan M Davis
Nov 24, 2013
Jonathan M Davis
Nov 24, 2013
ponce
Nov 25, 2013
Jonathan M Davis
Nov 25, 2013
Craig Dillabaugh
Nov 25, 2013
Jonathan M Davis
Nov 25, 2013
Iain Buclaw
Nov 25, 2013
Iain Buclaw
Nov 25, 2013
Jonathan M Davis
Nov 25, 2013
Johannes Pfau
Nov 25, 2013
Walter Bright
Nov 25, 2013
Iain Buclaw
Nov 25, 2013
Jonathan M Davis
Nov 25, 2013
Brad Roberts
Nov 25, 2013
qznc
Nov 25, 2013
Jacob Carlborg
Nov 25, 2013
nazriel
Nov 25, 2013
Jonathan M Davis
Nov 25, 2013
froglegs
Nov 25, 2013
Gary Willoughby
Nov 25, 2013
Jonathan M Davis
Nov 26, 2013
froglegs
Nov 25, 2013
IgorStepanov
Nov 25, 2013
Iain Buclaw
Nov 25, 2013
IgorStepanov
Nov 26, 2013
Iain Buclaw
November 24, 2013
https://github.com/D-Programming-Language/druntime/pull/663
November 24, 2013
On 2013-11-24 11:38:25 +0000, Iain Buclaw said:

> https://github.com/D-Programming-Language/druntime/pull/663

A link to pages of a pull extension for CTFE hashes.   Care to clarify?

November 24, 2013
Am Sun, 24 Nov 2013 10:34:36 -0500
schrieb Shammah Chancellor <anonymous@coward.com>:

> On 2013-11-24 11:38:25 +0000, Iain Buclaw said:
> 
> > https://github.com/D-Programming-Language/druntime/pull/663
> 
> A link to pages of a pull extension for CTFE hashes.   Care to clarify?
> 

A guess: Everything using floating point is probably assuming real is 80 bit. This and floating point unit tests always show up as the main problems when porting druntime / phobos.

We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems...

https://github.com/D-Programming-Language/druntime/pull/663/files#diff-d07f1a3835b1d391d103490da285999dR183
November 24, 2013
On 11/24/13, Johannes Pfau <nospam@example.com> wrote:
> We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems...

It seems any time a language defines something as implementation-specific or platform-specific it ends up giving everyone headaches. I don't know why D chose to use reals like that, after enforcing the sizes of long/int/etc. types.
November 24, 2013
On 2013-11-24 17:47:49 +0000, Andrej Mitrovic said:

> On 11/24/13, Johannes Pfau <nospam@example.com> wrote:
>> We have one type in D which has a different size depending on platform
>> and it's the number one source for platform-specific problems...
> 
> It seems any time a language defines something as
> implementation-specific or platform-specific it ends up giving
> everyone headaches. I don't know why D chose to use reals like that,
> after enforcing the sizes of long/int/etc. types.

Having 80-bit reals on platforms that support them are helpful for numerical simulations.  There use to be an article about this decision. However, phobos should never use real for this reason.  It should only be used by application developers.   Maybe a compiler flag to error when compiling code that includes real to make sure portable libraries don't use it?

-Shammah

November 24, 2013
On 11/24/2013 9:47 AM, Andrej Mitrovic wrote:
> I don't know why D chose to use reals like that,

Because more precision is better.

November 24, 2013
On Sunday, November 24, 2013 18:47:49 Andrej Mitrovic wrote:
> On 11/24/13, Johannes Pfau <nospam@example.com> wrote:
> > We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems...
> 
> It seems any time a language defines something as implementation-specific or platform-specific it ends up giving everyone headaches. I don't know why D chose to use reals like that, after enforcing the sizes of long/int/etc. types.

I'd expect it's because D is a systems language and tries to give you full access to the hardware when you need it, and high-precision floating point types were considered useful enough that they shouldn't require inline assembly to work.

However, in most cases, I think that what it means is that if you use reals where you care at all about the bit layout, you're just not going to be able to write platform-independent code (e.g. std.bitmanip punts or reals for swapping endianness).

- Jonathan M Davis
November 24, 2013
On Sunday, November 24, 2013 17:15:25 Johannes Pfau wrote:
> We have one type in D which has a different size depending on platform and it's the number one source for platform-specific problems...

No. We have several types which vary in size. In addition to real, there's also size_t (which should be being used in almost all D programs, whereas real is used in far fewer), and there's also ptrdiff_t, which is effectively an unsigned size_t. And of course, all of the pointer types vary in size, as do the c_* types from druntime when you have to interact with C (though those aren't part of the language - or even just treated as part of the language as size_t and ptrdiff_t are, since they're defined in object_.d). So, even if almost all of D's numeric types don't vary in size, there are some that do.

But it is true that a large portion of our platform-specific problems stem from types that vary in size.

- Jonathan M Davis
November 24, 2013
On Sunday, 24 November 2013 at 17:50:20 UTC, Shammah Chancellor wrote:
> Having 80-bit reals on platforms that support them are helpful for numerical simulations.  There use to be an article about this decision. However, phobos should never use real for this reason.

What, so mathematical functions shouldn't use the highest-precision floating point?
November 24, 2013
On Sunday, 24 November 2013 at 22:38:15 UTC, Jonathan M Davis wrote:
> No. We have several types which vary in size. In addition to real, there's
> also size_t (which should be being used in almost all D programs, whereas real
> there's also ptrdiff_t, which is effectively an unsigned size_t.

Just to correct things, size_t is unsigned, ptrdiff_t is the signed one.
« First   ‹ Prev
1 2 3 4