View mode: basic / threaded / horizontal-split · Log in · Help
February 02, 2004
D strings
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 ?
February 02, 2004
Re: D strings
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.
February 02, 2004
Re: D strings
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.
February 02, 2004
Re: D strings
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.
>
February 02, 2004
Re: D strings
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.
February 02, 2004
Re: D strings
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.
>
February 02, 2004
Re: D strings
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
February 02, 2004
Re: D strings
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
February 03, 2004
Re: D strings
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.
February 03, 2004
Re: D strings
"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.
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home