• Matthew Wilson (12/12) Oct 10 2003 I think that there should be two string concatenation operators.
• Jan-Eric Duden (17/29) Oct 10 2003 The manual :
• Patrick Down (4/19) Oct 10 2003 + and other operators are still being reserved for vector operations on
• Helmut Leitner (13/27) Oct 10 2003 Basically this doesn't seem to be an "operator" problem.
• Walter (14/25) Oct 10 2003 would

"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

"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

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

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.

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

"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

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).

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];