On Friday, 18 July 2014 at 09:25:46 UTC, Chris wrote:
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>.
Java has AOT compilers available since the early days. Most
developers just tend to ignore them, because they are not part of
the free package.
--
Paulo
