In winsamp.d, Walter does something like:

MessageBoxA(null, (char*)o.toString(), ...

Shouldn't that cause bugs because D strings arent null termintated? And why cant a pointer be implicity assigned to a D style array without casting ?

imr1984 wrote:
> In winsamp.d, Walter does something like:
> 
> MessageBoxA(null, (char*)o.toString(), ...
> 
> Shouldn't that cause bugs because D strings arent null termintated? And why cant
> a pointer be implicity assigned to a D style array without casting ?

That's a bug because of the lack of null termination and because D strings are encoded in UTF-8 while the A series of functions takes ASCII.  The right way is:

    import std.utf;

    MessageBoxW(null, toUTF16z(o.toString()));

A pointer can't be implicitly assigned to a D array because the compiler would have no idea how many items were in the array.

Burton Radons wrote:

> imr1984 wrote:
> 
>> In winsamp.d, Walter does something like:
>>
>> MessageBoxA(null, (char*)o.toString(), ...
>>
>> Shouldn't that cause bugs because D strings arent null termintated? And why cant
>> a pointer be implicity assigned to a D style array without casting ?
> 
> 
> That's a bug because of the lack of null termination and because D strings are encoded in UTF-8 while the A series of functions takes ASCII.  The right way is:
> 
>     import std.utf;
> 
>     MessageBoxW(null, toUTF16z(o.toString()));
> 
> A pointer can't be implicitly assigned to a D array because the compiler would have no idea how many items were in the array.

Addendum: The right way to cast from a pointer to an array is to slice the pointer space:

   char *buffer;
   int length;

   ...
   char [] string = buffer [0 .. length];

The "std.string" module also provides a function called "toString" that can convert a C-style "char *" to a "char []".

If a forced cast from a pointer to an array works at all, I'm not sure what it does, but I am sure it is wrong.  A pointer can't be said to contain anything for sure, not even one item.

inline

In article <bvlu5o$1fpr$1@digitaldaemon.com>, Burton Radons says...
>
>imr1984 wrote:
>> In winsamp.d, Walter does something like:
>> 
>> MessageBoxA(null, (char*)o.toString(), ...
>> 
>> Shouldn't that cause bugs because D strings arent null termintated? And why cant a pointer be implicity assigned to a D style array without casting ?
>
>That's a bug because of the lack of null termination and because D strings are encoded in UTF-8 while the A series of functions takes ASCII.  The right way is:
>
>     import std.utf;
>
>     MessageBoxW(null, toUTF16z(o.toString()));

What about Win98/95 backward compatibility?

>
>A pointer can't be implicitly assigned to a D array because the compiler would have no idea how many items were in the array.
>

Patrick Down wrote:
> inline
> 
> In article <bvlu5o$1fpr$1@digitaldaemon.com>, Burton Radons says...
> 
>>imr1984 wrote:
>>
>>>In winsamp.d, Walter does something like:
>>>
>>>MessageBoxA(null, (char*)o.toString(), ...
>>>
>>>Shouldn't that cause bugs because D strings arent null termintated? And why cant
>>>a pointer be implicity assigned to a D style array without casting ?
>>
>>That's a bug because of the lack of null termination and because D strings are encoded in UTF-8 while the A series of functions takes ASCII.  The right way is:
>>
>>    import std.utf;
>>
>>    MessageBoxW(null, toUTF16z(o.toString()));
> 
> 
> What about Win98/95 backward compatibility?

MessageBoxW already exists in Windows 95/98 (ms-help://MS.VSCC/MS.MSDNVS/win32/unilayer_7ezp.htm).

Microsoft has provided a "UNICODE" layer for the unsupported functions, but all that it does is remove the naughty characters from the UNICODE input so that it maps to the display code page.  That could be handled more easily (not requiring a separate DLL with each program) by a wrapping layer.

Burton, I actually asked, why cant you implicitly cast from an array to a pointer, not the other way round. Can you explain that to me?

In article <bvlvdm$1hm3$1@digitaldaemon.com>, Burton Radons says...
>
>Burton Radons wrote:
>
>> imr1984 wrote:
>> 
>>> In winsamp.d, Walter does something like:
>>>
>>> MessageBoxA(null, (char*)o.toString(), ...
>>>
>>> Shouldn't that cause bugs because D strings arent null termintated?
>>> And why cant
>>> a pointer be implicity assigned to a D style array without casting ?
>> 
>> 
>> That's a bug because of the lack of null termination and because D strings are encoded in UTF-8 while the A series of functions takes ASCII.  The right way is:
>> 
>>     import std.utf;
>> 
>>     MessageBoxW(null, toUTF16z(o.toString()));
>> 
>> A pointer can't be implicitly assigned to a D array because the compiler would have no idea how many items were in the array.
>
>Addendum: The right way to cast from a pointer to an array is to slice the pointer space:
>
>    char *buffer;
>    int length;
>
>    ...
>    char [] string = buffer [0 .. length];
>
>The "std.string" module also provides a function called "toString" that can convert a C-style "char *" to a "char []".
>
>If a forced cast from a pointer to an array works at all, I'm not sure what it does, but I am sure it is wrong.  A pointer can't be said to contain anything for sure, not even one item.
>

imr1984 wrote:
> Burton, I actually asked, why cant you implicitly cast from an array to a
> pointer, not the other way round. Can you explain that to me?
> 

It does implicitly cast:

char[] foo = "hi";
char* pfoo = foo; //valid

oops, silly me. I was led to believe that you couldn't implicitly cast it becuase Walter uses an explicit cast from char[] to char* in his winsamp.d example.

In article <bvmbiq$25o9$1@digitaldaemon.com>, Vathix says...
>
>imr1984 wrote:
>> Burton, I actually asked, why cant you implicitly cast from an array to a pointer, not the other way round. Can you explain that to me?
>> 
>
>It does implicitly cast:
>
>char[] foo = "hi";
>char* pfoo = foo; //valid

While it was 2/2/04 8:38 pm throughout the UK, imr1984 sprinkled little black dots on a white screen, and they fell thus:

> oops, silly me. I was led to believe that you couldn't implicitly cast it
> becuase Walter uses an explicit cast from char[] to char* in his winsamp.d
> example.
<snip top of upside-down reply>

It does tend to be a Good Idea from time to time to explicitly cast even when an implicit conversion would work.  Such as to make sure that you, other people reading your code, and the compiler all know which version of an overloaded function is going to be called.

Of course:
- D's unique matching principle should make this less necessary
- it gets done with functions that aren't overloaded

but I guess some people would just tend to "if in doubt, cast it".

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

"Stewart Gordon" <smjg_1998@yahoo.com> wrote in message news:bvoeoa$4ro$1@digitaldaemon.com...
> While it was 2/2/04 8:38 pm throughout the UK, imr1984 sprinkled little black dots on a white screen, and they fell thus:
>
> > oops, silly me. I was led to believe that you couldn't implicitly cast it becuase Walter uses an explicit cast from char[] to char* in his winsamp.d example.
> <snip top of upside-down reply>
>
> It does tend to be a Good Idea from time to time to explicitly cast even when an implicit conversion would work.  Such as to make sure that you, other people reading your code, and the compiler all know which version of an overloaded function is going to be called.
>
> Of course:
> - D's unique matching principle should make this less necessary
> - it gets done with functions that aren't overloaded
>
> but I guess some people would just tend to "if in doubt, cast it".


<general_hint>

Well, no. Explicit cast is almost always a Bad Thing. Documenting your intention, OTOH, is always a Good Thing.

Now, the problem is that an explicit cast does not only document
your intention, but it also _forces_ your intention through
some possible protection mechanisms a compiler could do for
you when your intention is actually wrong...

So, whenever an implicit cast does what you want, NEVER make it explicit, circumventing the implicit compiler control. But, do ALWAYS add a comment about the casting. That would give you the good part of both choices.

</general_hint>

Sz.