digitalmars.D - How to use D for cross platform development?
- Bennie Copeland (27/27) Mar 25 2012 Hello all. I'm sorry if this has been addressed before.
- maarten van damme (8/11) Mar 25 2012 http://d.puremagic.com/issues/show_bug.cgi?id=4583) that made it impossi...
- Iain Buclaw (10/20) Mar 25 2012 ts.
- Jacob Carlborg (56/81) Mar 25 2012 First I have to say that D is a great language for doing cross platform
- =?UTF-8?B?QWxleCBSw7hubmUgUGV0ZXJzZW4=?= (7/87) Mar 25 2012 About ARM support: That's not strictly true. D on ARM should work fine
- Jacob Carlborg (4/8) Mar 25 2012 Ok, I didn't know about that. Is GDC using its own runtime?
- Iain Buclaw (5/13) Mar 25 2012 A spork of druntime, yes.
- James Miller (4/5) Mar 25 2012 A spork? I've never heard that before...
- Iain Buclaw (6/9) Mar 25 2012 It's constantly merged from upstream, however we keep any GDC-specific
- Bennie Copeland (10/14) Mar 28 2012 I'm still new at low level programming topics like ABI's etc, so
- Jacob Carlborg (9/17) Mar 28 2012 Druntime is basically inseparable from the language. Among other things
- Nick Sabalausky (11/26) Mar 28 2012 Some basic things are tied into druntme/phobos. The GC is definitely one...
- H. S. Teoh (17/27) Mar 28 2012 [...]
- Nick Sabalausky (3/4) Mar 28 2012 lol :)
- Michel Fortin (8/12) Mar 25 2012 It is not up to date with the latest DMD versions. The project is on
- Jonathan M Davis (4/8) Mar 25 2012 http://en.wikipedia.org/wiki/Spork
- Kevin Cox (2/10) Mar 25 2012 I like it. Not separated just a set of patches.
- Chris W. (7/7) Mar 26 2012 I am using D for cross platform development. I recently
- Bennie Copeland (7/15) Mar 28 2012 Great to hear someone with experience with it. Was there any
- Iain Buclaw (7/23) Mar 28 2012 Binary compatibility by measure of thumb is no different to binary
- Nick Sabalausky (5/33) Mar 28 2012 D makes it a little easier though with things like "int"/"long"/etc bein...
- Chris W. (17/24) Mar 29 2012 I cannot give you any advice as regards C++, because I have never
- Jacob Carlborg (15/28) Mar 29 2012 I have some with using Objective-C together with D. It's a lot more
- Chris W. (20/34) Mar 29 2012 Thanks for the link. Objective-C is basically C and can be
- Jacob Carlborg (30/48) Mar 29 2012 That's the alternative approach, I've done that as well. It's very
- Bennie Copeland (5/56) Mar 29 2012 Thanks for your help. My primary use case is to provide a native
- Gour (11/15) Mar 29 2012 Have you considered using wxD? New version on which Andrej is working at
- Jacob Carlborg (6/14) Mar 29 2012 That would be another idea. It would also be possible to add some
- Chris W. (10/10) Mar 30 2012 That's all great stuff. Thanks guys. I think in this respect D
- Jacob Carlborg (7/10) Mar 29 2012 In that case you would, hopefully, only need a new functions declared as...
- Michel Fortin (15/26) Mar 30 2012 All true.
- Jacob Carlborg (7/10) Mar 30 2012 I don't know if you have seen this, but I took the liberty to add your
- Michel Fortin (6/17) Mar 30 2012 I had not seen this. Great idea!
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
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
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> =hetvolgende:ts.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=This bug was fixed in dmd version 2.057 so it should work with dmd -c -fP=ICand 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
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
On 25-03-2012 17:04, Jacob Carlborg wrote:On 2012-03-25 13:12, Bennie Copeland 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.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.-- - AlexMy 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/
Mar 25 2012
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
On 25 March 2012 21:31, Jacob Carlborg <doob me.com> wrote:On 2012-03-25 18:20, Alex R=F8nne Petersen wrote:A spork of druntime, yes. --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';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
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
On 25 March 2012 21:55, James Miller <james aatch.net> wrote:On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:It's constantly merged from upstream, however we keep any GDC-specific differences in-house. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';A spork of druntime, yes.A spork? I've never heard that before...
Mar 25 2012
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
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
"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: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).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
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
"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
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
On Monday, March 26, 2012 09:55:00 James Miller wrote:On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:http://en.wikipedia.org/wiki/Spork Not that it has anything to do with software... - Jonathan M DavisA spork of druntime, yes.A spork? I've never heard that before...
Mar 25 2012
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:I like it. Not separated just a set of patches.On 26 March 2012 09:44, Iain Buclaw <ibuclaw ubuntu.com> wrote:http://en.wikipedia.org/wiki/Spork Not that it has anything to do with software... - Jonathan M DavisA spork of druntime, yes.A spork? I've never heard that before...
Mar 25 2012
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
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
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: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';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
"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: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.On Monday, 26 March 2012 at 10:46:39 UTC, Chris W. wrote: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.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
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
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
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
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
On Thursday, 29 March 2012 at 16:36:57 UTC, Jacob Carlborg wrote:On 2012-03-29 14:44, Chris W. 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.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
Mar 29 2012
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
On 2012-03-29 21:45, Gour wrote:On Thu, 29 Mar 2012 21:03:05 +0200 "Bennie Copeland"<mugen.kanosei gmail.com> wrote: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 CarlborgThanks 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.
Mar 29 2012
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
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
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
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
On 2012-03-30 12:34:50 +0000, Jacob Carlborg <doob me.com> said:On 2012-03-30 13:09, Michel Fortin wrote:I had not seen this. Great idea! -- Michel Fortin michel.fortin michelf.com http://michelf.com/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 :)
Mar 30 2012