www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - long double in C APIs

reply "David Nadlinger" <code klickverbot.at> writes:
There are currently a few pull requests related to interfacing to 
C's long double type on Win64, most of which have been already 
merged:
  - https://github.com/D-Programming-Language/dmd/pull/3981
  - https://github.com/D-Programming-Language/druntime/pull/958
  - https://github.com/D-Programming-Language/dmd/pull/3990

At first glance, this solution does not seem to be very appealing 
to me:

  1. We need to teach everybody to not use 'real' when declaring C 
APIs, even though it's currently all over the place.

  2. It effectively forces everybody to make all conversions to 
long double explicit in their code, at least if it they want to 
be cross-platform compatible. As the conversion will still be 
implicit on all platforms other than Win64 (and potentially some 
GDC/LDC targets), it seems like this could turn into another 
size_t-style portability trap.

I guess this has already been discussed more extensively, though. 
I even seem to remember talking about making real equivalent to 
the 64 bit long double type on MSVC targets (which IIRC GDC is 
going to do anyway). As I've been more or less out of the loop 
for a while, could somebody please point me to the relevant 
threads/issues/DIPs/…?

Cheers,
David
Sep 15 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/15/2014 3:24 PM, David Nadlinger wrote:

   1. We need to teach everybody to not use 'real' when declaring C APIs, even
 though it's currently all over the place.


They should use c_long_double when interfacing with C and C++.



   2. It effectively forces everybody to make all conversions to long double
 explicit in their code,


This is due to D currently not allowing implicit conversion to a struct. It's a 
general issue, and should be dealt with as a general issue, as it comes up 
whenever a wrapped type is used.



 at least if it they want to be cross-platform
 compatible. As the conversion will still be implicit on all platforms other
than
 Win64 (and potentially some GDC/LDC targets), it seems like this could turn
into
 another size_t-style portability trap.


I wouldn't call it a "trap", just a minor issue that the compiler will complain 
about.



 I guess this has already been discussed more extensively, though. I even seem
to
 remember talking about making real equivalent to the 64 bit long double type on
 MSVC targets (which IIRC GDC is going to do anyway). As I've been more or less
 out of the loop for a while, could somebody please point me to the relevant
 threads/issues/DIPs/…?


Even if we did that, it doesn't solve the issue of C++ name mangling for types 
that D doesn't have, such as 'long' and 'unsigned long'. Those will still need 
to be wrapped types.
Sep 15 2014
parent reply "Nicolas Sicard" <dransic gmail.com> writes:
On Monday, 15 September 2014 at 23:20:45 UTC, Walter Bright wrote:

 On 9/15/2014 3:24 PM, David Nadlinger wrote:

  2. It effectively forces everybody to make all conversions to 
 long double
 explicit in their code,


 This is due to D currently not allowing implicit conversion to 
 a struct. It's a general issue, and should be dealt with as a 
 general issue, as it comes up whenever a wrapped type is used.


You say 'currently'. Is there a plan to allow this, if there's no
ambiguity and if the wrapping struct defines some kind of
opImplicitCast?
Sep 16 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/16/14, 3:45 AM, Nicolas Sicard wrote:

 On Monday, 15 September 2014 at 23:20:45 UTC, Walter Bright wrote:

 On 9/15/2014 3:24 PM, David Nadlinger wrote:

  2. It effectively forces everybody to make all conversions to long
 double
 explicit in their code,


 This is due to D currently not allowing implicit conversion to a
 struct. It's a general issue, and should be dealt with as a general
 issue, as it comes up whenever a wrapped type is used.


 You say 'currently'. Is there a plan to allow this, if there's no
 ambiguity and if the wrapping struct defines some kind of
 opImplicitCast?


It's on the table. -- Andrei
Sep 16 2014
parent "Adam D. Ruppe" <destructionator gmail.com> writes:
On Tuesday, 16 September 2014 at 14:52:13 UTC, Andrei 
Alexandrescu wrote:

 It's on the table. -- Andrei


sweet. Implicit casts like that are IMO evil most the time... but 
when doing transparent wrappers there's times when they are 
appropriate and I sometimes want them. (Along with multiple or 
templated alias this, they tackle different problems.)
Sep 16 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
http://forum.dlang.org/post/uhrxangvpblsadewhnck forum.dlang.org ?
Sep 15 2014
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 15 September 2014 23:24, David Nadlinger via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 There are currently a few pull requests related to interfacing to C's long
 double type on Win64, most of which have been already merged:
  - https://github.com/D-Programming-Language/dmd/pull/3981
  - https://github.com/D-Programming-Language/druntime/pull/958
  - https://github.com/D-Programming-Language/dmd/pull/3990

 At first glance, this solution does not seem to be very appealing to me:

  1. We need to teach everybody to not use 'real' when declaring C APIs, even
 though it's currently all over the place.

  2. It effectively forces everybody to make all conversions to long double
 explicit in their code, at least if it they want to be cross-platform
 compatible. As the conversion will still be implicit on all platforms other
 than Win64 (and potentially some GDC/LDC targets), it seems like this could
 turn into another size_t-style portability trap.

 I guess this has already been discussed more extensively, though. I even
 seem to remember talking about making real equivalent to the 64 bit long
 double type on MSVC targets (which IIRC GDC is going to do anyway).


I would do it if GDC supported MSVC.  :o)

Real has /always/ been the equivalent of long double on all targets in
GDC's implementation.  The GCC compiler backend doesn't really keep
information about the largest float format supported by the CPU,
regardless of whether or not the size of long double is smaller.

Iain.
Sep 16 2014