www.digitalmars.com         C & C++   DMDScript  

D - toStringz

reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
A current requirement has me wanting toStringz return NULL when passed a
null char[]. However, I can see that it might also be good to return "".

What is scary is that the current implementation appears to do neither, and
expects a non-null char[] to be passed.

What're everyone's thoughts on a best policy for library-functions working
with null array (and other type) references?
Dec 18 2003
next sibling parent reply "Vathix" <vathix dprogramming.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,

 expects a non-null char[] to be passed.

 What're everyone's thoughts on a best policy for library-functions working
 with null array (and other type) references?

I'd say a char[] that is actually null (s === null I think) should return null, but if it's just 0 length, it should be "".
Dec 18 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10 machine
cycles over the entire execution, surely that's worth it!  ;)

((I'm joking.  I agree with Vathix.))

The nice thing about D is, that library functions can be inlined, and the
compiler has an opportunity to see if the parameter passed in is always null
or not, and eliminate the inappropriate cases.

Sean

"Vathix" <vathix dprogramming.com> wrote in message
news:brsn7u$q97$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,

 expects a non-null char[] to be passed.

 What're everyone's thoughts on a best policy for library-functions


 with null array (and other type) references?

I'd say a char[] that is actually null (s === null I think) should return null, but if it's just 0 length, it should be "".

Dec 18 2003
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10 machine
 cycles over the entire execution, surely that's worth it!  ;)

 ((I'm joking.  I agree with Vathix.))

But it's not a joke. If we make library functions null-tolerant we may be promoting the culture that Borland did by making their str??? functions null-tolerant, which ...
 The nice thing about D is, that library functions can be inlined, and the
 compiler has an opportunity to see if the parameter passed in is always

 or not, and eliminate the inappropriate cases.

... leads to an overall loss of efficiency, since the compiler will be unable to deduce all cases. The less aesthetically appealing, but probably better, alternative is to have different shims to be null-tolerant. (I refer the honourable gentleman to the sidebar http://www.cuj.com/documents/s=8681/cuj0308wilson/cuj0308wilson_sb4.htm from my oft-touted "Generalized String Manipulation ..." article.) I'd be interested in your further thoughts on this. Matthew
 Sean

 "Vathix" <vathix dprogramming.com> wrote in message
 news:brsn7u$q97$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed



 null char[]. However, I can see that it might also be good to return



 What is scary is that the current implementation appears to do



 and
 expects a non-null char[] to be passed.

 What're everyone's thoughts on a best policy for library-functions


 with null array (and other type) references?

I'd say a char[] that is actually null (s === null I think) should


 null, but if it's just 0 length, it should be "".


Dec 18 2003
parent reply "Vathix" <vathix dprogramming.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brt1d3$1ab7$1 digitaldaemon.com...
 What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10 machine
 cycles over the entire execution, surely that's worth it!  ;)

 ((I'm joking.  I agree with Vathix.))

But it's not a joke. If we make library functions null-tolerant we may be promoting the culture that Borland did by making their str??? functions null-tolerant, which ...
 The nice thing about D is, that library functions can be inlined, and


 compiler has an opportunity to see if the parameter passed in is always

 or not, and eliminate the inappropriate cases.

... leads to an overall loss of efficiency, since the compiler will be unable to deduce all cases.

I fail to see the problem. In D strings, null[0 .. 0] is just like "" and won't cause a problem. The issue is with C strings, which shouldn't be used too often. I solve this by doing s = toStringz(s)[0 .. s.length] if I know I'm going to be using a particular string a lot with C. Then I can use s with functions that expect C or D strings.
Dec 18 2003
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Vathix" <vathix dprogramming.com> wrote in message
news:brt8ga$1lij$1 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brt1d3$1ab7$1 digitaldaemon.com...
 What?!!  Why wouldn't you want it to crash?  C'mon, it'll save10



 cycles over the entire execution, surely that's worth it!  ;)

 ((I'm joking.  I agree with Vathix.))

But it's not a joke. If we make library functions null-tolerant we may


 promoting the culture that Borland did by making their str??? functions
 null-tolerant, which ...

 The nice thing about D is, that library functions can be inlined, and


 compiler has an opportunity to see if the parameter passed in is



 null
 or not, and eliminate the inappropriate cases.

... leads to an overall loss of efficiency, since the compiler will be unable to deduce all cases.

I fail to see the problem. In D strings, null[0 .. 0] is just like "" and won't cause a problem. The issue is with C strings, which shouldn't be

 too often. I solve this by doing  s = toStringz(s)[0 .. s.length] if I

 I'm going to be using a particular string a lot with C. Then I can use s
 with functions that expect C or D strings.

I don't really understand what you're saying there, I'm afraid. I'm not sure you're addressing my issue. I have a C function that either wants a file name, or it wants a null (string) pointer. I call this function via a private static helper (to provide exceptions if the C func fails) from within a couple of constructors, two of which pass a (non-null) D string for the filename, and the third passes a null. In the D helper function I want to translate the potentially null D string into either a null-terminated C string, or a null (C) string pointer. Hence, static void helper(char[] dstr) { char *cstr = (null === dtr) ? null : toStringz(dstr); cfunc(cstr, . .. ); } My point was whether toStringz() should be able to work with null D strings - which it currently does _not_ - or whether we should be forced to use the idiom shown in the code above. I then suggested (rather ineptly, I admit), that the "null"-handling of such helper functions should not be implicit, but rather in the form of a separate function, perhaps call toStringzNull, as in char *toStringz(char[] dstr) { assert(null !== dstr); // This current does not exist! . . . // the rest of the current implementation } char *toStringzNull(char[] dstr) { return (null === dstr) ? null : toStringz(dstr) } That way, we don't get into a Borland-like mindset whereby a null string is the same as an empty string - which it most certainly is not - and we don't infect all code with tests that 95% of it does not need. We are D, after all, not Java! =P Walter, any thoughts? Matthew
Dec 18 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,

 expects a non-null char[] to be passed.

I disagree. string.toStringz() works correctly when passed a null string (it returns "").
 What're everyone's thoughts on a best policy for library-functions working
 with null array (and other type) references?

A null array has a .length property of 0. There should be no problem at all, since a 0 length array and a NULL array have the same representation.
Dec 18 2003
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Walter" <walter digitalmars.com> wrote in message
news:brth37$22f3$2 digitaldaemon.com...
 "Matthew" <matthew.hat stlsoft.dot.org> wrote in message
 news:brs0k4$2nje$1 digitaldaemon.com...
 A current requirement has me wanting toStringz return NULL when passed a
 null char[]. However, I can see that it might also be good to return "".

 What is scary is that the current implementation appears to do neither,

 expects a non-null char[] to be passed.

I disagree. string.toStringz() works correctly when passed a null string

 returns "").

My mistake. Strike one for the bleary eyed monster.
 What're everyone's thoughts on a best policy for library-functions


 with null array (and other type) references?

A null array has a .length property of 0. There should be no problem at

 since a 0 length array and a NULL array have the same representation.

That's good. That can be transferred to all manner of things. :) That's going to have a cost, though, for each array access, since there'll be checks for every .length access. You deliberately chose safety first here, then?
Dec 18 2003
parent reply "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:brtikj$24oo$1 digitaldaemon.com...
 That's going to have a cost, though, for each array access, since there'll
 be checks for every .length access. You deliberately chose safety first
 here, then?

I don't see how this is any extra cost. It's just normal array bounds checking, which can be turned on or off <g>.
Dec 18 2003
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 That's going to have a cost, though, for each array access, since


 be checks for every .length access. You deliberately chose safety first
 here, then?

I don't see how this is any extra cost. It's just normal array bounds checking, which can be turned on or off <g>.

I think I'm forgetting that arrays themselves (i.e. the len+ptr structures) are passed by value. Blonde moment ...
Dec 18 2003