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

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

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

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

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