D - toStringz
- Matthew (6/6) Dec 18 2003 A current requirement has me wanting toStringz return NULL when passed a
- Vathix (5/11) Dec 18 2003 and
- Sean L. Palmer (10/24) Dec 18 2003 What?!! Why wouldn't you want it to crash? C'mon, it'll save10 machine
- Walter (7/13) Dec 18 2003 and
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
"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,andexpects 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
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...workingA 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,andexpects a non-null char[] to be passed. What're everyone's thoughts on a best policy for library-functionswith 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
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 alwaysnullor 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. MatthewSean "Vathix" <vathix dprogramming.com> wrote in message news:brsn7u$q97$1 digitaldaemon.com...a"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 returnneither,What is scary is that the current implementation appears to doreturnandworkingexpects a non-null char[] to be passed. What're everyone's thoughts on a best policy for library-functionswith null array (and other type) references?I'd say a char[] that is actually null (s === null I think) shouldnull, but if it's just 0 length, it should be "".
Dec 18 2003
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:brt1d3$1ab7$1 digitaldaemon.com...theWhat?!! 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, andI 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.compiler has an opportunity to see if the parameter passed in is alwaysnullor not, and eliminate the inappropriate cases.... leads to an overall loss of efficiency, since the compiler will be unable to deduce all cases.
Dec 18 2003
"Matthew" <matthew.hat stlsoft.dot.org> "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...machineWhat?!! Why wouldn't you want it to crash? C'mon, it'll save10becycles 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 mayalwayspromoting the culture that Borland did by making their str??? functions null-tolerant, which ...theThe nice thing about D is, that library functions can be inlined, andcompiler has an opportunity to see if the parameter passed in isusednullI 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 beor not, and eliminate the inappropriate cases.... leads to an overall loss of efficiency, since the compiler will be unable to deduce all cases.too often. I solve this by doing s = toStringz(s)[0 .. s.length] if IknowI'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
"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,andexpects 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
"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...(itA 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,andexpects a non-null char[] to be passed.I disagree. string.toStringz() works correctly when passed a null stringreturns "").My mistake. Strike one for the bleary eyed monster.workingWhat're everyone's thoughts on a best policy for library-functionsall,with null array (and other type) references?A null array has a .length property of 0. There should be no problem atsince 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
"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
there'llThat's going to have a cost, though, for each array access, sinceI think I'm forgetting that arrays themselves (i.e. the len+ptr structures) are passed by value. Blonde moment ...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