Remove aliases to D floating point types

[ibuclaw]

Same as #5234 but for floats.

[ibuclaw]

Ah, I forgot that @rainers played around with longdouble making some conflict between C++ and D codebase.

[rainers]

Ah, I forgot that @rainers played around with longdouble making some conflict between C++ and D codebase.

Not sure what exactly you are alluding to (maybe #5010?), but I'm fine with reducing the number of different aliases to the same thing.

[ibuclaw]

Not sure what exactly you are alluding to (maybe #5010), but I'm fine with reducing the number of different aliases to the same thing.

ea9f51a#diff-5513f3fc83d340ad7546670375b7aa7fR16 is not the same as https://github.com/D-Programming-Language/dmd/blob/681ebb35f30f76f9810acd9bfdade51ea27e76bb/src/root/longdouble.h#L70 which is a bit problematic, granted that GDC has it's own struct longdouble that needs to be used everywhere instead of real (and preferably double and float).

[ibuclaw]

@rainers - So any suggestions to be done? I know you wouldn't want MSVC broken, and know more of how it binds together for dmd. What I'd like to know is:

• Why is struct longdouble not in longdouble.d?
• Why does it have a different structure compared to C++ code?
• Is this chicanery really needed?

[rainers]

IIRC struct longdouble in port.d was added as a workaround to be able to call strtold_dm and ld_sprint. Therefore name mangling and ABI have to match.

Why is struct longdouble not in longdouble.d?

I was expecting longdouble.d to be ditched, it doesn't really contain useful code, just a relacement for real(x). I suspect that's probably something you'd want to use for gdc, though.

Why does it have a different structure compared to C++ code?

I didn't want to repeat the long definition of the C++ code when D has a working real implementation.
That might fall short if real is not 80-bit wide, though.

Is this chicanery really needed?

We could use extern(C) for strtol_dm and ld_sprint to avoid name mangling issues. This would allow renaming the current struct longdouble to something specfic for this VS workaround.

[ibuclaw]

I was expecting longdouble.d to be ditched, it doesn't really contain useful code, just a relacement for real(x). I suspect that's probably something you'd want to use for gdc, though.

Well, longdouble doesn't have to be the name for it. It just so happened that it provided just the right level of abstraction to use, rather than continuing to maintain #ifdef stubs for differing implementations of real_t. I could go back to using the real_t name, but that would mean ripping it out of globals.d and putting it in it's own module (similar to complex.d)

I didn't want to repeat the long definition of the C++ code when D has a working real implementation.

I do not see D's real as a working solution for my needs, or infact, any compiler's needs if they want to be serious about cross-compilation and portability.

[kinke]

@ibuclaw: Can be closed after #5471 as that removed the aliases too.

[ibuclaw]

Indeed