GCs in the news

Chris via Digitalmars-d digitalmars-d at puremagic.com
Fri Jul 18 02:25:45 PDT 2014


On Thursday, 17 July 2014 at 18:19:04 UTC, H. S. Teoh via 
Digitalmars-d wrote:
> 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

That sounds good to me! This gives me time to upgrade my old code 
little by little and use the new approach when writing new code. 
Phew!

By the way, my code is string intensive and I still have some 
suboptimal (greedy) ranges here and there. But believe it or not, 
they're no problem at all. The application (a plugin for a screen 
reader) is fast and responsive* (according to user feedback) like 
any other screen reader plugin, and it hasn't crashed for ages 
(thanks to GC?) - knock on wood! I use a lot of lazy ranges too 
plus some pointer magic for work intensive algorithms. Plus D let 
me easily model the various relations between text and speech 
(for other use cases down the road). Maybe it is not a real time 
system, but it has to be responsive. So far, GC hasn't affected 
it negatively. Once the online version will be publicly 
available, I will report how well vibe.d performs. Current 
results are encouraging.

As regards Java, the big advantage of D is that it compiles to a 
native DLL and all users have to do is to double click on it to 
install. No "please download JVM" nightmare. I've been there. 
Users cannot handle it (why should they?), and to provide it as a 
developer is a waste of time and resources, and it might still go 
wrong which leaves both the users and the developers angry and 
frustrated.

* The only thing that bothers me is that there seems to be a 
slight audio latency problem on Windows, which is not D's fault. 
On Linux it speaks as soon as you press <Enter>.



More information about the Digitalmars-d mailing list