On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
> That's good news! See, we're getting there, just bear with us. This begs the question of course, how will this affect existing code? My code is string intensive.

Usually GC-free API is added by providing new overloads that take an output range instance as an argument so no existing code should break (it will still use allocating versions)

On Thursday, 17 July 2014 at 18:08:18 UTC, Dicebot wrote:
> On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
>> That's good news! See, we're getting there, just bear with us. This begs the question of course, how will this affect existing code? My code is string intensive.
>
> Usually GC-free API is added by providing new overloads that take an output range instance as an argument so no existing code should break (it will still use allocating versions)

Yes, output ranges are underused by now.

On 7/17/14, 2:32 PM, Right wrote:
>   I hate GC, so there.
>
>> I see no proof of this. And not everybody hates GCs.
>>
>> Bye,
>> bearophile
>

Java is everywhere and it has a GC. Go is starting to be everywhere and it has a GC. C# too has a GC, and I think they use it to make games too. I don't think everyone hates GCs. :-)

On Thursday, 17 July 2014 at 16:56:56 UTC, Vic wrote:
> On Thursday, 17 July 2014 at 13:29:18 UTC, John wrote:
> <snip>
>>
>> If D came without GC, it would have replaced C++ a long time ago!
>
> Agree +1000.
>
> If GC is so good, why not make it an option, have a base lib w/o GC.
>
> If I want GC, I got me JRE. It seems that some in D want to write a better JRE, and that just won't happen ever.
>
> Cheers,
> Vic

I can't think of anyone posting here, to be honest, who wants to write a better JRE. The JRE is a virtual machine, and java compiles to bytecode that is run on the JVM. On the contrary, and in accordance with the core principle that D is a systems programming language, D compiles to native and (hopefully) highly optimised native machine code. There does exist something of a 'culture clash' where, by the very nature of GCs, there can be not-insignificant pauses in the running of the program that would be inimicable to real-time software such as high res complex games, operating systems, drivers etc.

The response to this in the forums is either to improve the GC so that it doesn't ever pause for more than a certain amount of time (e.g. concurrent GCs, remove the global lock so other threads can continue to run), or to offer alternative memory management approaches such as ARC, which can also have pauses, but at other inflections as the program runs.

Personally I'm a bit disappointed that the good work that has been done on GCs so far doesn't seem to be being picked up and run with, and nor do I see any reasons given as to why that is the case. Adnrei was threatening to start another GC an one point but unfortunately I haven't seen any more of that and we all know how short of time every one seems to be these days.

Also on a personal note, I see some slightly snarky comments about D targeting C# and Java. Well from my perspective I'm extremely happy with the fact that D is a better C# and a better Java. I just wish it had Qt (I must finish my bindings for Qt) and/or ran on Android! The GC issues are irrelevant for me.

On Thu, Jul 17, 2014 at 05:58:14PM +0000, Chris via Digitalmars-d wrote:
> On Thursday, 17 July 2014 at 17:49:24 UTC, H. S. Teoh via Digitalmars-d wrote:
[...]
> >AFAIK some work still needs to be done with std.string; Walter for one has started some work to implement range-based equivalents for std.string functions, which would be non-allocating; we just need a bit of work to push things through.
> >
> >DMD 2.066 will have @nogc, which will make it easy to discover which remaining parts of Phobos are still not GC-free. Then we'll know where to direct our efforts. :-)
> >
> >
> >T
> 
> That's good news! See, we're getting there, just bear with us. This begs the question of course, how will this affect existing code? My code is string intensive.

I don't think it will affect existing code (esp. given Walter's stance on breaking changes!). Probably the old GC-based string functions will still be around for backwards-compatibility. Perhaps some of them might be replaced with non-GC versions where it can be done transparently, but I'd expect you'd need to rewrite your string code to take advantage of the new range-based stuff. Hopefully the rewrites will be minimal (e.g., pass in an output range as argument instead of getting a returned string, replace allocation-based code with a UFCS chain, etc.). The ideal scenario may very well be as simple as tacking on `.copy(myBuffer)` at the end of a UFCS chain. :-P


T

-- 
Genius may have its limitations, but stupidity is not thus handicapped. -- Elbert Hubbard

On Thu, Jul 17, 2014 at 06:09:49PM +0000, deadalnix via Digitalmars-d wrote:
> On Thursday, 17 July 2014 at 18:08:18 UTC, Dicebot wrote:
> >On Thursday, 17 July 2014 at 17:58:15 UTC, Chris wrote:
> >>That's good news! See, we're getting there, just bear with us. This begs the question of course, how will this affect existing code? My code is string intensive.
> >
> >Usually GC-free API is added by providing new overloads that take an output range instance as an argument so no existing code should break (it will still use allocating versions)
> 
> Yes, output ranges are underused by now.

Actually, I've realized that output ranges are really only useful when you want to store the final result. For data in mid-processing, you really want to be exporting an input (or higher) range interface instead, because functions that take output ranges are not composable. And for storing final results, you just use std.algorithm.copy, so there's really no need for many functions to take an output range at all.


T

-- 
One Word to write them all, One Access to find them, One Excel to count them all, And thus to Windows bind them. -- Mike Champion

H. S. Teoh:

> I don't think it will affect existing code (esp. given Walter's stance on breaking changes!).

Making various parts of Phobos GC-free doesn't mean that nothing GC-allocates, it means that Phobos will offer means to use memory provided by the user. There are many situations where using a GC is OK, so both kinds of usages should be supported by Phobos. It should contain nothrow @nogc functions to format and to convert to number and strings. It's a matter of offering choice.

Bye,
bearophile

On Thursday, 17 July 2014 at 18:22:11 UTC, H. S. Teoh via Digitalmars-d wrote:
> Actually, I've realized that output ranges are really only useful when
> you want to store the final result. For data in mid-processing, you
> really want to be exporting an input (or higher) range interface
> instead, because functions that take output ranges are not composable.
> And for storing final results, you just use std.algorithm.copy, so
> there's really no need for many functions to take an output range at
> all.

Plain algorithm ranges rarely need to allocate at all so those are somewhat irrelevant to the topic. What I am speaking about are variety of utility functions like this:

S detab(S)(S s, size_t tabSize = 8)
    if (isSomeString!S)

this allocates result string. Proper alternative:

S detab(S)(ref S output, size_t tabSize = 8)
    if (isSomeString!S);

plus

void detab(S, OR)(OR output, size_t tab_Size = 8)
    if (   isSomeString!S
        && isSomeString!(ElementType!OR)
       )

On Thu, 2014-07-17 at 15:11 -0300, Ary Borenszweig via Digitalmars-d
wrote:
[…]
> Java is everywhere and it has a GC. Go is starting to be everywhere and it has a GC. C# too has a GC, and I think they use it to make games too. I don't think everyone hates GCs. :-)

I think we need to try and turn this to a more constructive debate and the above gives a hook.

The Go thread is coming to the conclusion that they need a better GC than they currently have. I suspect this will now become a unit of work and that something good will come of it.

For many years GC in Java has been a bit of a problem; Java relies on GC, yet the algorithms were always a bit of a compromise and second rate. However Java now has the G1 garbage collector and there is evidence and a huge amount of hope that this is actually a turning point.

Java exhibits the behaviour of having a lot of very short lived objects so it becomes crucial to be able to deal with object creation as a very lightweight activity and for very lightweight collection of rapidly useless objects. Java originally went for a generational GC strategy but this has always led to problems especially in a multicore context. Taking an alternative strategy, G1 has seemingly ameliorated a lot of the problems leading to a system that is not "stop the world", is multicore and multithread compatible, and works very well such that soft real time is seemingly not a problem.

I have no data re C#.

With C++ I am coming to grips with RAII management of the heap. With Java, Groovy, Go and Python I rely on the GC doing a good job. I note though that there is a lot of evidence that the Unreal folk developed a garbage collector for C++ exactly because they didn't want to do the RAII thing.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 7/17/14, 11:11 AM, Ary Borenszweig wrote:
> On 7/17/14, 2:32 PM, Right wrote:
>>   I hate GC, so there.
>>
>>> I see no proof of this. And not everybody hates GCs.
>>>
>>> Bye,
>>> bearophile
>>
>
> Java is everywhere and it has a GC. Go is starting to be everywhere and
> it has a GC. C# too has a GC, and I think they use it to make games too.
> I don't think everyone hates GCs. :-)

http://www.stroustrup.com/C++11FAQ.html#gc-abi

Andrei