www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - C++ interop - what to do about long and unsigned long?

reply Walter Bright <newshound2 digitalmars.com> writes:
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
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdan.org> writes:
"bearophile" <bearophileHUGS lycos.com> wrote:

 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


C++ interoperability: 1,000,000 merit points
Anything related to the GC: 999,999 merit points
All else: two digits merit points
Sep 10 2014
parent reply "bachmeier" <no spam.net> writes:
On Wednesday, 10 September 2014 at 21:32:22 UTC, Andrei 
Alexandrescu wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote:

 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


 C++ interoperability: 1,000,000 merit points
 Anything related to the GC: 999,999 merit points
 All else: two digits merit points


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.
Sep 10 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent "bachmeier" <no spam.net> writes:
On Wednesday, 10 September 2014 at 23:18:18 UTC, Walter Bright 
wrote:

 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.


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.
Sep 11 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
next sibling parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei 
Alexandrescu wrote:

 On 9/10/14, 4:16 PM, bachmeier wrote:

 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


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.
--
/Paolo
Sep 10 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/10/14, 10:35 PM, Paolo Invernizzi wrote:

 On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:

 On 9/10/14, 4:16 PM, bachmeier wrote:

 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


 It's scaring that all the efforts are now focused on that.


Well they aren't :o).


 I'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
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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
parent reply "Paolo Invernizzi" <paolo.invernizzi no.address> writes:
On Thursday, 11 September 2014 at 07:52:01 UTC, Daniel Murphy 
wrote:

 "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.


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?

--
/Paolo
Sep 11 2014
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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
prev sibling next sibling parent reply "bachmeier" <no spam.com> writes:
On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei 
Alexandrescu wrote:

 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.


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.org
Sep 11 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/11/14, 5:47 AM, bachmeier wrote:

 On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:

 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.


 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.org


Of course. That's why I wrote:


 C++ interoperability: 1,000,000 merit points
 Anything related to the GC: 999,999 merit points
 All else: two digits merit points



Andrei
Sep 11 2014
prev sibling parent reply "Sean Kelly" <sean invisibleduck.org> writes:
On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei 
Alexandrescu wrote:

 On 9/10/14, 4:16 PM, bachmeier wrote:


 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.


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?
Sep 11 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/11/14, 8:39 AM, Sean Kelly wrote:

 On Thursday, 11 September 2014 at 00:29:37 UTC, Andrei Alexandrescu wrote:

 On 9/10/14, 4:16 PM, bachmeier wrote:


 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.


 Is C++ interop really that important or is it another one of those "if D
 had this, *then* I would use it!" dismissals.


It is that important.


 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
parent Andrej Mitrovic via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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
parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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?

 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.


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?
Sep 12 2014
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:


 Surely, at very least, an extern(C++) class should be final-by-default?


 How do you declare virtual extern(C++) class methods then?


with 'virtual' (which Andrei had removed)
Sep 12 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/13/14, 3:45 AM, bearophile wrote:

 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.


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.

Andrei
Sep 13 2014
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/13/2014 3:45 AM, bearophile wrote:

 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.


I guarantee that few will remember which way the final-by-default goes with 
which mode.
Sep 13 2014
parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
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?


 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.


I guarantee that few will remember which way the final-by-default goes with
which mode.



 Sep 13 2014



  parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org>  writes:


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



 next sibling parent  "Jakob Ovrum" <jakobovrum gmail.com>  writes:


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:

 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


+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.



 Sep 13 2014



prev sibling  parent reply "David Nadlinger" <code klickverbot.at>  writes:


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:

 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


Yep, there most definitely wasn't.

David



 Sep 14 2014



  parent  "monarch_dodra" <monarchdodra gmail.com>  writes:


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:

 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


 Yep, there most definitely wasn't.

 David


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.



 Sep 14 2014



prev sibling  parent  "bachmeier" <no spam.com>  writes:


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:

 On 9/10/14, 4:16 PM, bachmeier wrote:


 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.


 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?


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".



 Sep 12 2014



prev sibling  parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


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



prev sibling next sibling parent  "Adam D. Ruppe" <destructionator gmail.com>  writes:


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



prev sibling next sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com>  writes:


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



  parent  "Daniel Murphy" <yebbliesnospam gmail.com>  writes:


"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*


 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.


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.


 The same issue exists for C++'s 'long double'.


 I don't think so, as there is 'real' for that.


real doesn't always match long double in dmd. 



 Sep 11 2014



prev sibling next sibling parent  "monarch_dodra" <monarchdodra gmail.com>  writes:


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



prev sibling next sibling parent  "Gary Willoughby" <dev nomad.so>  writes:


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



prev sibling  parent  "Daniel N" <ufo orbiting.us>  writes:


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