www.digitalmars.com         C & C++   DMDScript  

D - String concatenation - operators ... ???

reply "Matthew Wilson" <matthew stlsoft.org> writes:
I think that there should be two string concatenation operators.

At the moment, ~ (and ~=) concatenates the contents of a char[] as it would
any other array. Hence, if the string contains embedded (or simply trailing)
null(s), they are preserved, and the string - to a C-style string
recipient - appears to be unchanged.

Since this is a ridiculously easy situation to find oneself in, I think that
the ~ (and ~=) operator(s) not fit for character handling, and that another
should be considered. Alternatively, + (and +=) can be used to concatenate
arrays, and ~ can be used solely for C-string concatenation (of char[] and
wchar[], and arguably for an array of any type where a 0 value can be
meaningfully identified).

Matthew
Oct 10 2003
next sibling parent "Jan-Eric Duden" <jeduden whisset.com> writes:
The manual :
"...Since strings, however, are not 0 terminated in D, when transfering a
pointer to a string to C, add a terminating 0..."
Thus if you get your strings from C you just need to strip of the trailing
0,
this should do it:

d_str=c_str[0..c_str.length-1];

I personally like the difference between ~ and + a lot.
I guess Walter won't change the semantics of ~, right?

-- 
Jan-Eric Duden

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm62jc$15j$1 digitaldaemon.com...
 I think that there should be two string concatenation operators.

 At the moment, ~ (and ~=) concatenates the contents of a char[] as it

 any other array. Hence, if the string contains embedded (or simply

 null(s), they are preserved, and the string - to a C-style string
 recipient - appears to be unchanged.

 Since this is a ridiculously easy situation to find oneself in, I think

 the ~ (and ~=) operator(s) not fit for character handling, and that

 should be considered. Alternatively, + (and +=) can be used to concatenate
 arrays, and ~ can be used solely for C-string concatenation (of char[] and
 wchar[], and arguably for an array of any type where a 0 value can be
 meaningfully identified).

 Matthew

Oct 10 2003
prev sibling next sibling parent Patrick Down <pat codemoon.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in
news:bm62jc$15j$1 digitaldaemon.com: 

 I think that there should be two string concatenation operators.
 
 At the moment, ~ (and ~=) concatenates the contents of a char[] as it
 would any other array. Hence, if the string contains embedded (or
 simply trailing) null(s), they are preserved, and the string - to a
 C-style string recipient - appears to be unchanged.
 
 Since this is a ridiculously easy situation to find oneself in, I
 think that the ~ (and ~=) operator(s) not fit for character handling,
 and that another should be considered. Alternatively, + (and +=) can
 be used to concatenate arrays, and ~ can be used solely for C-string
 concatenation (of char[] and wchar[], and arguably for an array of any
 type where a 0 value can be meaningfully identified).
 
 Matthew

+ and other operators are still being reserved for vector operations on arrays.
Oct 10 2003
prev sibling next sibling parent Helmut Leitner <leitner hls.via.at> writes:
Matthew Wilson wrote:
 
 I think that there should be two string concatenation operators.
 
 At the moment, ~ (and ~=) concatenates the contents of a char[] as it would
 any other array. Hence, if the string contains embedded (or simply trailing)
 null(s), they are preserved, and the string - to a C-style string
 recipient - appears to be unchanged.
 
 Since this is a ridiculously easy situation to find oneself in, I think that
 the ~ (and ~=) operator(s) not fit for character handling, and that another
 should be considered. Alternatively, + (and +=) can be used to concatenate
 arrays, and ~ can be used solely for C-string concatenation (of char[] and
 wchar[], and arguably for an array of any type where a 0 value can be
 meaningfully identified).

Basically this doesn't seem to be an "operator" problem. Anyone can write a StringCatStringz function. But if we view it as an operator problem, then looking for singular solutions just is not enough. It can only be by chance that we have an operator at hand that we can sensefullly overload. I think that named operators would be a way to go (syntax open for discussion: string = sza <=cat0=> szb; This would also allow things like: matrix = ( veca <=vecmul=> vecb ) <=matmul=> matrixb ; -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Oct 10 2003
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bm62jc$15j$1 digitaldaemon.com...
 I think that there should be two string concatenation operators.

 At the moment, ~ (and ~=) concatenates the contents of a char[] as it

 any other array. Hence, if the string contains embedded (or simply

 null(s), they are preserved, and the string - to a C-style string
 recipient - appears to be unchanged.

 Since this is a ridiculously easy situation to find oneself in, I think

 the ~ (and ~=) operator(s) not fit for character handling, and that

 should be considered. Alternatively, + (and +=) can be used to concatenate
 arrays, and ~ can be used solely for C-string concatenation (of char[] and
 wchar[], and arguably for an array of any type where a 0 value can be
 meaningfully identified).

I think that adding more operators would be a more confusing solution than converting the strings back to D strings with: string = string[0..string.length-1]; would be. In general, the way to deal with C strings is to convert to ASCIZ as the *last* step before calling a C function, and when receiving a C string, first thing is to convert it to a D string with: string = string[0..string.length-1];
Oct 10 2003