www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Incorporating D

reply "Szymon" <noemail gmail.com> writes:
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.
Jan 25 2013
next sibling parent reply "q66" <quaker66 gmail.com> writes:
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
Jan 25 2013
next sibling parent reply "Szymon" <noemail gmail.com> writes:
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 ;)
Jan 25 2013
parent "mist" <none none.none> writes:
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.
Jan 25 2013
prev sibling parent reply "SomeDude" <lovelydear mailmetrash.com> writes:
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?
1a) no 1b) yes
AFAWK, at least one major videogames studio is writing its new title in D.
Jan 26 2013
parent reply FG <home fgda.pl> writes:
On 2013-01-26 20:55, SomeDude wrote:
 AFAWK, at least one major videogames studio is writing its new title in D.
For real? You must be joking. :)
Jan 26 2013
parent reply "mist" <none none.none> writes:
On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote:
 On 2013-01-26 20:55, SomeDude wrote:
 AFAWK, at least one major videogames studio is writing its new 
 title in D.
For real? You must be joking. :)
Tsss, it is a secret ;)
Jan 26 2013
parent reply "Szymon" <noemail gmail.com> writes:
On Saturday, 26 January 2013 at 21:30:22 UTC, mist wrote:
 On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote:
 On 2013-01-26 20:55, SomeDude wrote:
 AFAWK, at least one major videogames studio is writing its 
 new title in D.
For real? You must be joking. :)
Tsss, it is a secret ;)
We actually are video game company ;) That is why D seems like perfect choice for future language. Native code + superb programmer productivity + fast compile times. If D was bit more mature decision would be dead simple.
Jan 28 2013
next sibling parent reply "eles" <eles eles.com> writes:
On Monday, 28 January 2013 at 12:04:42 UTC, Szymon wrote:
 On Saturday, 26 January 2013 at 21:30:22 UTC, mist wrote:
 On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote:
 On 2013-01-26 20:55, SomeDude wrote:
We actually are video game company ;) That is why D seems like perfect choice for future language. Native code + superb programmer productivity + fast compile times. If D was bit more mature decision would be dead simple.
Well, let's hope it becomes mature enough. My impression is that it needs to clean up itself a bit, to remove several ambiguities (that property discussion...) that lasted far too long to bring any good, and to work heavily on tools: the compiler. Otherwise, I think it is OK to start with it. Custom runtimes/libraries could provide GC-free implementation where needed (BSPs, games). Not wanting to sadden anyone, but the main effort in tools should be, my feeling, directed at gdc/gcc. It will help a lot to having D a good-quality "gcc-standard" language. Then, Eclipse/DDT with debugging and what else it is missing. Then... happy coding.
Jan 28 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.01.2013 16:11, schrieb eles:
 On Monday, 28 January 2013 at 12:04:42 UTC, Szymon wrote:
 On Saturday, 26 January 2013 at 21:30:22 UTC, mist wrote:
 On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote:
 On 2013-01-26 20:55, SomeDude wrote:
We actually are video game company ;) That is why D seems like perfect choice for future language. Native code + superb programmer productivity + fast compile times. If D was bit more mature decision would be dead simple.
Well, let's hope it becomes mature enough. My impression is that it needs to clean up itself a bit, to remove several ambiguities (that property discussion...) that lasted far too long to bring any good, and to work heavily on tools: the compiler. Otherwise, I think it is OK to start with it. Custom runtimes/libraries could provide GC-free implementation where needed (BSPs, games).
I have a post-mortem of Witcher 2 for the XBox 360 sitting on my desk explaining how they made use of a GC for the game...
Jan 28 2013
parent reply "Szymon" <noemail gmail.com> writes:
On Monday, 28 January 2013 at 16:28:51 UTC, Paulo Pinto wrote:
 I have a post-mortem of Witcher 2 for the XBox 360 sitting on 
 my desk explaining how they made use of a GC for the game...
That is something confidential I assume...?
Jan 28 2013
parent Paulo Pinto <pjmlp progtools.org> writes:
Am 28.01.2013 18:03, schrieb Szymon:
 On Monday, 28 January 2013 at 16:28:51 UTC, Paulo Pinto wrote:
 I have a post-mortem of Witcher 2 for the XBox 360 sitting on my desk
 explaining how they made use of a GC for the game...
That is something confidential I assume...?
No, quite public. An article on the "Making Games Magazine". The Magazine of the German games development community. http://tinyurl.com/bjxxp5f -- Paulo
Jan 28 2013
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 28 January 2013 at 12:04:42 UTC, Szymon wrote:
 On Saturday, 26 January 2013 at 21:30:22 UTC, mist wrote:
 On Saturday, 26 January 2013 at 20:54:30 UTC, FG wrote:
 On 2013-01-26 20:55, SomeDude wrote:
 AFAWK, at least one major videogames studio is writing its 
 new title in D.
For real? You must be joking. :)
Tsss, it is a secret ;)
We actually are video game company ;) That is why D seems like perfect choice for future language. Native code + superb programmer productivity + fast compile times. If D was bit more mature decision would be dead simple.
I believe that if you stick with a particular version of the compiler + druntime + phobos then you could use D now. If you treat it as a nicer c++ and don't branch out in to the more exotic features, I'd expect a pretty smooth ride.
Jan 28 2013
prev sibling next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
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.
Jan 25 2013
parent reply "q66" <quaker66 gmail.com> writes:
 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"
Jan 25 2013
next sibling parent "q66" <quaker66 gmail.com> writes:
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)
Jan 25 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2013 1:06 PM, q66 wrote:
 As he apparently is on Windows, you can only do this with a D DLL,
Not true. Nothing says you have to use a 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 win32, if your C++ code is compiled with DMC++, you can link them together. On Win64, you can link in code compiled with VC++.
Jan 25 2013
prev sibling parent "jerro" <a a.com> writes:
 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
Couldn't you work around that by compiling your D code with GDC/MinGW and the C++ code with MinGW?
Jan 26 2013
prev sibling next sibling parent Jonathan Crapuchettes <jcrapuchettes gmail.com> writes:
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
Jan 25 2013
prev sibling next sibling parent reply "Maxim Fomin" <maxim maxim-fomin.ru> writes:
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.
Jan 25 2013
parent reply "q66" <quaker66 gmail.com> writes:
 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.
Jan 25 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 10:33 PM, q66 wrote:
 D's GC does not have serious problems. The only issue is controversial
 status of GC.
D's GC has inherent issues
Certainly not. Maybe druntime's GC does.
 with false positives, sometimes freeing
 memory that you don't really want freed, causing (sometimes hidden) bugs
 that are pretty much impossible to debug.
I have never experienced such. That would be a serious bug. What's the bug report?
Jan 25 2013
prev sibling next sibling parent "Maxim Fomin" <maxim maxim-fomin.ru> writes:
On Friday, 25 January 2013 at 21:33:15 UTC, q66 wrote:
 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.
Examples (especially with false positives) are appreciated.
Jan 25 2013
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, January 25, 2013 22:33:14 q66 wrote:
 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.
I've _never_ heard of it freeing something when it shouldn't. The main problem with false positives is that because it's conservative, on 32-bit systems, it will sometimes think that a block of memory contains a pointer when it doesn't (and therefore won't free the memory that it incorrectly thinks is being pointed to). But 64-bit fixes that. Regardless, a new GC is in the works, so the situation is going to improve. - Jonathan M Davis
Jan 25 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Fri, 25 Jan 2013 22:38:51 +0100
schrieb "Jonathan M Davis" <jmdavisProg gmx.com>:

 On Friday, January 25, 2013 22:33:14 q66 wrote:
 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.
I've _never_ heard of it freeing something when it shouldn't.
I've seen that when porting GDC. Usually happens if the GC fails to scan the stack or more often it misses some TLS ranges. Never saw that with dmd though. IIRC toStringz is also dangerous. You have to make sure that the C library does not store the pointer or also store it manually so the GC can find it. (This is not different from passing other C/D pointers, but with toStringz it's easy to miss).
Jan 26 2013
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2013 1:41 AM, Johannes Pfau wrote:
 IIRC toStringz is also dangerous. You have to make sure that the C
 library does not store the pointer or also store it manually so the GC
 can find it. (This is not different from passing other C/D pointers, but
 with toStringz it's easy to miss).
That's not a bug in the GC, though.
Jan 26 2013
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Saturday, January 26, 2013 10:41:46 Johannes Pfau wrote:
 Am Fri, 25 Jan 2013 22:38:51 +0100
 
 schrieb "Jonathan M Davis" <jmdavisProg gmx.com>:
 On Friday, January 25, 2013 22:33:14 q66 wrote:
 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.
I've _never_ heard of it freeing something when it shouldn't.
I've seen that when porting GDC. Usually happens if the GC fails to scan the stack or more often it misses some TLS ranges. Never saw that with dmd though. IIRC toStringz is also dangerous. You have to make sure that the C library does not store the pointer or also store it manually so the GC can find it. (This is not different from passing other C/D pointers, but with toStringz it's easy to miss).
Which is why the toStringz documentation points that out. The GC can only see what's referred to in the D code, not C code, so you have to make sure that the D code retains a reference to any pointers passed into C code or risk the GC thinking that it's okay to free it. But there really isn't any way around that, and it's completely different from the GC incorrectly thinking that a pointer was not referenced anywhere in D code and freeing it. - Jonathan M Davis
Jan 26 2013
parent reply Johannes Pfau <nospam example.com> writes:
Am Sat, 26 Jan 2013 02:19:02 -0800
schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 
 IIRC toStringz is also dangerous. You have to make sure that the C
 library does not store the pointer or also store it manually so the
 GC can find it. (This is not different from passing other C/D
 pointers, but with toStringz it's easy to miss).
Which is why the toStringz documentation points that out. The GC can only see what's referred to in the D code, not C code, so you have to make sure that the D code retains a reference to any pointers passed into C code or risk the GC thinking that it's okay to free it. But there really isn't any way around that, and it's completely different from the GC incorrectly thinking that a pointer was not referenced anywhere in D code and freeing it. - Jonathan M Davis
Yes, I just wanted to point out a common source for such bugs, it's not the GC's fault. It's great that the documentation of toStringz mentions that issue. What I meant is most of the time we use toStringz() like this: string str; c_function(str.toStringz()); This is only valid if c_function doesn't store the pointer, but newbies might miss that and just copy this nice looking example code for other c functions. There's nothing we can do about that though, interfacing to C just is a little bit dangerous.
Jan 26 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.01.2013 11:40, Johannes Pfau wrote:
 Yes, I just wanted to point out a common source for such bugs, it's not
 the GC's fault. It's great that the documentation of toStringz mentions
 that issue. What I meant is most of the time we use toStringz() like
 this:

 string str;
 c_function(str.toStringz());

 This is only valid if c_function doesn't store the pointer, but newbies
 might miss that and just copy this nice looking example code for other
 c functions. There's nothing we can do about that though, interfacing
 to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that function call, but copied elsewhere in the C heap and cleared on the stack: struct param_struct { const char* name; }; void c_function(const char*p) { param_struct* ps = new param_struct; ps->name = p; p = 0; doSomething(ps); delete ps; } Imagine a garbage collection while executing doSomething...
Jan 26 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze 
wrote:
 On 26.01.2013 11:40, Johannes Pfau wrote:
 Yes, I just wanted to point out a common source for such bugs, 
 it's not
 the GC's fault. It's great that the documentation of toStringz 
 mentions
 that issue. What I meant is most of the time we use 
 toStringz() like
 this:

 string str;
 c_function(str.toStringz());

 This is only valid if c_function doesn't store the pointer, 
 but newbies
 might miss that and just copy this nice looking example code 
 for other
 c functions. There's nothing we can do about that though, 
 interfacing
 to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that function call, but copied elsewhere in the C heap and cleared on the stack: struct param_struct { const char* name; }; void c_function(const char*p) { param_struct* ps = new param_struct; ps->name = p; p = 0; doSomething(ps); delete ps; } Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the stack anyway.
Jan 26 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.01.2013 16:53, deadalnix wrote:
 On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
 On 26.01.2013 11:40, Johannes Pfau wrote:
 Yes, I just wanted to point out a common source for such bugs, it's not
 the GC's fault. It's great that the documentation of toStringz mentions
 that issue. What I meant is most of the time we use toStringz() like
 this:

 string str;
 c_function(str.toStringz());

 This is only valid if c_function doesn't store the pointer, but newbies
 might miss that and just copy this nice looking example code for other
 c functions. There's nothing we can do about that though, interfacing
 to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that function call, but copied elsewhere in the C heap and cleared on the stack: struct param_struct { const char* name; }; void c_function(const char*p) { param_struct* ps = new param_struct; ps->name = p; p = 0; doSomething(ps); delete ps; } Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the stack anyway.
"p = 0;" clears the only existing reference on the stack.
Jan 26 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2013 8:17 AM, Rainer Schuetze wrote:
 On 26.01.2013 16:53, deadalnix wrote:
 On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
 On 26.01.2013 11:40, Johannes Pfau wrote:
 Yes, I just wanted to point out a common source for such bugs, it's not
 the GC's fault. It's great that the documentation of toStringz mentions
 that issue. What I meant is most of the time we use toStringz() like
 this:

 string str;
 c_function(str.toStringz());

 This is only valid if c_function doesn't store the pointer, but newbies
 might miss that and just copy this nice looking example code for other
 c functions. There's nothing we can do about that though, interfacing
 to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that function call, but copied elsewhere in the C heap and cleared on the stack: struct param_struct { const char* name; }; void c_function(const char*p) { param_struct* ps = new param_struct; ps->name = p; p = 0; doSomething(ps); delete ps; } Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the stack anyway.
"p = 0;" clears the only existing reference on the stack.
No, because ps is on the stack, and ps points to a copy of p. Hence, that code snippet is GC safe.
Jan 26 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 26.01.2013 21:13, Walter Bright wrote:
 On 1/26/2013 8:17 AM, Rainer Schuetze wrote:
 On 26.01.2013 16:53, deadalnix wrote:
 On Saturday, 26 January 2013 at 10:52:59 UTC, Rainer Schuetze wrote:
 On 26.01.2013 11:40, Johannes Pfau wrote:
 Yes, I just wanted to point out a common source for such bugs, it's
 not
 the GC's fault. It's great that the documentation of toStringz
 mentions
 that issue. What I meant is most of the time we use toStringz() like
 this:

 string str;
 c_function(str.toStringz());

 This is only valid if c_function doesn't store the pointer, but
 newbies
 might miss that and just copy this nice looking example code for other
 c functions. There's nothing we can do about that though, interfacing
 to C just is a little bit dangerous.
It is even dangerous if it is only used temporarily during that function call, but copied elsewhere in the C heap and cleared on the stack: struct param_struct { const char* name; }; void c_function(const char*p) { param_struct* ps = new param_struct; ps->name = p; p = 0; doSomething(ps); delete ps; } Imagine a garbage collection while executing doSomething...
That isn't an issue as the pointer will e found at upper level in the stack anyway.
"p = 0;" clears the only existing reference on the stack.
No, because ps is on the stack, and ps points to a copy of p. Hence, that code snippet is GC safe.
Please note that c_function is C/C++ code. The struct is allocated on the C heap, not in GC memory. "p = 0" clears the only reference in GC scanned memory to the char array allocated and returned by toStringz().
Jan 26 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/26/2013 12:44 PM, Rainer Schuetze wrote:
 Please note that c_function is C/C++ code. The struct is allocated on the C
 heap, not in GC memory. "p = 0" clears the only reference in GC scanned memory
 to the char array allocated and returned by toStringz().
Oh, I see what you mean. You're right.
Jan 26 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2013 1:33 PM, q66 wrote:
 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.
There are zero reported examples of this happening. I believe you have this confused with the GC being a conservative collector, where it will sometimes not free memory that it could free. This is not a bug.
Jan 25 2013
parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 23:02:10 UTC, Walter Bright wrote:
 On 1/25/2013 1:33 PM, q66 wrote:
 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.
There are zero reported examples of this happening.
I had an issue like like in D < 2.061 .
Jan 25 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 25 January 2013 at 21:33:15 UTC, q66 wrote:
 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.
That is very wrong. False positive are the exact opposite : memory that isn't freed. And it statistically never occurs on 64 bits systems.
Jan 25 2013
prev sibling next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
Jan 25 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 10:39 PM, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster.
No. Also, it is not stopping production use at all.
 But there are plenty of other missing features.
It is not really clear what this is supposed to mean.
Jan 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 25 January 2013 at 21:50:22 UTC, Timon Gehr wrote:
 On 01/25/2013 10:39 PM, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster.
No. Also, it is not stopping production use at all.
No? Still, that's the fact and it doesn't matter whether you agree or not. You don't use structs as many as I do I think. And I'm not saying that it is stopping production at all. I'm saying that D is far away from productive usage and that the missing rvalue ref is a big pain.
Jan 25 2013
parent reply "Szymon" <noemail gmail.com> writes:
In C++ rv-refs do not help with structs (PODs). Do you mean D has 
no refs / pointers for struct passing?

On Friday, 25 January 2013 at 22:13:25 UTC, Namespace wrote:
 On Friday, 25 January 2013 at 21:50:22 UTC, Timon Gehr wrote:
 On 01/25/2013 10:39 PM, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster.
No. Also, it is not stopping production use at all.
No? Still, that's the fact and it doesn't matter whether you agree or not. You don't use structs as many as I do I think. And I'm not saying that it is stopping production at all. I'm saying that D is far away from productive usage and that the missing rvalue ref is a big pain.
Jan 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 25 January 2013 at 22:16:11 UTC, Szymon wrote:
 In C++ rv-refs do not help with structs (PODs). Do you mean D 
 has no refs / pointers for struct passing?
I meant that we have nothing comparable with const&. const& int C++ accept both, lvalues and rvalues. If it is an lvalue it is taken by reference and isn't copied.
Jan 25 2013
next sibling parent reply "Szymon" <noemail gmail.com> writes:
So structs in D are always passed by-value? That is unfortunate...

On Friday, 25 January 2013 at 22:20:32 UTC, Namespace wrote:
 On Friday, 25 January 2013 at 22:16:11 UTC, Szymon wrote:
 In C++ rv-refs do not help with structs (PODs). Do you mean D 
 has no refs / pointers for struct passing?
I meant that we have nothing comparable with const&. const& int C++ accept both, lvalues and rvalues. If it is an lvalue it is taken by reference and isn't copied.
Jan 25 2013
next sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 01/25/2013 11:22 PM, Szymon wrote:
 So structs in D are always passed by-value?
No.
 That is unfortunate...
Jan 25 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
 So structs in D are always passed by-value? That is 
 unfortunate...

 On Friday, 25 January 2013 at 22:20:32 UTC, Namespace wrote:
 On Friday, 25 January 2013 at 22:16:11 UTC, Szymon wrote:
 In C++ rv-refs do not help with structs (PODs). Do you mean D 
 has no refs / pointers for struct passing?
I meant that we have nothing comparable with const&. const& int C++ accept both, lvalues and rvalues. If it is an lvalue it is taken by reference and isn't copied.
Not if you pass them as ref. struct A { } void foo(ref A a) { } Now foo takes A's by reference. But _only_ lvalues: A a; foo(a); So this is (currently) not possible: foo(A());
Jan 25 2013
prev sibling next sibling parent "mist" <none none.none> writes:
On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
 So structs in D are always passed by-value? That is 
 unfortunate...
No, that is what he speaks about: -------- struct SomeStruct { int a, b; } void f1(ref SomeStruct input) { } void f2(const ref SomeStruct input) { } void main() { SomeStruct a; f1(a); // fine f2(a); // fine // f1(SomeStruct(0,0)); // invalid, predictable // f2(SomeStruct(0,0)); // invalid, surprise to C++ guys } --------
Jan 25 2013
prev sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
 So structs in D are always passed by-value? That is 
 unfortunate...
It has both pointers and ref but they both only work with lvalues, regardless of const: struct S {} void test(const ref S s) {} void test2(const S* s) {} S getS() { return S(); } void main() { S s; test(s); // ok test2(&s); // ok test(getS()); // not ok (line 12) test2(&getS()); // not ok (line 13) } test.d(12): Error: function test.test (ref const(S) s) is not callable using argument types (S) test.d(12): Error: getS() is not an lvalue test.d(13): Error: getS() is not an lvalue
Jan 25 2013
next sibling parent reply "Adam D. Ruppe" <destructionator gmail.com> writes:
LOL 3 of us said the same thing at the same time!
Jan 25 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 25 January 2013 at 22:30:46 UTC, Adam D. Ruppe wrote:
 LOL 3 of us said the same thing at the same time!
And everytime the example was more detailed. :)
Jan 25 2013
prev sibling next sibling parent reply "Szymon" <noemail gmail.com> writes:
Ah, perfectly clear now. Thanks guys. At one point I though maybe 
it was about move semantics but it indeed about something much 
more fundamental. And indeed surprising coming from C++.


On Friday, 25 January 2013 at 22:29:44 UTC, Adam D. Ruppe wrote:
 On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
 So structs in D are always passed by-value? That is 
 unfortunate...
It has both pointers and ref but they both only work with lvalues, regardless of const: struct S {} void test(const ref S s) {} void test2(const S* s) {} S getS() { return S(); } void main() { S s; test(s); // ok test2(&s); // ok test(getS()); // not ok (line 12) test2(&getS()); // not ok (line 13) } test.d(12): Error: function test.test (ref const(S) s) is not callable using argument types (S) test.d(12): Error: getS() is not an lvalue test.d(13): Error: getS() is not an lvalue
Jan 25 2013
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 25, 2013 at 11:32:19PM +0100, Szymon wrote:
 Ah, perfectly clear now. Thanks guys. At one point I though maybe it
 was about move semantics but it indeed about something much more
 fundamental. And indeed surprising coming from C++.
[...] When moving to D, one thing to keep in mind is that you should not expect C/C++ struct and D struct to behave the same way, because they do not. In D, a struct is a value type, and basically behaves like a glorified int. This means assignment with = (shallow-)copies the struct, structs are allocated on the stack by default (unless you explicitly use new), etc.. Be aware that using struct ctors/dtors is fraught with peril; the simplest cases do work, but there are some bugs with complicated dtors and some unexpected behaviour with disable ctors. If you need a complicated dtor, chances are you want to be using a class anyway. Same goes for postblit ctors (the analogue of copy ctors): there are some bugs related to this, and IMO, if you need to do complicated stuff in a postblit, you should just use a class. In D, a class is a reference type, which means they are always passed by reference, and assignment with = only copies the reference, NOT the object. By default, they are allocated on the heap (unless you use emplace), and generally, ctors and dtors work in a much more predictable and stable way. (But be aware that dtors may not run when you expect, because the GC may not collect the object immediately after it's out of use.) Class objects are not deep-copied unless you provide a method to do that yourself. In summary, if you want something that behaves like an int, but just happens to have a couple of extra fields, use a struct. If you want complex behaviours like ctors, dtors, copy/cloning semantics, polymorphism, etc., spare yourself the pain and just use a class. (It *is* possible to pull some tricks along these lines with structs, but like I said, there is a risk of running into some bugs in that area, so it's best to steer clear until these issues have been fixed.) T -- "I suspect the best way to deal with procrastination is to put off the procrastination itself until later. I've been meaning to try this, but haven't gotten around to it yet. " -- swr
Jan 25 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Jan-2013 04:42, H. S. Teoh пишет:
 On Fri, Jan 25, 2013 at 11:32:19PM +0100, Szymon wrote:
 Ah, perfectly clear now. Thanks guys. At one point I though maybe it
 was about move semantics but it indeed about something much more
 fundamental. And indeed surprising coming from C++.
[...] When moving to D, one thing to keep in mind is that you should not expect C/C++ struct and D struct to behave the same way, because they do not. In D, a struct is a value type, and basically behaves like a glorified int. This means assignment with = (shallow-)copies the struct, structs are allocated on the stack by default (unless you explicitly use new), etc.. Be aware that using struct ctors/dtors is fraught with peril; the simplest cases do work, but there are some bugs with complicated dtors and some unexpected behaviour with disable ctors. If you need a complicated dtor, chances are you want to be using a class anyway. Same goes for postblit ctors (the analogue of copy ctors): there are some bugs related to this, and IMO, if you need to do complicated stuff in a postblit, you should just use a class.
In general postblit/dtor are working but I wouldn't recommend using them in complex code (least you want to file a bug report) like with statements, or array-literals [ Struct(...), Struct(...), Struct(...)], and of course built-in associative arrays(!). Another thing of importance is that pass-by-value is automated to move (simple bitwise-copy) where applicable as D structs can't have internal references. And you don't have to define move constructor or rely on sombody to define it.
 In D, a class is a reference type, which means they are always passed by
 reference, and assignment with = only copies the reference, NOT the
 object. By default, they are allocated on the heap (unless you use
 emplace), and generally, ctors and dtors work in a much more predictable
 and stable way. (But be aware that dtors may not run when you expect,
 because the GC may not collect the object immediately after it's out of
 use.) Class objects are not deep-copied unless you provide a method to
 do that yourself.

 In summary, if you want something that behaves like an int, but just
 happens to have a couple of extra fields, use a struct. If you want
 complex behaviours like ctors, dtors, copy/cloning semantics,
 polymorphism, etc., spare yourself the pain and just use a class. (It
 *is* possible to pull some tricks along these lines with structs, but
 like I said, there is a risk of running into some bugs in that area, so
 it's best to steer clear until these issues have been fixed.)


 T
-- Dmitry Olshansky
Jan 26 2013
prev sibling parent reply "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 22:29:44 UTC, Adam D. Ruppe wrote:
 On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
 So structs in D are always passed by-value? That is 
 unfortunate...
It has both pointers and ref but they both only work with lvalues, regardless of const: struct S {} void test(const ref S s) {} void test2(const S* s) {} S getS() { return S(); } void main() { S s; test(s); // ok test2(&s); // ok test(getS()); // not ok (line 12) test2(&getS()); // not ok (line 13) } test.d(12): Error: function test.test (ref const(S) s) is not callable using argument types (S) test.d(12): Error: getS() is not an lvalue test.d(13): Error: getS() is not an lvalue
It should be mentioned that there's a solution of sorts, but it is a pain to have to do and does not scale up when you have multiple ref arguments. void test(const ref S s) { // implementation ... return; } void test(const S s) { test( s ); // calls test(const ref S s) return; } --rt
Jan 25 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
26-Jan-2013 03:48, Rob T пишет:
 On Friday, 25 January 2013 at 22:29:44 UTC, Adam D. Ruppe wrote:
 On Friday, 25 January 2013 at 22:22:44 UTC, Szymon wrote:
 So structs in D are always passed by-value? That is unfortunate...
It has both pointers and ref but they both only work with lvalues, regardless of const: struct S {} void test(const ref S s) {} void test2(const S* s) {} S getS() { return S(); } void main() { S s; test(s); // ok test2(&s); // ok test(getS()); // not ok (line 12) test2(&getS()); // not ok (line 13) } test.d(12): Error: function test.test (ref const(S) s) is not callable using argument types (S) test.d(12): Error: getS() is not an lvalue test.d(13): Error: getS() is not an lvalue
It should be mentioned that there's a solution of sorts, but it is a pain to have to do and does not scale up when you have multiple ref arguments. void test(const ref S s) { // implementation ... return; } void test(const S s) { test( s ); // calls test(const ref S s) return; }
void test(const S s){ return test(s); } D is not Java and allows returning void functions directly ;) -- Dmitry Olshansky
Jan 26 2013
prev sibling parent "Namespace" <rswhite4 googlemail.com> writes:
And yes, I meant of course D structs and that D has nothing to 
receive these as rvalue _and_ rvalue. Sorry for confusing you.
Jan 25 2013
prev sibling next sibling parent reply "Rob T" <alanb ucora.com> writes:
On Friday, 25 January 2013 at 21:39:58 UTC, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
Yes, the ref issue can be a pain, but it's not even close to a show stopper for production use. C++ has by far worse limitations, such as an almost unusable template implementation, and that's just the start of it. D does not really lack much at all in terms of language features, but one of the main features D lacks on the tool chain side is full shared library support. I really think this needs to be shored up because not only is shared library support is essential on it's own, it's also a safe means for people to start migrating from C++ to D by incorporating D libraries into their existing C++ code. The other thing is the GC which is also tool chain related. We could use a better implementation, but existing one is definitely not a show stopper for production use, and there are ways to deal with any performance issues that may appear, you just need to be aware of potential slowness problems if you are doing a lot of memory allocations and/or real time programming. Finally there are editors, and IDE's with decent D support. In fact I find that C++ IDE and editor support is no better, and fails often due to the near impossible nature of correctly parsing through C++ code. --rt
Jan 25 2013
next sibling parent reply "Szymon" <noemail gmail.com> writes:
On Friday, 25 January 2013 at 22:00:02 UTC, Rob T wrote:
 On Friday, 25 January 2013 at 21:39:58 UTC, Namespace 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:
Wow, I may not fully like D after all those comments but I do certainly like its community :) You are as fast as this forums loading times. I actually played a bit with D in Visual Studio with VisualD and it was rather pleasant experience. I don't know why but release build crashed while debug run fine that is why I turned here with questions. I am definitely looking forward to D being more mature. And wish I could get to DConf (which I backed!) but it is bit too far ;) Thanks for all the answers!
Jan 25 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 5:07 PM, Szymon wrote:
 On Friday, 25 January 2013 at 22:00:02 UTC, Rob T wrote:
 On Friday, 25 January 2013 at 21:39:58 UTC, Namespace 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:
Wow, I may not fully like D after all those comments but I do certainly like its community :) You are as fast as this forums loading times. I actually played a bit with D in Visual Studio with VisualD and it was rather pleasant experience. I don't know why but release build crashed while debug run fine that is why I turned here with questions. I am definitely looking forward to D being more mature. And wish I could get to DConf (which I backed!) but it is bit too far ;) Thanks for all the answers!
Thank you for asking. We have been strongly focused on quality improvement since last year but judging from this thread we need to work more on it (and the derived community sentiment). Andrei
Jan 25 2013
parent reply "Oleg Kuporosov" <Oleg.Kuporosov gmail.com> writes:
On Friday, 25 January 2013 at 23:24:54 UTC, Andrei Alexandrescu 
wrote:

 Thank you for asking. We have been strongly focused on quality 
 improvement since last year but judging from this thread we 
 need to work more on it (and the derived community sentiment).

 Andrei
And that is true, during 2012 and by now 1495 bug fixed and closed: http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2012-01-01&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&component=DMD&product=D That is just so Awesome! Great thanks to everybody involved! The bad news is there are still some TDPL bugs: http://d.puremagic.com/issues/buglist.cgi?keywords=tdpl&query_format=advanced&keywords_type=allwords&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=DMD&product=D These probably would require more attention because TDPL is the _only_ printed source of the language. Not so big amount although, so using D per TDPL looks pretty safe. Oleg.
Jan 26 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/13 4:23 AM, Oleg Kuporosov wrote:
 On Friday, 25 January 2013 at 23:24:54 UTC, Andrei Alexandrescu wrote:

 Thank you for asking. We have been strongly focused on quality
 improvement since last year but judging from this thread we need to
 work more on it (and the derived community sentiment).

 Andrei
And that is true, during 2012 and by now 1495 bug fixed and closed: http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2012-01-01&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&component=DMD&product=D That is just so Awesome! Great thanks to everybody involved! The bad news is there are still some TDPL bugs: http://d.puremagic.com/issues/buglist.cgi?keywords=tdpl&query_format=advanced&keywords_type=allwords&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&component=DMD&product=D These probably would require more attention because TDPL is the _only_ printed source of the language. Not so big amount although, so using D per TDPL looks pretty safe.
Also, http://dlang.org/bugstats suggests (red line) a downward trend of bugs reported and unfixed. I also played a bit with the chart generator and plotted open vs. resolved bugs for the past 365 days: http://goo.gl/OX9bo. It seems we're consistently reducing net opened issues since November. Andrei
Jan 26 2013
parent reply "Rob T" <alanb ucora.com> writes:
On Saturday, 26 January 2013 at 14:41:20 UTC, Andrei Alexandrescu 
wrote:
 Also, http://dlang.org/bugstats suggests (red line) a downward 
 trend of bugs reported and unfixed. I also played a bit with 
 the chart generator and plotted open vs. resolved bugs for the 
 past 365 days: http://goo.gl/OX9bo. It seems we're consistently 
 reducing net opened issues since November.

 Andrei
For comparison, I wonder what the situation is for the various major implementations of C++11. Anyone know? --rt
Jan 26 2013
parent reply "Freddie Chopin" <freddie_chopin op.pl> writes:
On Saturday, 26 January 2013 at 22:16:09 UTC, Rob T wrote:
 For comparison, I wonder what the situation is for the various 
 major implementations of C++11. Anyone know?
You're looking for something like this? http://gcc.gnu.org/projects/cxx0x.html 4\/3!!
Jan 27 2013
parent "Rob T" <alanb ucora.com> writes:
On Sunday, 27 January 2013 at 08:49:39 UTC, Freddie Chopin wrote:
 On Saturday, 26 January 2013 at 22:16:09 UTC, Rob T wrote:
 For comparison, I wonder what the situation is for the various 
 major implementations of C++11. Anyone know?
You're looking for something like this? http://gcc.gnu.org/projects/cxx0x.html 4\/3!!
More like this. http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=--- Those are bugs listed for C++ front end only. --rt
Jan 28 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Friday, 25 January 2013 at 22:00:02 UTC, Rob T wrote:

 Finally there are editors, and IDE's with decent D support. In 
 fact I find that C++ IDE and editor support is no better, and 
 fails often due to the near impossible nature of correctly 
 parsing through C++ code.

 --rt
Come on, Visual C++ is awesome on code completion! But I have to admit, mono-d does a good job (as I am using ubuntu).
Jan 25 2013
prev sibling next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
 Yes, the ref issue can be a pain, but it's not even close to a 
 show stopper for production use. C++ has by far worse 
 limitations, such as an almost unusable template 
 implementation, and that's just the start of it.
I agree. However, there remains the fact that the lack of an rvalue ref hurts. Nothing else I said. :)
Jan 25 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 23:00, Rob T wrote:

 In fact I find that C++ IDE and editor support is no better, and fails often
due
 to the near impossible nature of correctly parsing through C++ code.
I think Xcode on Mac OS X is really good. It uses Clang for parsing the code, so if the IDE can't parse the code the compiler can't either. -- /Jacob Carlborg
Jan 26 2013
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 4:39 PM, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
I have discussed a few possible designs at http://d.puremagic.com/issues/show_bug.cgi?id=9238. I actually have in mind a design that I'd choose, but haven't had the time to write it. What other features are you referring to? Andrei
Jan 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Friday, 25 January 2013 at 23:16:09 UTC, Andrei Alexandrescu 
wrote:
 On 1/25/13 4:39 PM, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
I have discussed a few possible designs at http://d.puremagic.com/issues/show_bug.cgi?id=9238. I actually have in mind a design that I'd choose, but haven't had the time to write it.
The choosen syntax was "auto ref". There is still a Pull which waits for completeness and merging It hurts this much because this issue is dicussed since a year and there is still no implemented solution. structs are now lvalues, so this error is fixed, but the rvalue ref is still missing. So struct usage is more unhandy as anytime before.
 What other features are you referring to?
Oh I have a list, but the auto ref problem is my most favorite of missing features. Another example would be the scope storage class (and with it also "in").
Jan 25 2013
next sibling parent "Namespace" <rswhite4 googlemail.com> writes:
structs are now lvalues => structs are now rvalues.
Jan 25 2013
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/13 6:53 PM, Namespace wrote:
 On Friday, 25 January 2013 at 23:16:09 UTC, Andrei Alexandrescu wrote:
 On 1/25/13 4:39 PM, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
I have discussed a few possible designs at http://d.puremagic.com/issues/show_bug.cgi?id=9238. I actually have in mind a design that I'd choose, but haven't had the time to write it.
The choosen syntax was "auto ref". It hurts this much because this issue is dicussed since a year and there is still no implemented solution. structs are now lvalues, so this error is fixed, but the rvalue ref is still missing. So struct usage is more unhandy as anytime before.
We better get this right and not hurry about this.
 What other features are you referring to?
Oh I have a list, but the auto ref problem is my most favorite of missing features. Another example would be the scope storage class (and with it also "in").
What languages have that feature, and what makes it important? To me it seems rather niche and is easily worked around within the language. Andrei
Jan 25 2013
parent reply "Namespace" <rswhite4 googlemail.com> writes:
 We better get this right and not hurry about this.
I will open a new, separate thread about this tomorrow. Seems to me more appropriate. Then we can discuss about this important but missing feature in detail.
 What languages have that feature, and what makes it important? 
 To me it seems rather niche and is easily worked around within 
 the language.


 Andrei
Sorry I was tired and had misunderstood the relation to D problems which keep you back from using it in production. I will write a few sentences about this tomorrow.
Jan 25 2013
parent "Namespace" <rswhite4 googlemail.com> writes:
On Saturday, 26 January 2013 at 02:51:41 UTC, Namespace wrote:
 We better get this right and not hurry about this.
I will open a new, separate thread about this tomorrow. Seems to me more appropriate. Then we can discuss about this important but missing feature in detail.
http://forum.dlang.org/thread/nirfuenixutsbgyrcsla forum.dlang.org#post-nirfuenixutsbgyrcsla:40forum.dlang.org
Jan 26 2013
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
On Friday, 25 January 2013 at 21:39:58 UTC, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
Java has far less features than D, including what you complain about, yet it is considered a pretty productive programming language...
Jan 28 2013
next sibling parent reply "Namespace" <rswhite4 googlemail.com> writes:
On Monday, 28 January 2013 at 15:15:38 UTC, Dejan Lekic wrote:
 On Friday, 25 January 2013 at 21:39:58 UTC, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
Java has far less features than D, including what you complain about, yet it is considered a pretty productive programming language...
I hate to programming in Java because of the many many missing features. And because _all_ is stored on the heap. Java is IMO only good (if any) for learning programming but nothing else. But don't let us start a flame war about programming languages. ;)
Jan 28 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.01.2013 16:22, schrieb Namespace:
 On Monday, 28 January 2013 at 15:15:38 UTC, Dejan Lekic wrote:
 On Friday, 25 January 2013 at 21:39:58 UTC, Namespace 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?
Not really. A big pain in the ass is the missing rvalue ref that C++ has. So using structs is a big disaster. But there are plenty of other missing features.
Java has far less features than D, including what you complain about, yet it is considered a pretty productive programming language...
I hate to programming in Java because of the many many missing features. And because _all_ is stored on the heap. ...
This is not true for current native compilers and JVMs. If escape analysis can prove the object does not leave scope, new actually allocates on the stack. -- Paulo
Jan 28 2013
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 28 January 2013 at 16:26:29 UTC, Paulo Pinto wrote:
 This is not true for current native compilers and JVMs.

 If escape analysis can prove the object does not leave scope, 
 new actually allocates on the stack.
Modern can even speculate that an object will not leave scope, allocate it on stack, and move it on heap if it escape !
Jan 28 2013
parent reply Paulo Pinto <pjmlp progtools.org> writes:
Am 28.01.2013 17:30, schrieb deadalnix:
 On Monday, 28 January 2013 at 16:26:29 UTC, Paulo Pinto wrote:
 This is not true for current native compilers and JVMs.

 If escape analysis can prove the object does not leave scope, new
 actually allocates on the stack.
Modern can even speculate that an object will not leave scope, allocate it on stack, and move it on heap if it escape !
That is how Go works if you return a pointer to something declared on the stack.
Jan 28 2013
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 28, 2013 at 06:21:17PM +0100, Paulo Pinto wrote:
 Am 28.01.2013 17:30, schrieb deadalnix:
On Monday, 28 January 2013 at 16:26:29 UTC, Paulo Pinto wrote:
This is not true for current native compilers and JVMs.

If escape analysis can prove the object does not leave scope, new
actually allocates on the stack.
Modern can even speculate that an object will not leave scope, allocate it on stack, and move it on heap if it escape !
That is how Go works if you return a pointer to something declared on the stack.
I think DMD needs something like this, to fix all of those ref-to-stack bugs, like: - Unsafe slicing of static arrays - Slicing of variadic arguments - Delegates that reference a returned struct (becomes invalid because caller moves the struct but doesn't update the delegate's context ptr) - ref functions returning ref to local variables And many others. All of these become non-problems if the compiler (or code at runtime) detects the escaping reference and move the stuff onto the heap. T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
Jan 28 2013
prev sibling parent "eles" <eles eles.com> writes:
On Monday, 28 January 2013 at 15:15:38 UTC, Dejan Lekic wrote:
 On Friday, 25 January 2013 at 21:39:58 UTC, Namespace wrote:
 On Friday, 25 January 2013 at 20:45:22 UTC, Szymon wrote:
Java has far less features than D, including what you complain about, yet it is considered a pretty productive programming language...
I think it is no more about bringing in new features. It is just about ironing out and clarifying existing ones. People started complaining less and less about features (well, exceptions exist), but more and more about the quality of the implementation. Two month of crash-session in clarification & implementation would make D ready for the summer.
Jan 28 2013
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/25/2013 12:45 PM, Szymon wrote:
 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?
Yes, and it is in use for production code.
 I often hear ppl
 complaining about compiler bugs or regressions causing them to
 drop D "for now".
If you stick to bread and butter code, you shouldn't have problems. If you use advanced features out to the edge, you're more likely to run into issues. Furthermore, nothing says you have to upgrade to the latest version if it doesn't work for you. All released versions are available for download.
 Is it true that D has GC problems?
All GC's have problems. GC isn't a "fire and forget" way to deal with memory management. However, the GC is reliable and works well if you use it with awareness of how it works.
 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?
A much easier route is to add C++ code to a D project. I.e. make the D code have the 'main()'.
 3) Is it possible to use D on iOS?
Not at the moment.
Jan 25 2013
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 25, 2013 at 02:53:31PM -0800, Walter Bright wrote:
[...]
 If you stick to bread and butter code, you shouldn't have problems.
 If you use advanced features out to the edge, you're more likely to
 run into issues.
And I have to add that so far, I haven't found any problems that are showstoppers (in the sense that there's no way to work around it). Almost all of the bugs I've found have workarounds that aren't too painful. (They may look a bit ugly at times, but they work, and let you get the job done.) Even with advanced features, when you run into bugs it's almost always possible to recast your code in a way that *doesn't* use that specific combination of advanced features that exhibit the bug. You may not be able to write idealistic, perfect code in that case, but things will still work. [...]
Is it true that D has GC problems?
All GC's have problems. GC isn't a "fire and forget" way to deal with memory management. However, the GC is reliable and works well if you use it with awareness of how it works.
[...] I have to say that while the current GC certainly could do with some significant improvements, *I've* certainly never run into any major problems with it yet. There have been reports of performance loss in some cases, but there are ways to disable/re-enable the GC which you can use to minimize the problem around critical pieces of code. In any case, the GC *is* being worked on, and hopefully we'll see a much better incarnation of it in the near future. (Not to mention that having a GC makes it much easier to write certain kinds of code. Complex string manipulations, for example, are an utter pain in the neck in C/C++. The simplest operations require meticulous care and copious tricky pointer arithmetics to prevent buffer overflows and memory leaks. In D, you just write string operations with impunity and they Just Work(tm). And the resulting code is much more readable.) T -- Your inconsistency is the only consistent thing about you! -- KD
Jan 25 2013
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
Walter Bright wrote:

 Yes, and it is in use for production code.
What do you mean by this statement? Do those companies publish their reliance on D? How many people make there living on "production code" written in D with a time perspective of at least five years? -manfred
Jan 25 2013
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-25 21:45, Szymon wrote:

 3) Is it possible to use D on iOS?
The short answer is, no. The longer more detailed answer is, DMD cannot output ARM code. That means you need to use LDC or GDC. Don't know how good they work, also I don't know the status of the runtime on ARM. Then you need to somehow integrate the D compiler in the iOS tool chain. Except from actually be able to compile for iOS you need some way to integrate with Objective-C, if you want to do anything useful. For that you have three options: 1. The Objective-C runtime functions are implemented in standard C which D can call and link to. It becomes very tedious very fast using this approach. 2. Use the Objective-C runtime functions via a bridge that handles all type conversions and similar automatically. This causes code bloat due to template and virtual methods that cannot be optimized away. On Mac OS X we're talking about 60MB for a Hello World application. 3. Make D ABI compatible with Objective-C, i.e. extern (Objective-C). Michel Fortin has created a fork of DMD that implements this. He has released an alpha version of this fork which do work. Unfortunately the code hasn't been update for two to three years. The most correct approach would be number three. Objective-C bridge: http://www.dsource.org/projects/dstep D with support for Objective-C: http://michelf.ca/projects/d-objc/ -- /Jacob Carlborg
Jan 26 2013