www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How to use D for cross platform development?

reply "Bennie Copeland" <mugen.kanosei gmail.com> writes:
Hello all. I'm sorry if this has been addressed before.

For a little background. I've been studying C++ with the 
intention of doing cross platform work on Windows, OSX, and 
eventually iOS and some other mobile OSes. My plan was to write 
cross platform shared libraries for the core functionality and 
implement the GUI using Win32, Cocoa, etc. Well, while C++ is 
powerful, I'm finding it a beast to work with. I kept thinking 

stumbled upon D. D sounds exactly like what I am looking for, 
powerful yet productive and native.

My question however is how to do D cross platform development. I 
can't seem to find any recent information about it. From what I 
have gathered so far it seems, shared libraries are possible on 
win/osx/linux, but only when linked against other D code. For 
linking against C, I can create a DLL in windows, but I can't 
create an .so in linux, and no information at all about OSX. Some 
of the information I found is years old and I can't tell if the 
situation has changed. There is nothing in the FAQ about 
libraries. And googling provides little information.

So, is it possible to write the core of an application in a cross 
platform D library that can be callable by C, C++, or Objective-C 
to provide the GUI elements?
If not, is it possible to write a C wrapper around the library 
that is then callable by C, C++ or Objective-C?
How have others approached this situation?
Besides the library issues, what other issues or gotchas should I 
look out for in regards to cross platform development?
Mar 25 2012
next sibling parent maarten van damme <maartenvd1994 gmail.com> writes:
Op 25 maart 2012 13:12 schreef Bennie Copeland
<mugen.kanosei gmail.com>het volgende:

 For linking against C, I can create a DLL in windows, but I can't create
 an .so in linux, and no information at all about OSX.
From what I've heard this was a certain bug  (
http://d.puremagic.com/issues/show_bug.cgi?id=4583) that made it impossible to generate position independent code and thus no shared objects. This bug was fixed in dmd version 2.057 so it should work with dmd -c -fPIC and then use gcc on your platform to create the shared object. If you don't need/want to use dmd I think gdc is capable of doing it. Maarten
Mar 25 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 25 March 2012 13:22, maarten van damme <maartenvd1994 gmail.com> wrote:
 Op 25 maart 2012 13:12 schreef Bennie Copeland <mugen.kanosei gmail.com> =
het
 volgende:

 For linking against C, I can create a DLL in windows, but I can't create
 an .so in linux, and no information at all about OSX.
From what I've heard this was a certain bug =A0(http://d.puremagic.com/issues/show_bug.cgi?id=3D4583) that made it impossible to generate position independent code and thus no shared objec=
ts.
 This bug was fixed in dmd version 2.057 so it should work with dmd -c -fP=
IC
 and then use gcc on your platform to create the shared object.
 If you don't need/want to use dmd I think gdc is capable of doing it.
The rule of thumb generally is if you are able to build a gcc C cross compiler, you can just tack gdc onto it and it will be fine. Regards --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Mar 25 2012
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-25 13:12, Bennie Copeland wrote:
 Hello all. I'm sorry if this has been addressed before.

 For a little background. I've been studying C++ with the intention of
 doing cross platform work on Windows, OSX, and eventually iOS and some
 other mobile OSes. My plan was to write cross platform shared libraries
 for the core functionality and implement the GUI using Win32, Cocoa,
 etc. Well, while C++ is powerful, I'm finding it a beast to work with. I

 until I stumbled upon D. D sounds exactly like what I am looking for,
 powerful yet productive and native.
First I have to say that D is a great language for doing cross platform development. But for iOS there are a couple of big problems. The reference D compiler, DMD, does not have an ARM-backend. There are other compilers available though: LDC, the DMD frontend on the LLVM backend and GDC, the DMD frontend on the GCC backend. Second big problem is the D runtime does not support ARM. As far as I know, no one has ever used D on iOS.
 My question however is how to do D cross platform development. I can't
 seem to find any recent information about it. From what I have gathered
 so far it seems, shared libraries are possible on win/osx/linux, but
 only when linked against other D code. For linking against C, I can
 create a DLL in windows, but I can't create an .so in linux, and no
 information at all about OSX. Some of the information I found is years
 old and I can't tell if the situation has changed. There is nothing in
 the FAQ about libraries. And googling provides little information.
You should be able to create shared libraries for linking with C code. You just need to make sure you initialize the D runtime. I'm not entirely sure about the status for creating shared libraries, not sure if the runtime has been modified to support that on all platforms. I think Windows and Linux is good to go but I don't think the runtime is not ready yet for Mac OS X.
 So, is it possible to write the core of an application in a cross
 platform D library that can be callable by C, C++, or Objective-C to
 provide the GUI elements?
 If not, is it possible to write a C wrapper around the library that is
 then callable by C, C++ or Objective-C?
 How have others approached this situation?
 Besides the library issues, what other issues or gotchas should I look
 out for in regards to cross platform development?
When it comes to providing a GUI for your application there are a couple of choices: * Directly access the native GUI operations of the operating system * Use a cross platform GUI library For directly accessing the native GUI of the operating system there are again various options. First option, C wrapper. A C wrapper works for all languages you need to interact with: C, C++ and Objective-C. D has limited support for interfacing directly with C++. For example, D understand the C++ mangling and you can call virtual C++ functions from D. This could be another idea, or used together with C wrappers. http://dlang.org/cpp_interface.html For interfacing with Objective-C there are a couple of options as well. One option is to use C wrappers. Another is to use the Objective-C runtime functions to get be able to create Objective-C class and methods from D. There are two projects that have gone this road and created a fully working, fully automatic bridge between D and Objective-C. Although it turned out to not be usable in practice. A third option for Objective-C would be to use a fork of DMD that makes it possible to directly interface with Objective-C, just as it's possible with C. I'm not sure of the status of this project but an alpha has been released. D/Objective-C bridge: http://dsource.org/projects/dstep D/Objective-C bridge: http://michelf.com/projects/d-objc-bridge/ DMD fork: http://michelf.com/projects/d-objc/ Cross platform GUI libraries. Here are again several options: * DWT - Port of SWT. Uses the native operations of the operating system. Supports Windows (win32) and Linux (GTK+). Support for Mac OS X (Cocoa) is worked on. http://dsource.org/projects/dwt * gtkD - Bindings to GTK. Does not use the native drawing operations of the operating system. Available on all platforms. http://dsource.org/projects/gtkd * QtD - Bindings to Qt. Use the native drawing operations of the operating system (I think). Available on all platforms. Not sure if this is developed any more. http://dsource.org/projects/qtd * wxD - Bindings to wxWidgets. Use the native drawing operations of the operating system. Available on all platforms. Not sure of the status. http://wxd.sourceforge.net/ -- /Jacob Carlborg
Mar 25 2012
next sibling parent reply =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= <xtzgzorex gmail.com> writes:
On 25-03-2012 17:04, Jacob Carlborg wrote:
 On 2012-03-25 13:12, Bennie Copeland wrote:
 Hello all. I'm sorry if this has been addressed before.

 For a little background. I've been studying C++ with the intention of
 doing cross platform work on Windows, OSX, and eventually iOS and some
 other mobile OSes. My plan was to write cross platform shared libraries
 for the core functionality and implement the GUI using Win32, Cocoa,
 etc. Well, while C++ is powerful, I'm finding it a beast to work with. I

 until I stumbled upon D. D sounds exactly like what I am looking for,
 powerful yet productive and native.
First I have to say that D is a great language for doing cross platform development. But for iOS there are a couple of big problems. The reference D compiler, DMD, does not have an ARM-backend. There are other compilers available though: LDC, the DMD frontend on the LLVM backend and GDC, the DMD frontend on the GCC backend. Second big problem is the D runtime does not support ARM. As far as I know, no one has ever used D on iOS.
About ARM support: That's not strictly true. D on ARM should work fine at this point in time if you build druntime/phobos in GDC with -fno-section-anchors (there is even some experimental Android support). But indeed, no iOS support.
 My question however is how to do D cross platform development. I can't
 seem to find any recent information about it. From what I have gathered
 so far it seems, shared libraries are possible on win/osx/linux, but
 only when linked against other D code. For linking against C, I can
 create a DLL in windows, but I can't create an .so in linux, and no
 information at all about OSX. Some of the information I found is years
 old and I can't tell if the situation has changed. There is nothing in
 the FAQ about libraries. And googling provides little information.
You should be able to create shared libraries for linking with C code. You just need to make sure you initialize the D runtime. I'm not entirely sure about the status for creating shared libraries, not sure if the runtime has been modified to support that on all platforms. I think Windows and Linux is good to go but I don't think the runtime is not ready yet for Mac OS X.
 So, is it possible to write the core of an application in a cross
 platform D library that can be callable by C, C++, or Objective-C to
 provide the GUI elements?
 If not, is it possible to write a C wrapper around the library that is
 then callable by C, C++ or Objective-C?
 How have others approached this situation?
 Besides the library issues, what other issues or gotchas should I look
 out for in regards to cross platform development?
When it comes to providing a GUI for your application there are a couple of choices: * Directly access the native GUI operations of the operating system * Use a cross platform GUI library For directly accessing the native GUI of the operating system there are again various options. First option, C wrapper. A C wrapper works for all languages you need to interact with: C, C++ and Objective-C. D has limited support for interfacing directly with C++. For example, D understand the C++ mangling and you can call virtual C++ functions from D. This could be another idea, or used together with C wrappers. http://dlang.org/cpp_interface.html For interfacing with Objective-C there are a couple of options as well. One option is to use C wrappers. Another is to use the Objective-C runtime functions to get be able to create Objective-C class and methods from D. There are two projects that have gone this road and created a fully working, fully automatic bridge between D and Objective-C. Although it turned out to not be usable in practice. A third option for Objective-C would be to use a fork of DMD that makes it possible to directly interface with Objective-C, just as it's possible with C. I'm not sure of the status of this project but an alpha has been released. D/Objective-C bridge: http://dsource.org/projects/dstep D/Objective-C bridge: http://michelf.com/projects/d-objc-bridge/ DMD fork: http://michelf.com/projects/d-objc/ Cross platform GUI libraries. Here are again several options: * DWT - Port of SWT. Uses the native operations of the operating system. Supports Windows (win32) and Linux (GTK+). Support for Mac OS X (Cocoa) is worked on. http://dsource.org/projects/dwt * gtkD - Bindings to GTK. Does not use the native drawing operations of the operating system. Available on all platforms. http://dsource.org/projects/gtkd * QtD - Bindings to Qt. Use the native drawing operations of the operating system (I think). Available on all platforms. Not sure if this is developed any more. http://dsource.org/projects/qtd * wxD - Bindings to wxWidgets. Use the native drawing operations of the operating system. Available on all platforms. Not sure of the status. http://wxd.sourceforge.net/
-- - Alex
Mar 25 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-25 18:20, Alex Rønne Petersen wrote:

 About ARM support: That's not strictly true. D on ARM should work fine
 at this point in time if you build druntime/phobos in GDC with
 -fno-section-anchors (there is even some experimental Android support).
 But indeed, no iOS support.
Ok, I didn't know about that. Is GDC using its own runtime? -- /Jacob Carlborg
Mar 25 2012
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 25 March 2012 21:31, Jacob Carlborg <doob me.com> wrote:
 On 2012-03-25 18:20, Alex R=F8nne Petersen wrote:

 About ARM support: That's not strictly true. D on ARM should work fine
 at this point in time if you build druntime/phobos in GDC with
 -fno-section-anchors (there is even some experimental Android support).
 But indeed, no iOS support.
Ok, I didn't know about that. Is GDC using its own runtime? -- /Jacob Carlborg
A spork of druntime, yes. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Mar 25 2012
prev sibling next sibling parent James Miller <james aatch.net> writes:
On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 A spork of druntime, yes.
A spork? I've never heard that before... -- James Miller
Mar 25 2012
prev sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 25 March 2012 21:55, James Miller <james aatch.net> wrote:
 On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 A spork of druntime, yes.
A spork? I've never heard that before...
It's constantly merged from upstream, however we keep any GDC-specific differences in-house. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 25 2012
prev sibling parent reply "Bennie Copeland" <mugen.kanosei gmail.com> writes:
On Sunday, 25 March 2012 at 16:20:51 UTC, Alex Rønne Petersen 
wrote:
 About ARM support: That's not strictly true. D on ARM should 
 work fine at this point in time if you build druntime/phobos in 
 GDC with -fno-section-anchors (there is even some experimental 
 Android support). But indeed, no iOS support.
I'm still new at low level programming topics like ABI's etc, so I'll betray my ignorance. Is the druntime only required for providing an interface between the executable and OS resources like IO, or is it inseparable from the language? For example, if I wrote the shell of an iOS app in Obj-C that handled the interface with the phone software/hardware, could the remaining core be written using D? Or is the language capabilities like GC, slicing, mixins, etc. intimately tied to the runtime or phobes?
Mar 28 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-28 17:23, Bennie Copeland wrote:

 I'm still new at low level programming topics like ABI's etc, so I'll
 betray my ignorance. Is the druntime only required for providing an
 interface between the executable and OS resources like IO, or is it
 inseparable from the language? For example, if I wrote the shell of an
 iOS app in Obj-C that handled the interface with the phone
 software/hardware, could the remaining core be written using D? Or is
 the language capabilities like GC, slicing, mixins, etc. intimately tied
 to the runtime or phobes?
Druntime is basically inseparable from the language. Among other things it contains the GC, it's used for handling arrays (appending, concatenation, slicing, switch statements and so on), threads, thread local storage (TLS) and a lot of other stuff I can't remember right now. But I don't see that stopping anyone for writing parts of an app using Objective-C and the other parts using D. -- /Jacob Carlborg
Mar 28 2012
prev sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Bennie Copeland" <mugen.kanosei gmail.com> wrote in message 
news:mizfgcnxjpbfbclcsmwo forum.dlang.org...
 On Sunday, 25 March 2012 at 16:20:51 UTC, Alex Rønne Petersen wrote:
 About ARM support: That's not strictly true. D on ARM should work fine at 
 this point in time if you build druntime/phobos in GDC 
 with -fno-section-anchors (there is even some experimental Android 
 support). But indeed, no iOS support.
I'm still new at low level programming topics like ABI's etc, so I'll betray my ignorance. Is the druntime only required for providing an interface between the executable and OS resources like IO, or is it inseparable from the language? For example, if I wrote the shell of an iOS app in Obj-C that handled the interface with the phone software/hardware, could the remaining core be written using D? Or is the language capabilities like GC, slicing, mixins, etc. intimately tied to the runtime or phobes?
Some basic things are tied into druntme/phobos. The GC is definitely one of them. AIUI, Arrays and AAs have been moving to a druntime-based implementation, and the Object class is implemented there. Technically, you can use D without druntime/phobos. Hell, druntime itself is implemented in D. And I've even done it myself ages ago ( https://www.semitwist.com/articles/article/view/d-on-gba-nds-progr ss-thanks-to-oopman ) . But you'd be limited to a relatively small C-like subset of the langauge (which I'd argue *can* still be worthwhile in cases where C is your only other option - like low-power embedded stuff).
Mar 28 2012
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Mar 28, 2012 at 03:13:01PM -0400, Nick Sabalausky wrote:
[...]
 Some basic things are tied into druntme/phobos. The GC is definitely
 one of them. AIUI, Arrays and AAs have been moving to a druntime-based
 implementation, and the Object class is implemented there.
 
 Technically, you can use D without druntime/phobos. Hell, druntime
 itself is implemented in D. And I've even done it myself ages ago (
 https://www.semitwist.com/articles/article/view/d-on-gba-nds-progress-thanks-to-oopman
 ) . But you'd be limited to a relatively small C-like subset of the
 langauge (which I'd argue *can* still be worthwhile in cases where C
 is your only other option - like low-power embedded stuff).
[...] I've been toying with the idea of an AA implementation that doesn't' need the GC... Basically translate it to work with explicit malloc/free instead of the GC. But currently I'm already maxed out fixing my AA replacement for druntime, so I don't think I'll get to that in the near future. (It's true that they say about the last 10% of a project needing 90% of the time... I *thought* my AA implementation was close to being ready to integrate into druntime, but that last 10% is turning into a huge project in and of itself. (Several compiler bugs later. ;-) (Hey, at least I'm helping to weed out dmd bugs! (Gah, I'm starting to Lisp, better stop now!)))) T -- PNP = Plug 'N' Pray
Mar 28 2012
parent "Nick Sabalausky" <a a.a> writes:
"H. S. Teoh" <hsteoh quickfur.ath.cx> wrote in message 
news:mailman.1199.1332962802.4860.digitalmars-d puremagic.com...
 ( [...] ( [...] ( [...] (Gah, I'm starting to Lisp, better stop now!))))
lol :)
Mar 28 2012
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2012-03-25 15:04:34 +0000, Jacob Carlborg <doob me.com> said:

 A third option for Objective-C would be to use a fork of DMD that makes 
 it possible to directly interface with Objective-C, just as it's 
 possible with C. I'm not sure of the status of this project but an 
 alpha has been released.
It is not up to date with the latest DMD versions. The project is on hold as I'm working on other things. But it can compile code if you target the Apple's 32-bit Legacy Objective-C runtime. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 25 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, March 26, 2012 09:55:00 James Miller wrote:
 On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 A spork of druntime, yes.
A spork? I've never heard that before...
http://en.wikipedia.org/wiki/Spork Not that it has anything to do with software... - Jonathan M Davis
Mar 25 2012
prev sibling next sibling parent Kevin Cox <kevincox.ca gmail.com> writes:
On Mar 25, 2012 7:34 PM, "Jonathan M Davis" <jmdavisProg gmx.com> wrote:
 On Monday, March 26, 2012 09:55:00 James Miller wrote:
 On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:
 A spork of druntime, yes.
A spork? I've never heard that before...
http://en.wikipedia.org/wiki/Spork Not that it has anything to do with software... - Jonathan M Davis
I like it. Not separated just a set of patches.
Mar 25 2012
prev sibling parent reply "Chris W." <wendlec cd.ie> writes:
I am using D for cross platform development. I recently 
implemented C wrappers for D. It works fine (Mac OS X). I could 
also create a Python module that consists of both D and C code 
(the C code is really just the wrapper for the module's 
functionality that is completely in D). It also works with Lua.

I think the decision to make C logic part of the language was a 
very very good idea. The dream of every cross platform developer.
Mar 26 2012
parent reply "Bennie Copeland" <mugen.kanosei gmail.com> writes:
On Monday, 26 March 2012 at 10:46:39 UTC, Chris W. wrote:
 I am using D for cross platform development. I recently 
 implemented C wrappers for D. It works fine (Mac OS X). I could 
 also create a Python module that consists of both D and C code 
 (the C code is really just the wrapper for the module's 
 functionality that is completely in D). It also works with Lua.

 I think the decision to make C logic part of the language was a 
 very very good idea. The dream of every cross platform 
 developer.
Great to hear someone with experience with it. Was there any issues with the code that had to be tweaked depending on the OS? When I was looking at C++, there was implementation defined data type sizes, endieness, implementation defined order of variables in a struct, etc. On that topic, what do I have to consider in D if I want binary compatibility in files saved on different OS's?
Mar 28 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 28 March 2012 16:31, Bennie Copeland <mugen.kanosei gmail.com> wrote:
 On Monday, 26 March 2012 at 10:46:39 UTC, Chris W. wrote:
 I am using D for cross platform development. I recently implemented C
 wrappers for D. It works fine (Mac OS X). I could also create a Python
 module that consists of both D and C code (the C code is really just the
 wrapper for the module's functionality that is completely in D). It also
 works with Lua.

 I think the decision to make C logic part of the language was a very very
 good idea. The dream of every cross platform developer.
Great to hear someone with experience with it. Was there any issues with the code that had to be tweaked depending on the OS? When I was looking at C++, there was implementation defined data type sizes, endieness, implementation defined order of variables in a struct, etc. On that topic, what do I have to consider in D if I want binary compatibility in files saved on different OS's?
Binary compatibility by measure of thumb is no different to binary compatibility in C or C++ when moving executables across different versions of the same platform. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Mar 28 2012
parent "Nick Sabalausky" <a a.a> writes:
"Iain Buclaw" <ibuclaw ubuntu.com> wrote in message 
news:mailman.1198.1332955673.4860.digitalmars-d puremagic.com...
 On 28 March 2012 16:31, Bennie Copeland <mugen.kanosei gmail.com> wrote:
 On Monday, 26 March 2012 at 10:46:39 UTC, Chris W. wrote:
 I am using D for cross platform development. I recently implemented C
 wrappers for D. It works fine (Mac OS X). I could also create a Python
 module that consists of both D and C code (the C code is really just the
 wrapper for the module's functionality that is completely in D). It also
 works with Lua.

 I think the decision to make C logic part of the language was a very 
 very
 good idea. The dream of every cross platform developer.
Great to hear someone with experience with it. Was there any issues with the code that had to be tweaked depending on the OS? When I was looking at C++, there was implementation defined data type sizes, endieness, implementation defined order of variables in a struct, etc. On that topic, what do I have to consider in D if I want binary compatibility in files saved on different OS's?
Binary compatibility by measure of thumb is no different to binary compatibility in C or C++ when moving executables across different versions of the same platform.
D makes it a little easier though with things like "int"/"long"/etc being the same size on all platforms, and "align" for structs. And just generally having less "undefined/implementation-defined" cruft.
Mar 28 2012
prev sibling parent reply "Chris W." <wendlec cd.ie> writes:
On Wednesday, 28 March 2012 at 15:31:26 UTC, Bennie Copeland 
wrote:
 Great to hear someone with experience with it. Was there any 
 issues with the code that had to be tweaked depending on the 
 OS? When I was looking at C++, there was implementation defined 
 data type sizes, endieness, implementation defined order of 
 variables in a struct, etc. On that topic, what do I have to 
 consider in D if I want binary compatibility in files saved on 
 different OS's?
I cannot give you any advice as regards C++, because I have never really used it - avoiding it like the plague. My strategy is to keep things as simple as possible and use C only as the "glue". It's a bit like the Lua approach which only uses ANSI C to ensure maximum portability. Since I have just started to put the pieces together, I have yet to test whether it works on all platforms. I haven't tested it on Windows yet and don't know where the pitfalls are (and I am sure there are some!). It is amazing, though, how easily C code can be integrated into a D program. I have to use two external frameworks/libraries written in C (one of them the utf8proc library). With a few lines of code I've got all the functionality I need without writing any wrappers. I have not yet used Objective-C with D directly. Does anyone have experience with that?
Mar 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-29 11:12, Chris W. wrote:

 I cannot give you any advice as regards C++, because I have never really
 used it - avoiding it like the plague. My strategy is to keep things as
 simple as possible and use C only as the "glue". It's a bit like the Lua
 approach which only uses ANSI C to ensure maximum portability.

 Since I have just started to put the pieces together, I have yet to test
 whether it works on all platforms. I haven't tested it on Windows yet
 and don't know where the pitfalls are (and I am sure there are some!).
 It is amazing, though, how easily C code can be integrated into a D
 program. I have to use two external frameworks/libraries written in C
 (one of them the utf8proc library). With a few lines of code I've got
 all the functionality I need without writing any wrappers.

 I have not yet used Objective-C with D directly. Does anyone have
 experience with that?
I have some with using Objective-C together with D. It's a lot more verbose and quite more complicated than using a C library with D. How complicated it is depends on what one want to do with the Objective-C library. Obviously one want to create Objective-C objects and call Objective-C methods. But if it's necessary to create subclasses in D and have Objective-C create instances of those classes and call methods on the objects it gets even more complicated. I would recommend to have a look at Michel Fortin's fork of DMD which adds support for binding to Objective-C code directly, i.e. extern(Objective-C). Note that it's not 100% complete and based on an older version of DMD. http://michelf.com/projects/d-objc/ -- /Jacob Carlborg
Mar 29 2012
parent reply "Chris W." <wendlec cd.ie> writes:
On Thursday, 29 March 2012 at 12:10:17 UTC, Jacob Carlborg wrote:
 I have some with using Objective-C together with D. It's a lot 
 more verbose and quite more complicated than using a C library 
 with D.

 How complicated it is depends on what one want to do with the 
 Objective-C library. Obviously one want to create Objective-C 
 objects and call Objective-C methods. But if it's necessary to 
 create subclasses in D and have Objective-C create instances of 
 those classes and call methods on the objects it gets even more 
 complicated.

 I would recommend to have a look at Michel Fortin's fork of DMD 
 which adds support for binding to Objective-C code directly, 
 i.e. extern(Objective-C). Note that it's not 100% complete and 
 based on an older version of DMD.

 http://michelf.com/projects/d-objc/
Thanks for the link. Objective-C is basically C and can be implemented in C style as far as I know. Is it worth going down to the C level like so: struct NSObject { struct objc_class* isa; } struct objc_class { Class isa; Class super_class; const char *name; long version; long info; long instance_size; struct objc_ivar_list *ivars; struct objc_method_list **methodLists; struct objc_cache *cache; struct objc_protocol_list *protocols; } Just a random thought.
Mar 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-29 14:44, Chris W. wrote:

 Thanks for the link. Objective-C is basically C and can be implemented
 in C style as far as I know. Is it worth going down to the C level like so:
Yes that would be possible.
 struct NSObject {
 struct objc_class* isa;
 }
 struct objc_class {
 Class isa;
 Class super_class;
 const char *name;
 long version;
 long info;
 long instance_size;
 struct objc_ivar_list *ivars;
 struct objc_method_list **methodLists;
 struct objc_cache *cache;
 struct objc_protocol_list *protocols;
 }

 Just a random thought.
That's the alternative approach, I've done that as well. It's very tedious and becomes verbose very fast. Both I and Michel have created an Objective-C/D bridge that uses this approach. It lets you call Objective-C methods, create instances of Objective-C classes, create subclasses in D that inherit from Objective-C classes and so on. It did this all automatically. The problem with the bridge was the enormous template bloat. A GUI Hello World application takes around 60MB with the bridge. http://www.dsource.org/projects/dstep http://michelf.com/projects/d-objc-bridge/ That's why Michel started the DMD fork to directly support binding to Objective-C classes and methods. If you just have a small amount of Objective-C code that needs to be called and basically never changes then it won't be a problem using the Objective-C runtime functions. Otherwise I wouldn't recommend it. I've ported the SDL initialization code for Mac OS X to D, to be used in derelict. This doesn't contain any fancy templates like the bridge uses to help making the code less verbose. It's quite a lot of D code compared to the Objective-C code: http://dsource.org/projects/derelict/browser/branches/Derelict2/DerelictSDL/derelict/sdl/macinit This would be the original Objective-C code: http://codespeak.net/svn/pypy/dist/pypy/rlib/rsdl/macosx-sdl-main/SDLMain.m If you're going with this approach you could have a look at my bridge if you need help, it has some useful documentation of how it works and is implemented: http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals -- /Jacob Carlborg
Mar 29 2012
next sibling parent reply "Bennie Copeland" <mugen.kanosei gmail.com> writes:
On Thursday, 29 March 2012 at 16:36:57 UTC, Jacob Carlborg wrote:
 On 2012-03-29 14:44, Chris W. wrote:

 Thanks for the link. Objective-C is basically C and can be 
 implemented
 in C style as far as I know. Is it worth going down to the C 
 level like so:
Yes that would be possible.
 struct NSObject {
 struct objc_class* isa;
 }
 struct objc_class {
 Class isa;
 Class super_class;
 const char *name;
 long version;
 long info;
 long instance_size;
 struct objc_ivar_list *ivars;
 struct objc_method_list **methodLists;
 struct objc_cache *cache;
 struct objc_protocol_list *protocols;
 }

 Just a random thought.
That's the alternative approach, I've done that as well. It's very tedious and becomes verbose very fast. Both I and Michel have created an Objective-C/D bridge that uses this approach. It lets you call Objective-C methods, create instances of Objective-C classes, create subclasses in D that inherit from Objective-C classes and so on. It did this all automatically. The problem with the bridge was the enormous template bloat. A GUI Hello World application takes around 60MB with the bridge. http://www.dsource.org/projects/dstep http://michelf.com/projects/d-objc-bridge/ That's why Michel started the DMD fork to directly support binding to Objective-C classes and methods. If you just have a small amount of Objective-C code that needs to be called and basically never changes then it won't be a problem using the Objective-C runtime functions. Otherwise I wouldn't recommend it. I've ported the SDL initialization code for Mac OS X to D, to be used in derelict. This doesn't contain any fancy templates like the bridge uses to help making the code less verbose. It's quite a lot of D code compared to the Objective-C code: http://dsource.org/projects/derelict/browser/branches/Derelict2/DerelictSDL/derelict/sdl/macinit This would be the original Objective-C code: http://codespeak.net/svn/pypy/dist/pypy/rlib/rsdl/macosx-sdl-main/SDLMain.m If you're going with this approach you could have a look at my bridge if you need help, it has some useful documentation of how it works and is implemented: http://www.dsource.org/projects/dstep/wiki/ObjcBridge/BridgeInternals
Thanks for your help. My primary use case is to provide a native look and feel GUI on the Mac. So, to the extent of creating the interface using Cocoa and tying it back to the core code written in D.
Mar 29 2012
next sibling parent reply Gour <gour atmarama.net> writes:
On Thu, 29 Mar 2012 21:03:05 +0200
"Bennie Copeland" <mugen.kanosei gmail.com> wrote:

 Thanks for your help. My primary use case is to provide a native=20
 look and feel GUI on the Mac. So, to the extent of creating the=20
 interface using Cocoa and tying it back to the core code written=20
 in D.
Have you considered using wxD? New version on which Andrej is working at the moment will support wx-2.9.x/3.0 for which there is new Cocoa port. Sincerely, Gour --=20 There is no work that affects Me; nor do I aspire for the=20 fruits of action. One who understands this truth about Me also=20 does not become entangled in the fruitive reactions of work. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Mar 29 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-29 21:45, Gour wrote:
 On Thu, 29 Mar 2012 21:03:05 +0200
 "Bennie Copeland"<mugen.kanosei gmail.com>  wrote:

 Thanks for your help. My primary use case is to provide a native
 look and feel GUI on the Mac. So, to the extent of creating the
 interface using Cocoa and tying it back to the core code written
 in D.
Have you considered using wxD? New version on which Andrej is working at the moment will support wx-2.9.x/3.0 for which there is new Cocoa port.
That would be another idea. It would also be possible to add some Objective-C code, or D code that calls Objective-C code, to do some platform specific functionality that wxD and wxWidget can't handle. -- /Jacob Carlborg
Mar 29 2012
parent "Chris W." <wendlec cd.ie> writes:
That's all great stuff. Thanks guys. I think in this respect D 
could really take off, i.e. as the natively compiled, portable 
"core language" that can easily interface to platform specific 
frameworks through C and C++. This, among other things, got me 
interested in D in the first place. I think developers are less 
and less willing to re-implement their programs (or portions of 
it) for each platform – especially now that mobile devices add 
yet another array of OSes to the market. It's a question of time, 
money, maintenance and last but not least of trying to avoid more 
work (doing the same thing really).
Mar 30 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-03-29 21:03, Bennie Copeland wrote:

 Thanks for your help. My primary use case is to provide a native look
 and feel GUI on the Mac. So, to the extent of creating the interface
 using Cocoa and tying it back to the core code written in D.
In that case you would, hopefully, only need a new functions declared as extern (C) in the D code which the Objective-C code calls. Make the separation as clear as possible and make the interaction between the languages minimal. -- /Jacob Carlborg
Mar 29 2012
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2012-03-29 16:36:55 +0000, Jacob Carlborg <doob me.com> said:

 Both I and Michel have created an Objective-C/D bridge that uses this 
 approach. It lets you call Objective-C methods, create instances of 
 Objective-C classes, create subclasses in D that inherit from 
 Objective-C classes and so on. It did this all automatically. The 
 problem with the bridge was the enormous template bloat. A GUI Hello 
 World application takes around 60MB with the bridge.
 
 http://www.dsource.org/projects/dstep
 http://michelf.com/projects/d-objc-bridge/
All true. The tricky thing with Objective-C is that you need to subclass Objective-C classes to make use of Cocoa. It's that mechanism that let you create a "D subclass" of a Objective-C class that is so heavyweight, and also not very efficient. Just calling Objective-C code is relatively easy in D if you don't need to subclass, but it won't take you very far.
 That's why Michel started the DMD fork to directly support binding to 
 Objective-C classes and methods.
Indeed. And the approach makes much more sense. Only I don't really have time for compiler hacking these days. I still hope I'll be able to continue it later this year. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 30 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-03-30 13:09, Michel Fortin wrote:
 Indeed. And the approach makes much more sense. Only I don't really have
 time for compiler hacking these days. I still hope I'll be able to
 continue it later this year.
I don't know if you have seen this, but I took the liberty to add your project as an idea for GSOC 2012: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas#Objective-Csupport I hope it's Ok :) -- /Jacob Carlborg
Mar 30 2012
parent Michel Fortin <michel.fortin michelf.com> writes:
On 2012-03-30 12:34:50 +0000, Jacob Carlborg <doob me.com> said:

 On 2012-03-30 13:09, Michel Fortin wrote:
 Indeed. And the approach makes much more sense. Only I don't really have
 time for compiler hacking these days. I still hope I'll be able to
 continue it later this year.
I don't know if you have seen this, but I took the liberty to add your project as an idea for GSOC 2012: http://prowiki.org/wiki4d/wiki.cgi?GSOC_2012_Ideas#Objective-Csupport I hope it's Ok :)
I had not seen this. Great idea! -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Mar 30 2012