digitalmars.D - long double in C APIs
- David Nadlinger (24/24) Sep 15 2014 There are currently a few pull requests related to interfacing to
- Walter Bright (10/23) Sep 15 2014 This is due to D currently not allowing implicit conversion to a struct....
- Nicolas Sicard (4/11) Sep 16 2014 You say 'currently'. Is there a plan to allow this, if there's no
- Andrei Alexandrescu (2/15) Sep 16 2014 It's on the table. -- Andrei
- Adam D. Ruppe (6/7) Sep 16 2014 sweet. Implicit casts like that are IMO evil most the time... but
- Kagamin (1/1) Sep 15 2014 http://forum.dlang.org/post/uhrxangvpblsadewhnck@forum.dlang.org ?
- Iain Buclaw via Digitalmars-d (8/24) Sep 16 2014 I would do it if GDC supported MSVC. :o)
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
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
On Monday, 15 September 2014 at 23:20:45 UTC, Walter Bright wrote:On 9/15/2014 3:24 PM, David Nadlinger wrote: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?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.
Sep 16 2014
On 9/16/14, 3:45 AM, Nicolas Sicard wrote:On Monday, 15 September 2014 at 23:20:45 UTC, Walter Bright wrote:It's on the table. -- AndreiOn 9/15/2014 3:24 PM, David Nadlinger wrote: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?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.
Sep 16 2014
On Tuesday, 16 September 2014 at 14:52:13 UTC, Andrei Alexandrescu wrote:It's on the table. -- Andreisweet. 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
http://forum.dlang.org/post/uhrxangvpblsadewhnck forum.dlang.org ?
Sep 15 2014
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