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.

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.

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.

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().

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. :)

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.

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 ;)

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

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!!

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.