On Wed, 13 Jul 2011 19:31:42 +0100, Steven Schveighoffer
<[email protected]> wrote:
On Wed, 13 Jul 2011 13:32:56 -0400, Regan Heath <[email protected]>
wrote:
On Wed, 13 Jul 2011 17:00:39 +0100, Steven Schveighoffer
<[email protected]> wrote:
How does your proposal know that a char * is part of a heap-allocated
array? If you are assuming the only case where char * is passed will
be arr.ptr, then that doesn't cut it. What if the compiler doesn't
know where the char * came from?
See your Q and my A above ("char * foo" example).
The inherent problem of zero-terminated strings is that you don't know
how long it is until you search for a zero. If it's not properly
terminated, then you are screwed. That problem cannot be "solved",
even with compiler help -- you can get situations where there is no
more information other than the pointer.
Really? But cant we obtain the GC lock and look them up, as mentioned
above? And isn't this exactly what toStringz will do when the
programmer first of all curses because it has crashed, and then adds an
explicit toStringz call?
Who said the char * points into GC memory? It could point at stack
memory, or static data in ROM.
Ok. What would toStringz do in this case? .. because that's what I'm
proposing we do here.
The goal here is to pick some low hanging fruit, the general case
mentioned earlier, and make it work as a new D programmer would expect.
In that case there is no technical difficulty implementing it (toStringz
already exists), there is no extra cost (you already have to call
toStringz), and the only disagreement seems to be whether it should be
implicit or explicit.
In this particular case I cannot see any harm in making it implicit. Yes,
there are some edge cases, but they either already exist (as shown by the
explicit toStringz example I gave where the passed char[] remained
unchanged, and your example passing buffer[]), or they may be detectable
by the compiler, or they are rare - in which case requiring some manual
intervention is not too much to ask.
So, on balance I reckon the implicit call would be "better" for more
people more of the time, and at no extra cost. It seems like a win/win to
me. Yes, there are edge cases, yes there are wrinkles to iron out, no
it's not a "general/covers everything perfectly" kind of idea - which I
agree we'd all prefer, but it makes D look slicker, and removes one more
stumbling block for new D programmers.
--
Using Opera's revolutionary email client: http://www.opera.com/mail/
