January 26, 2013
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.

January 26, 2013
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
January 26, 2013
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.
January 26, 2013
> 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?
January 26, 2013

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...
January 26, 2013
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
January 26, 2013
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
January 26, 2013
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
January 26, 2013
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
January 26, 2013
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.