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