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