May 25, 2006
In article <1xu5l9je8ge3f.txbccq4m8i7m.dlg@40tude.net>, Derek Parnell says...
>
>On Wed, 24 May 2006 14:15:43 -0700, BCS wrote:
>>
[...]
>>
>
>But if that happened, things lke concatenation would cause problems.
>
>#define FOO "foo"
>#define BAR "bar"
>   |
>   |
>   V
>const char[] FOO = "foo\0"; //explicitly null terminate const char[] BAR = "bar\0"; //explicitly null terminate
>
>. . .
>
>  char[] x = FOO ~ BAR; // Now it has an embedded \0 !
>
>-- 

I'll grant that. I think this will be another case of there being no 1-to-1 correspondence from C to D. I expect that with char constants, they are more likely to get copied than concatenated. The work around for either is easy as long as you remember it.

Char[] foo = "bar", copy; copy = bar ~ \0; \\cat copies

Char[] foo = "bar\0"
bing = "baz\0", copy; copy = bar[0..$-1] ~ bing ; \\cat copies



May 27, 2006
>>
>>But if that happened, things lke concatenation would cause problems.
>>
>>#define FOO "foo"
>>#define BAR "bar"
>>   |
>>   |
>>   V
>>const char[] FOO = "foo\0"; //explicitly null terminate const char[] BAR = "bar\0"; //explicitly null terminate
>>
>>. . .
>>
>>  char[] x = FOO ~ BAR; // Now it has an embedded \0 !

I thought that D managed the "\0" characters ( that was why we hadn't to put any
in our char [] variables ). Therefore I made the following test :
// constchar.d
import std.stdio ;

const char [] foo  = "foo\0" ;
typeof ( foo ) bar = "bar\0" ;

void main ()
{
char [] test = foo ~ bar ;

writefln ( test );
}
ray@Moonraker:~/dee/tmp$ ./constchar
foobar

Seems that there is no problem. I may have not understand something.


May 27, 2006
Rémy Mouëza wrote:

> import std.stdio ;
> 
> const char [] foo  = "foo\0" ;
> typeof ( foo ) bar = "bar\0" ;
> 
> void main ()
> {
> char [] test = foo ~ bar ;
> 
> writefln ( test );
> }

No, there are no problems, but your string test has length 8 now (\0 is a
non-printable character).

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource & #D: larsivi
May 27, 2006

Rémy Mouëza wrote:
>>>But if that happened, things lke concatenation would cause problems.
>>>
>>>#define FOO "foo"
>>>#define BAR "bar"
>>>  |
>>>  |
>>>  V
>>>const char[] FOO = "foo\0"; //explicitly null terminate
>>>const char[] BAR = "bar\0"; //explicitly null terminate
>>>
>>>. . .
>>>
>>> char[] x = FOO ~ BAR; // Now it has an embedded \0 !
> 
> 
> I thought that D managed the "\0" characters ( that was why we hadn't to put any
> in our char [] variables ). Therefore I made the following test :
> // constchar.d
> import std.stdio ;
> 
> const char [] foo  = "foo\0" ;
> typeof ( foo ) bar = "bar\0" ;
> 
> void main ()
> {
> char [] test = foo ~ bar ;
> 
> writefln ( test );
> }
> ray@Moonraker:~/dee/tmp$ ./constchar
> foobar
> 
> Seems that there is no problem. I may have not understand something.
> 
> 

With DMD 0.158 on Windows, I got "foo bar" from this.  Note the space between.  Also note that writef is written in D, for D, and therefore doesn't use null characters as end-of-string (it relies on the .length property instead).  The big problem had to do with sending these strings to C code, which /will/ see the null's as an end-of-array marker. Try replacing your writefln with a printf, and you will only get "foo" printed to the screen.

-- Chris Nicholson-Sauls
May 28, 2006
In article <e5a6dp$ols$1@digitaldaemon.com>, Chris Nicholson-Sauls says...
>With DMD 0.158 on Windows, I got "foo bar" from this.  Note the space between.  Also note that writef is written in D, for D, and therefore doesn't use null characters as end-of-string (it relies on the .length property instead).  The big problem had to do with sending these strings to C code, which /will/ see the null's as an end-of-array marker. Try replacing your writefln with a printf, and you will only get "foo" printed to the screen.

Using printf with dmd 0.158 on Linux, I've got 5 spaces and then "foo".
I guess that even a restricted use of the C preprocessor for our D interfaces
won't solve the problem since it seems to be type specific, will it ?


1 2 3 4
Next ›   Last »