Hi,

I would really like to start using D in our small company as a
C++ replacement. With that in mind I do have few questions:

1) Is D2 really ready for production code? I often hear ppl
complaining about compiler bugs or regressions causing them to
drop D "for now". Is it true that D has GC problems?

2) Is there a way to start adding D code to a C++ projects? For
example build a dll in D that is loaded by C++ host app? I guess
that is not possible because of GC not being there?

3) Is it possible to use D on iOS?

We will for sure switch to D eventually. Question is, when can we
start the transition so it would not fire back on us.

On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
> Hi,
>
> I would really like to start using D in our small company as a
> C++ replacement. With that in mind I do have few questions:
>
> 1) Is D2 really ready for production code? I often hear ppl
> complaining about compiler bugs or regressions causing them to
> drop D "for now". Is it true that D has GC problems?
>
> 2) Is there a way to start adding D code to a C++ projects? For
> example build a dll in D that is loaded by C++ host app? I guess
> that is not possible because of GC not being there?
>
> 3) Is it possible to use D on iOS?
>
> We will for sure switch to D eventually. Question is, when can we
> start the transition so it would not fire back on us.

1a) no 1b) yes
2) no/yes (dll on windows - yes + pain, elsewhere - no)
3) no

On Friday, 25 January 2013 at 20:47:15 UTC, q66 wrote:
> On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
>> Hi,
>>
>> I would really like to start using D in our small company as a
>> C++ replacement. With that in mind I do have few questions:
>>
>> 1) Is D2 really ready for production code? I often hear ppl
>> complaining about compiler bugs or regressions causing them to
>> drop D "for now". Is it true that D has GC problems?
>>
>> 2) Is there a way to start adding D code to a C++ projects? For
>> example build a dll in D that is loaded by C++ host app? I guess
>> that is not possible because of GC not being there?
>>
>> 3) Is it possible to use D on iOS?
>>
>> We will for sure switch to D eventually. Question is, when can we
>> start the transition so it would not fire back on us.
>
> 1a) no 1b) yes
> 2) no/yes (dll on windows - yes + pain, elsewhere - no)
> 3) no

That was fast :) Not thrilled about the answers to ;)

On Friday, 25 January 2013 at 20:50:22 UTC, Szymon wrote:
> That was fast :) Not thrilled about the answers to ;)
Well, I'd say application-level server side it is quite fine with one big OOPS: your company needs to be ready to spend certain time to maintain compiler yourself. In other words it is somewhat stable in sense it is not likely to meet broken code gen and is more than possible to code something neat. But you can't just take it and use it out of the box.

On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
> 1) Is D2 really ready for production code?

I use it and very rarely hit compiler bugs. Really depends what combination of features you use: I tend to stick to more conservative parts of the language, and have very few problems. Other people can't write ten lines without something going wrong though.

> Is it true that D has GC problems?

It is slow. If speed is a worry, you'll want to keep away. If not, it gets the job done well enough.

> 2) Is there a way to start adding D code to a C++ projects?

Yes. You'll need to expose parts of the D code as extern(C) or extern(C++) to interface with it, and remember to initialize the D  runtime.

This is something I did for a different thing (on Linux too, haven't tried on Windows) and it isn't really documented, but if you grab this zip:

http://arsdnet.net/dcode/dtocpp.zip

And check out testcpp.d and test.cpp, you can see some interaction. Notice that the main() function is in C++, and they are statically linked together. Functions, data, and even some classes (notice the extern(C++) interface in testcpp.d, which is inherited froma D class: Cat, and a C++ class, Dog) can interact between the two languages.

Indeed, in that zip is also a program called dtoh, which reads a json file generated by dmd, and outputs a C++ interface for it. The Makefile shows the commands, albeit assuming Linux.



Statically linking C++ and D on Windows 32 bit is a pain in the ass. You probably want to avoid that entirely. But doing a DLL isn't as bad... I've used C++ dlls from D exes before, but not the other way around. Still though, it should be doable and not terribly much different than the static example.

> 3) Is it possible to use D on iOS?

Not at this time.

>> 2) Is there a way to start adding D code to a C++ projects?
>
> Yes. You'll need to expose parts of the D code as extern(C) or extern(C++) to interface with it, and remember to initialize the D  runtime.
>

As he apparently is on Windows, you can only do this with a D DLL, which are likely to be a PITA (but at least they should work unlike on un*x); you can't really link D object files and C/C++ object files together, as on win32 OMF is used (you could use unilink, but that's so obscure I wouldn't expect a newbie to mess with this at all). So I'd take this as "no"

On Fri, 25 Jan 2013 21:45:21 +0100, Szymon wrote:

> Hi,
> 
> I would really like to start using D in our small company as a C++ replacement. With that in mind I do have few questions:
> 
> 1) Is D2 really ready for production code? I often hear ppl complaining about compiler bugs or regressions causing them to drop D "for now". Is it true that D has GC problems?
> 
> 2) Is there a way to start adding D code to a C++ projects? For example build a dll in D that is loaded by C++ host app? I guess that is not possible because of GC not being there?
> 
> 3) Is it possible to use D on iOS?
> 
> We will for sure switch to D eventually. Question is, when can we start the transition so it would not fire back on us.

I can only comment on the first set of questions:

1a) We use D for all of our high-performance production code (large economic models on a web server) and we are currently moving our big data processing to a D framework.

1b) Yes, there are some issues especially when it comes to the built-in AAs, but over all we haven't run into show stopper problems.

Jonathan

On Friday, 25 January 2013 at 21:07:00 UTC, q66 wrote:
>>> 2) Is there a way to start adding D code to a C++ projects?
>>
>> Yes. You'll need to expose parts of the D code as extern(C) or extern(C++) to interface with it, and remember to initialize the D  runtime.
>>
>
> As he apparently is on Windows, you can only do this with a D DLL, which are likely to be a PITA (but at least they should work unlike on un*x); you can't really link D object files and C/C++ object files together, as on win32 OMF is used (you could use unilink, but that's so obscure I wouldn't expect a newbie to mess with this at all). So I'd take this as "no"

you could theoretically use dmc/dmc++ to compile the rest, but that just asks for problems; you could also use GDC, which basically assumes MinGW as the C++ toolchain (though it might work with other compilers if done as a DLL) .. LLVM on Windows is still rather immature so LDC is not an option (SEH and so on)

On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
> Hi,
>
> I would really like to start using D in our small company as a
> C++ replacement. With that in mind I do have few questions:
>
> 1) Is D2 really ready for production code? I often hear ppl
> complaining about compiler bugs or regressions causing them to
> drop D "for now". Is it true that D has GC problems?

No. D compiler(s) has plenty of bugs and the language is not stable yet. You may encounter compiler errors when update to new version. And there is significant incentive to update, because each version fixes many bugs.

Standard library is not stable yet. Firstly, strictly speaking, there is no standard library. Phobos is a one, but it is extremely eclectic (contains many features which are not structured and certainly one day would be fixed). Secondly, some modules are deprecated, some modules are marked as "one day it would be fixed and you will not recognize it". Thirdly, inside modules declarations may significantly change across different versions.

D also has poor toolchain support: IDEs, editors, debuggers, etc.

D's GC does not have serious problems. The only issue is controversial status of GC.

If you are aware of codegen quality, you should take look at gdc or ldc, because dmd backend has poor optimizer and in general is worse.

> 2) Is there a way to start adding D code to a C++ projects? For
> example build a dll in D that is loaded by C++ host app? I guess
> that is not possible because of GC not being there?

Probably, but there are some problems. For example, dmd generates old object format on win32 which is not incompatible with almost anything on win32. Dynamic linking works only on linux and dynamic loading does not work on all platforms. However it is possible to write part of the application in D and link code to C++. Preferably it should be statically linked, or dynamically but without exposing D features (using extern(C) like C).

> 3) Is it possible to use D on iOS?

Likely no.

> We will for sure switch to D eventually. Question is, when can we
> start the transition so it would not fire back on us.

This will happen not soon.

> D's GC does not have serious problems. The only issue is controversial status of GC.
>

D's GC has inherent issues with false positives, sometimes freeing memory that you don't really want freed, causing (sometimes hidden) bugs that are pretty much impossible to debug.