digitalmars.D - C++ interop - what to do about long and unsigned long?
- Walter Bright (10/10) Sep 10 2014 C++'s long and unsigned long can be accessed with c_long and c_ulong.
- bearophile (8/9) Sep 10 2014 This looks like the simpler and cleaner solution. What are the
- Walter Bright (2/5) Sep 10 2014 Not inter-operating with C++ is turning out to be a huge barrier for D a...
- Andrei Alexandrescu (4/17) Sep 10 2014 C++ interoperability: 1,000,000 merit points
- bachmeier (9/28) Sep 10 2014 Not to go too far off topic, but C++ interoperability is at 0
- Walter Bright (3/6) Sep 10 2014 If that were true, then D interoperability with C would be impossible as...
- bachmeier (10/18) Sep 11 2014 The difference is that the only ones wanting to interoperate with
- Andrei Alexandrescu (4/11) Sep 10 2014 Ideally it would.
- Paolo Invernizzi (7/15) Sep 10 2014 It's scaring that all the efforts are now focused on that.
- Andrei Alexandrescu (5/18) Sep 11 2014 I don't know what OpenCV is but calls to non-virtual C++ methods work in...
- Daniel Murphy (3/5) Sep 11 2014 And in 2.066 IIRC.
- Paolo Invernizzi (13/18) Sep 11 2014 Andrei: OpenCV is probably the most used open-source library for
- Daniel Murphy (15/20) Sep 12 2014 Yeah, the documentation is a little out of date.
- bachmeier (6/15) Sep 11 2014 In terms of getting C++ developers to use D, this thread that
- Andrei Alexandrescu (3/18) Sep 11 2014 Andrei
- Sean Kelly (10/15) Sep 11 2014 Is C++ interop really that important or is it another one of
- Andrei Alexandrescu (7/23) Sep 11 2014 Blocker. No two ways about it.
- Andrej Mitrovic via Digitalmars-d (19/22) Sep 12 2014 I've had moderate success creating a codegenerator for automatically
- Walter Bright (11/17) Sep 11 2014 C++ was adopted because one could gradually ease into it from C. This wi...
- Manu via Digitalmars-d (6/27) Sep 11 2014 So, can we talk about virtual by default again?
- Daniel Murphy (4/8) Sep 12 2014 It's not required for C++ interop, it's just a huge pain in the ass sinc...
- Manu via Digitalmars-d (6/15) Sep 12 2014 Yeah, but that's true regardless of C++ interop. It's so easy to make
- Timon Gehr (2/3) Sep 12 2014 How do you declare virtual extern(C++) class methods then?
- Manu via Digitalmars-d (3/7) Sep 12 2014 with 'virtual' (which Andrei had removed)
- Jacob Carlborg (5/9) Sep 13 2014 We have showed how you can workaround that with a @virtual UDA. Forcing
- bearophile (6/8) Sep 13 2014 Often the less special cases you have, the less bugs you create.
- Andrei Alexandrescu (5/10) Sep 13 2014 Yah, the C++ interop philosophy is "D language rules, C++
- Walter Bright (3/7) Sep 13 2014 I guarantee that few will remember which way the final-by-default goes w...
- Manu via Digitalmars-d (7/14) Sep 13 2014 I agree. It should be the default in all cases, as unanimously agreed by
- Andrei Alexandrescu (2/4) Sep 13 2014 There was no unanimity. -- Andrei
- Jakob Ovrum (5/10) Sep 13 2014 +1. I like the status quo except I regret that there's no nice
- David Nadlinger (4/9) Sep 14 2014 Yep, there most definitely wasn't.
- monarch_dodra (5/15) Sep 14 2014 Correct me if I'm wrong, but I remember that there was unanimity
- bachmeier (18/36) Sep 12 2014 For numerical computing, C++ interop would be huge. Scientists,
- Adam D. Ruppe (5/9) Sep 10 2014 That would be nice, but C++ would be nicer. Not only does that
- Adam D. Ruppe (4/6) Sep 10 2014 That's what I'd do. Should have best compatibility too with other
- Iain Buclaw via Digitalmars-d (7/12) Sep 10 2014 This problem is not lost on me (and hopefully Daniel).
- Daniel Murphy (7/17) Sep 11 2014 *sigh*
- monarch_dodra (10/20) Sep 11 2014 Having actual new types makes me a bit nervous in regards to how
- Gary Willoughby (5/17) Sep 11 2014 How would these choices affect/handle the dynamic nature of the
- Daniel N (5/8) Sep 13 2014 How about?
C++'s long and unsigned long can be accessed with c_long and c_ulong. Unfortunately, these are aliases and mangle to their underlying types. Meaning that there is no way to interface to a C++ function declared as: void foo(unsigned long); So, what to do about this? 1. elevate c_long and c_ulong into full fledged types. 2. create full fledged types __c_long and __c_ulong, and alias c_long and c_ulong to them. 3. some sort of attribute? The same issue exists for C++'s 'long double'.
Sep 10 2014
Walter Bright:1. elevate c_long and c_ulong into full fledged types.This looks like the simpler and cleaner solution. What are the disadvantages of this solution? (In my opinion the C++ interop topic is way less important/urgent than designing and implementing the tracking/scoping of memory areas in D. So I am seeing a priority problem here). Bye, bearophile
Sep 10 2014
On 9/10/2014 2:08 PM, bearophile wrote:(In my opinion the C++ interop topic is way less important/urgent than designing and implementing the tracking/scoping of memory areas in D. So I am seeing a priority problem here).Not inter-operating with C++ is turning out to be a huge barrier for D adoption.
Sep 10 2014
"bearophile" <bearophileHUGS lycos.com> wrote:Walter Bright:C++ interoperability: 1,000,000 merit points Anything related to the GC: 999,999 merit points All else: two digits merit points1. elevate c_long and c_ulong into full fledged types.This looks like the simpler and cleaner solution. What are the disadvantages of this solution? (In my opinion the C++ interop topic is way less important/urgent than designing and implementing the tracking/scoping of memory areas in D. So I am seeing a priority problem here). Bye, bearophile
Sep 10 2014
On Wednesday, 10 September 2014 at 21:32:22 UTC, Andrei Alexandrescu wrote:"bearophile" <bearophileHUGS lycos.com> wrote:Not to go too far off topic, but C++ interoperability is at 0 merit points until you've got a GC-less standard library, finished shared library support on all platforms, and tools that rival those available for C++. Clearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Walter Bright:C++ interoperability: 1,000,000 merit points Anything related to the GC: 999,999 merit points All else: two digits merit points1. elevate c_long and c_ulong into full fledged types.This looks like the simpler and cleaner solution. What are the disadvantages of this solution? (In my opinion the C++ interop topic is way less important/urgent than designing and implementing the tracking/scoping of memory areas in D. So I am seeing a priority problem here). Bye, bearophile
Sep 10 2014
On 9/10/2014 4:16 PM, bachmeier wrote:Not to go too far off topic, but C++ interoperability is at 0 merit points until you've got a GC-less standard library, finished shared library support on all platforms, and tools that rival those available for C++.If that were true, then D interoperability with C would be impossible as well. But it is possible and works well.
Sep 10 2014
On Wednesday, 10 September 2014 at 23:18:18 UTC, Walter Bright wrote:On 9/10/2014 4:16 PM, bachmeier wrote:The difference is that the only ones wanting to interoperate with C++ are those already using C++. And something that always comes up in comments by C++ developers is that they need the standard library but don't want GC. C++ interoperability is exciting, and it can be D's killer application, but it's a long-term project. Releasing a compiler without regressions seems to me to be at least as important in the short-term.Not to go too far off topic, but C++ interoperability is at 0 merit points until you've got a GC-less standard library, finished shared library support on all platforms, and tools that rival those available for C++.If that were true, then D interoperability with C would be impossible as well. But it is possible and works well.
Sep 11 2014
On 9/10/14, 4:16 PM, bachmeier wrote:Not to go too far off topic, but C++ interoperability is at 0 merit points until you've got a GC-less standard library, finished shared library support on all platforms, and tools that rival those available for C++.No. C++ interop and GC are related, but only loosely.Clearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Ideally it would. Andrei
Sep 10 2014
On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:On 9/10/14, 4:16 PM, bachmeier wrote:It's scaring that all the efforts are now focused on that. I'm curious to understand the plan for interop with not-virtual class methods: OpenCV for example. -- /PaoloClearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Ideally it would. Andrei
Sep 10 2014
On 9/10/14, 10:35 PM, Paolo Invernizzi wrote:On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:Well they aren't :o).On 9/10/14, 4:16 PM, bachmeier wrote:It's scaring that all the efforts are now focused on that.Clearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Ideally it would. AndreiI'm curious to understand the plan for interop with not-virtual class methods: OpenCV for example.I don't know what OpenCV is but calls to non-virtual C++ methods work in master. Andrei
Sep 11 2014
"Andrei Alexandrescu" wrote in message news:lurk42$1228$1 digitalmars.com...I don't know what OpenCV is but calls to non-virtual C++ methods work in master.And in 2.066 IIRC.
Sep 11 2014
On Thursday, 11 September 2014 at 07:52:01 UTC, Daniel Murphy wrote:"Andrei Alexandrescu" wrote in message news:lurk42$1228$1 digitalmars.com...Andrei: OpenCV is probably the most used open-source library for computer vision, and it's switching from a C API to a C++ API, so that's an interesting topic for my company... Daniel: Good to know! Where can I find some documentation about it? Actually the online documentation of 2.066 states: "Note: non-virtual functions, and static member functions, cannot be accessed." Can you point to the pull request? -- /PaoloI don't know what OpenCV is but calls to non-virtual C++ methods work in master.And in 2.066 IIRC.
Sep 11 2014
"Paolo Invernizzi" wrote in message news:mlqsirmipwgfovetbaai forum.dlang.org...Daniel: Good to know! Where can I find some documentation about it? Actually the online documentation of 2.066 states: "Note: non-virtual functions, and static member functions, cannot be accessed." Can you point to the pull request?Yeah, the documentation is a little out of date. You can find some working examples in the test suite: https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/cppa.d https://github.com/D-Programming-Language/dmd/blob/master/test/runnable/extra-files/cppb.cpp Some pulls are: https://github.com/D-Programming-Language/dmd/pull/2053 https://github.com/D-Programming-Language/dmd/pull/2037 https://github.com/D-Programming-Language/dmd/pull/1990 https://github.com/D-Programming-Language/dmd/pull/2193 https://github.com/D-Programming-Language/dmd/pull/2816 But basically, most functions (except special member functions) work well across the language boundary. Mangling, vtable layout, and alignment are all matched.
Sep 12 2014
On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:On 9/10/14, 4:16 PM, bachmeier wrote:In terms of getting C++ developers to use D, this thread that just appeared is a perfect example of why C++ interop won't help until you can use the standard library without the GC. http://forum.dlang.org/post/impaxeaowtuaxtgtyojg forum.dlang.orgNot to go too far off topic, but C++ interoperability is at 0 merit points until you've got a GC-less standard library, finished shared library support on all platforms, and tools that rival those available for C++.No. C++ interop and GC are related, but only loosely.
Sep 11 2014
On 9/11/14, 5:47 AM, bachmeier wrote:On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:Of course. That's why I wrote:On 9/10/14, 4:16 PM, bachmeier wrote:In terms of getting C++ developers to use D, this thread that just appeared is a perfect example of why C++ interop won't help until you can use the standard library without the GC. http://forum.dlang.org/post/impaxeaowtuaxtgtyojg forum.dlang.orgNot to go too far off topic, but C++ interoperability is at 0 merit points until you've got a GC-less standard library, finished shared library support on all platforms, and tools that rival those available for C++.No. C++ interop and GC are related, but only loosely.C++ interoperability: 1,000,000 merit points Anything related to the GC: 999,999 merit points All else: two digits merit pointsAndrei
Sep 11 2014
On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:On 9/10/14, 4:16 PM, bachmeier wrote:Is C++ interop really that important or is it another one of those "if D had this, *then* I would use it!" dismissals. C interop is clearly crucial. Operating system interfaces are written in C, and not being able to call C functions is hugely limiting. But C++? I honestly can't envision a situation where I would actually care about C++ interop. Is this truly a blocker for some people? Like an actual, honest blocker and not just a false flag?Clearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Ideally it would.
Sep 11 2014
On 9/11/14, 8:39 AM, Sean Kelly wrote:On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:It is that important.On 9/10/14, 4:16 PM, bachmeier wrote:Is C++ interop really that important or is it another one of those "if D had this, *then* I would use it!" dismissals.Clearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Ideally it would.C interop is clearly crucial. Operating system interfaces are written in C, and not being able to call C functions is hugely limiting. But C++? I honestly can't envision a situation where I would actually care about C++ interop. Is this truly a blocker for some people? Like an actual, honest blocker and not just a false flag?Blocker. No two ways about it. We've done some stuff at FB going with the "ah we have C interface so we'll just write C wrappers around the C++ code we'll use" and it didn't take long to figure that won't scale, like, at all. Andrei
Sep 11 2014
On 9/11/14, Andrei Alexandrescu via Digitalmars-d <digitalmars-d puremagic.com> wrote:We've done some stuff at FB going with the "ah we have C interface so we'll just write C wrappers around the C++ code we'll use" and it didn't take long to figure that won't scale, like, at all.I've had moderate success creating a codegenerator for automatically writing C interface code to C++ and a D API on top. But, it's extremely complicated and would likely take me years to finish, there are so many edge cases. The generated code really lacks in performance due to all the jumping around between forwarding functions and whatnot (even though I've generated code which was faster than SWIG code for cross-language virtual calls). So I welcome any direct C++ interoperability support. Btw, one thing I want to see supported is cross-language polymorphism, meaning if you have this C++ function: // in foo.cpp Base foo() { return new Derived(); }; Then the following D code should work: assert( cast(Derived)foo() ); Afaik SWIG had no support for this, my codegenerator did, but it essentially had to go through a list of classes and attempt a cast for each one before returning the D object of the right dynamic type.
Sep 12 2014
On 9/11/2014 8:39 AM, Sean Kelly wrote:Is C++ interop really that important or is it another one of those "if D had this, *then* I would use it!" dismissals. C interop is clearly crucial. Operating system interfaces are written in C, and not being able to call C functions is hugely limiting. But C++? I honestly can't envision a situation where I would actually care about C++ interop. Is this truly a blocker for some people? Like an actual, honest blocker and not just a false flag?C++ was adopted because one could gradually ease into it from C. This will never be true for C++ => D, but many people have reported it was nearly impossible to transition to D for them because they had engines, libraries, whatever, in C++ and it was just not reasonable to wrap them with a C interface. So they just stayed with C++. Considering that some of them spent some significant effort trying to do it suggests it is an honest blocker (and I've seen plenty of false flags). Interestingly, D's "competitor" languages do not offer any migration path from C++, and some are even poor at hooking up with C code. Having a better story with D offers us potentially a huge advantage.
Sep 11 2014
So, can we talk about virtual by default again? Daniel Murphy was behind it wrt c++ compatibility. It's still driving me insane. All things I said will happen do happen, constantly. On 12 Sep 2014 09:25, "Walter Bright via Digitalmars-d" < digitalmars-d puremagic.com> wrote:On 9/11/2014 8:39 AM, Sean Kelly wrote:Is C++ interop really that important or is it another one of those "if D had this, *then* I would use it!" dismissals. C interop is clearly crucial. Operating system interfaces are written in C, and not being able to call C functions is hugely limiting. But C++? I honestly can't envision a situation where I would actually care about C++ interop. Is this truly a blocker for some people? Like an actual, honest blocker and not just a false flag?C++ was adopted because one could gradually ease into it from C. This will never be true for C++ => D, but many people have reported it was nearly impossible to transition to D for them because they had engines, libraries, whatever, in C++ and it was just not reasonable to wrap them with a C interface. So they just stayed with C++. Considering that some of them spent some significant effort trying to do it suggests it is an honest blocker (and I've seen plenty of false flags). Interestingly, D's "competitor" languages do not offer any migration path from C++, and some are even poor at hooking up with C code. Having a better story with D offers us potentially a huge advantage.
Sep 11 2014
"Manu via Digitalmars-d" <digitalmars-d puremagic.com> wrote in message news:mailman.789.1410494842.5783.digitalmars-d puremagic.com...So, can we talk about virtual by default again? Daniel Murphy was behind it wrt c++ compatibility. It's still driving me insane. All things I said will happen do happen, constantly.It's not required for C++ interop, it's just a huge pain in the ass since you have to mark nearly every function as final.
Sep 12 2014
On 12 September 2014 17:44, Daniel Murphy via Digitalmars-d < digitalmars-d puremagic.com> wrote:"Manu via Digitalmars-d" <digitalmars-d puremagic.com> wrote in message news:mailman.789.1410494842.5783.digitalmars-d puremagic.com... So, can we talk about virtual by default again?Yeah, but that's true regardless of C++ interop. It's so easy to make mistakes, and so hard to find them when you do. virtual-by-default is responsible for most of the silent errors in my code by far. Surely, at very least, an extern(C++) class should be final-by-default?Daniel Murphy was behind it wrt c++ compatibility. It's still driving me insane. All things I said will happen do happen, constantly.It's not required for C++ interop, it's just a huge pain in the ass since you have to mark nearly every function as final.
Sep 12 2014
On 09/13/2014 03:36 AM, Manu via Digitalmars-d wrote:Surely, at very least, an extern(C++) class should be final-by-default?How do you declare virtual extern(C++) class methods then?
Sep 12 2014
On 13 September 2014 11:43, Timon Gehr via Digitalmars-d < digitalmars-d puremagic.com> wrote:On 09/13/2014 03:36 AM, Manu via Digitalmars-d wrote:with 'virtual' (which Andrei had removed)Surely, at very least, an extern(C++) class should be final-by-default?How do you declare virtual extern(C++) class methods then?
Sep 12 2014
On 2014-09-13 03:36, Manu via Digitalmars-d wrote:Yeah, but that's true regardless of C++ interop. It's so easy to make mistakes, and so hard to find them when you do. virtual-by-default is responsible for most of the silent errors in my code by far. Surely, at very least, an extern(C++) class should be final-by-default?We have showed how you can workaround that with a virtual UDA. Forcing all methods to be either marked "final" or " virtual". -- /Jacob Carlborg
Sep 13 2014
Manu:Surely, at very least, an extern(C++) class should be final-by-default?Often the less special cases you have, the less bugs you create. So I suggest final to be handled in the same way in both regular and extern(C++) classes. Bye, bearophile
Sep 13 2014
On 9/13/14, 3:45 AM, bearophile wrote:Manu:Yah, the C++ interop philosophy is "D language rules, C++ implementations". I.e. no C++ overloading, visibility rules, name lookup, overriding vs. hiding, etc. etc. AndreiSurely, at very least, an extern(C++) class should be final-by-default?Often the less special cases you have, the less bugs you create. So I suggest final to be handled in the same way in both regular and extern(C++) classes.
Sep 13 2014
On 9/13/2014 3:45 AM, bearophile wrote:Manu:I guarantee that few will remember which way the final-by-default goes with which mode.Surely, at very least, an extern(C++) class should be final-by-default?Often the less special cases you have, the less bugs you create. So I suggest final to be handled in the same way in both regular and extern(C++) classes.
Sep 13 2014
I agree. It should be the default in all cases, as unanimously agreed by this community, and overruled by Andrei post-implementation. On 14 Sep 2014 05:50, "Walter Bright via Digitalmars-d" < digitalmars-d puremagic.com> wrote: On 9/13/2014 3:45 AM, bearophile wrote:Manu: Surely, at very least, an extern(C++) class should be final-by-default?I guarantee that few will remember which way the final-by-default goes with which mode.Often the less special cases you have, the less bugs you create. So I suggest final to be handled in the same way in both regular and extern(C++) classes.
Sep 13 2014
On 9/13/14, 8:43 PM, Manu via Digitalmars-d wrote:I agree. It should be the default in all cases, as unanimously agreed by this community, and overruled by Andrei post-implementation.There was no unanimity. -- Andrei
Sep 13 2014
On Sunday, 14 September 2014 at 04:26:30 UTC, Andrei Alexandrescu wrote:On 9/13/14, 8:43 PM, Manu via Digitalmars-d wrote:+1. I like the status quo except I regret that there's no nice way to express non-final as I'm a big fan of using the `attribute:` syntax.I agree. It should be the default in all cases, as unanimously agreed by this community, and overruled by Andrei post-implementation.There was no unanimity. -- Andrei
Sep 13 2014
On Sunday, 14 September 2014 at 04:26:30 UTC, Andrei Alexandrescu wrote:On 9/13/14, 8:43 PM, Manu via Digitalmars-d wrote:Yep, there most definitely wasn't. DavidI agree. It should be the default in all cases, as unanimously agreed by this community, and overruled by Andrei post-implementation.There was no unanimity. -- Andrei
Sep 14 2014
On Sunday, 14 September 2014 at 11:52:29 UTC, David Nadlinger wrote:On Sunday, 14 September 2014 at 04:26:30 UTC, Andrei Alexandrescu wrote:Correct me if I'm wrong, but I remember that there was unanimity that it *was* a better design decision. Changing the existing behavior, however, was what we were not unanimous about.On 9/13/14, 8:43 PM, Manu via Digitalmars-d wrote:Yep, there most definitely wasn't. DavidI agree. It should be the default in all cases, as unanimously agreed by this community, and overruled by Andrei post-implementation.There was no unanimity. -- Andrei
Sep 14 2014
On Thursday, 11 September 2014 at 15:39:08 UTC, Sean Kelly wrote:On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:For numerical computing, C++ interop would be huge. Scientists, statisticians, and economists don't want to write or even learn C++, but currently there is little choice. Here are a few examples off the top of my head: - Rcpp is the most popular dependency in R. It allows for easy embedding of C++ code in R. - RInside makes it easy to embed R in a C++ program. - Octave is written in C++ and extensions are easiest to write in C++. - Armadillo is a linear algebra library. - Eigen does linear algebra, non-linear optimization, and estimation. - CERN's ROOT is written in C++. No matter the claims about how much of an improvement C++11/C++14 are, the learning curve with D is much smaller. If you want to make a newbie hate their career choice, tell them "you can do that using Boost" or "that uses template metaprogramming".On 9/10/14, 4:16 PM, bachmeier wrote:Is C++ interop really that important or is it another one of those "if D had this, *then* I would use it!" dismissals. C interop is clearly crucial. Operating system interfaces are written in C, and not being able to call C functions is hugely limiting. But C++? I honestly can't envision a situation where I would actually care about C++ interop. Is this truly a blocker for some people? Like an actual, honest blocker and not just a false flag?Clearly Walter and everyone should work on whatever they think is important. I hope your statement doesn't imply that all development effort is going to be put into C++ compatibility.Ideally it would.
Sep 12 2014
On Wednesday, 10 September 2014 at 21:08:30 UTC, bearophile wrote:(In my opinion the C++ interop topic is way less important/urgent than designing and implementing the tracking/scoping of memory areas in D. So I am seeing a priority problem here).That would be nice, but C++ would be nicer. Not only does that really help in bringing D into existing code, it also makes things like using C++ libraries a lot easier. I'd enjoy access to Qt for example without needing 15 MB of wrapper code.
Sep 10 2014
On Wednesday, 10 September 2014 at 20:41:45 UTC, Walter Bright wrote:2. create full fledged types __c_long and __c_ulong, and alias c_long and c_ulong to them.That's what I'd do. Should have best compatibility too with other definitions of c_long in third party libs.
Sep 10 2014
On 10 September 2014 21:40, Walter Bright via Digitalmars-d <digitalmars-d puremagic.com> wrote:C++'s long and unsigned long can be accessed with c_long and c_ulong. Unfortunately, these are aliases and mangle to their underlying types.This problem is not lost on me (and hopefully Daniel).2. create full fledged types __c_long and __c_ulong, and alias c_long and c_ulong to them.This is not unreasonable. And would allow dmd to fix their whole C++ long/ulong mangling mess.The same issue exists for C++'s 'long double'.I don't think so, as there is 'real' for that. Iain.
Sep 10 2014
"Iain Buclaw via Digitalmars-d" wrote in message news:mailman.726.1410416827.5783.digitalmars-d puremagic.com...This problem is not lost on me (and hopefully Daniel).*sigh*Yeah this seems like the only reasonable one. Although I think they should only be allowed as parameters in extern(C++) functions, where they set up the custom mangling and then decay to int/uint/long/ulong as appropriate.2. create full fledged types __c_long and __c_ulong, and alias c_long and c_ulong to them.This is not unreasonable. And would allow dmd to fix their whole C++ long/ulong mangling mess.real doesn't always match long double in dmd.The same issue exists for C++'s 'long double'.I don't think so, as there is 'real' for that.
Sep 11 2014
On Wednesday, 10 September 2014 at 20:41:45 UTC, Walter Bright wrote:C++'s long and unsigned long can be accessed with c_long and c_ulong. Unfortunately, these are aliases and mangle to their underlying types. Meaning that there is no way to interface to a C++ function declared as: void foo(unsigned long); So, what to do about this? 1. elevate c_long and c_ulong into full fledged types. 2. create full fledged types __c_long and __c_ulong, and alias c_long and c_ulong to them.Having actual new types makes me a bit nervous in regards to how overloads will be handled, and how templates will be instantiated. I don't know how things happen behind the scenes, but (as I remember), writing "portable" C++ code to handle all possible integral primitives was a real hell, as on some systems, "foo(int)/foo(long)" would collide, whereas on others, you *need* both declared. Will this start happening in D too now...?
Sep 11 2014
On Wednesday, 10 September 2014 at 20:41:45 UTC, Walter Bright wrote:C++'s long and unsigned long can be accessed with c_long and c_ulong. Unfortunately, these are aliases and mangle to their underlying types. Meaning that there is no way to interface to a C++ function declared as: void foo(unsigned long); So, what to do about this? 1. elevate c_long and c_ulong into full fledged types. 2. create full fledged types __c_long and __c_ulong, and alias c_long and c_ulong to them. 3. some sort of attribute? The same issue exists for C++'s 'long double'.How would these choices affect/handle the dynamic nature of the current aliases? e.g. c_long on Windows is an int bu on Posix systems it can be int or long depending on the CPU architecture.
Sep 11 2014
On Wednesday, 10 September 2014 at 20:41:45 UTC, Walter Bright wrote:C++'s long and unsigned long can be accessed with c_long and c_ulong. Unfortunately, these are aliases and mangle to their underlying types.How about? pragma(mangle, "l") alias c_long = int;
Sep 13 2014