View mode: basic / threaded / horizontal-split · Log in · Help
February 04, 2004
Re: D strings
The unicode-layer is a separate DLL. Applications which use this layer need
to install the DLL.
Furthermore, the unicode layer is not 100% bug-free.
-- 
Jan-Eric Duden
"Burton Radons" <loth@users.sourceforge.net> wrote in message
news:bvm5ud$1sam$1@digitaldaemon.com...
> 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 05, 2004
Re: D strings
On Tue, 03 Feb 2004 21:33:24 +0100, Luna Kid wrote:

[...]
> 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...

I disagree.

Example:
| printf("%u\n", cast(int) d);

As you can see, the intention of the cast is wrong, if your true intention
is to print an unsigned. However, if this is your declaration of d:
| struct data { real value;} data d;

the compiler would nicely tell you:
| e2ir: cannot cast from data to int

So long.
February 06, 2004
Re: D strings
if your true intention is to print unsigned, then your cast is simply wrong.
a logical coding error. as such, they can only be caught by you. but thats
the case where ever you do something wrong.

this code documents: i want to print a %u of d as an int. if thats not what
you wanated, then you made the fault.

nobody can prevent you from typing stuff that doesn't make sence, right? :D


"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag
news:bvui81$17e6$1@digitaldaemon.com...
> On Tue, 03 Feb 2004 21:33:24 +0100, Luna Kid wrote:
>
> [...]
> > 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...
>
> I disagree.
>
> Example:
> | printf("%u\n", cast(int) d);
>
> As you can see, the intention of the cast is wrong, if your true intention
> is to print an unsigned. However, if this is your declaration of d:
> | struct data { real value;} data d;
>
> the compiler would nicely tell you:
> | e2ir: cannot cast from data to int
>
> So long.
>
February 06, 2004
Re: D strings
On Fri, 06 Feb 2004 09:43:00 +0100, davepermen wrote:

> if your true intention is to print unsigned, then your cast is simply wrong.

I wrote that.

> a logical coding error. as such, they can only be caught by you. but
> thats the case where ever you do something wrong.

Why? If the format string for printf would be type checked, it would be as
easy for the compiler as for us to see the type violation. 

> this code documents: i want to print a %u of d as an int. if thats not
> what you wanated, then you made the fault.

Correct. And that is also true for assembler and the like. But why should
compilers then produce error messages at all? All I wanted to give notice
to is, that it is not always bad to write down an intent as an explicit
cast. The compiler does not always force a wrong intention through its
guts.

Moreover:
| struct data {uint v;} data d;
| [...]
| printf("%u\n", d); // print unsigned d

has not only a completely superfluos and wrong comment, that may prevent a
reviewer from detecting the error, but also prints the desired result, as
long, as the compiler decides that in the physical layout of `data' the
`v' field is put first.

Whereas the correct explicit cast to `uint' would uncover the forgotten
`.v' in the parameter list of `printf'  


> nobody can prevent you from typing stuff that doesn't make sence, right?
> :D

:-) very true. But should D be a language where everything makes sense?

So long.
February 06, 2004
Re: D strings
>if your true intention is to print unsigned, then your cast is simply wrong.
>a logical coding error. as such, they can only be caught by you. but thats
>the case where ever you do something wrong.

If an error can be detected at compiletime it should be, as these errors are
easy to fix. This is a case where the compiler should detect an error, but the
function you use (printf) is bad desigend, so the compiler is unabled to to what
he should do.

This is a design error.




>nobody can prevent you from typing stuff that doesn't make sence, right? :D

Rigth. I could write

int main ()
{
bla bla bla bla bla bla bla bla bla bla bla bla bla bla;
}


But the compiler will tell me that I've done something without sense. And I
think that's what the compiler should do.
February 06, 2004
Re: D strings
In article <bvvtme$big$1@digitaldaemon.com>, Matthias Becker says...
>
>If an error can be detected at compiletime it should be, as these 
>errors are easy to fix. This is a case where the compiler should 
>detect an error, but the function you use (printf) is bad desigend, 
>so the compiler is unabled to to what he should do.
>
>This is a design error.

True. Especially when printf is used in D. But printf has been
with us since the inception of C, and at that time it was 
considered good design. (Remember that C never was a Computer
Language, rather it was an Architecture Independent Assembler
On Steroids. And should still be considered as such, IMnsHO.)

So, it's allright to discuss catching programmer errors -- as
long as printf is not mentioned (because this is an exception 
in D). And it is allright to discuss the badness of printf --
as long as the discussion is just about printf. But we should
not mix the two issues.

IIRC, Walter would welcome either a rewrite of printf into D,
(be it preserving the current syntax but introducing type
checking etc.) or a totally different solution, as long as it
proves equally effective, flexible, and not too distasteful
for old C programmers.

The problem is that this has been considered an enormous 
project. And we do have more pressing things to do in D.
February 06, 2004
Re: D strings
it's not a bug of casting or anything. it's just the bad design of printf.

we're hard working on motivating walter to extend the language to finally
get a real replacement.

printf is shit. it will always be.

"Manfred Nowak" <svv1999@hotmail.com> schrieb im Newsbeitrag
news:bvvsgh$9se$1@digitaldaemon.com...
> On Fri, 06 Feb 2004 09:43:00 +0100, davepermen wrote:
>
> > if your true intention is to print unsigned, then your cast is simply
wrong.
>
> I wrote that.
>
> > a logical coding error. as such, they can only be caught by you. but
> > thats the case where ever you do something wrong.
>
> Why? If the format string for printf would be type checked, it would be as
> easy for the compiler as for us to see the type violation.
>
> > this code documents: i want to print a %u of d as an int. if thats not
> > what you wanated, then you made the fault.
>
> Correct. And that is also true for assembler and the like. But why should
> compilers then produce error messages at all? All I wanted to give notice
> to is, that it is not always bad to write down an intent as an explicit
> cast. The compiler does not always force a wrong intention through its
> guts.
>
> Moreover:
> | struct data {uint v;} data d;
> | [...]
> | printf("%u\n", d); // print unsigned d
>
> has not only a completely superfluos and wrong comment, that may prevent a
> reviewer from detecting the error, but also prints the desired result, as
> long, as the compiler decides that in the physical layout of `data' the
> `v' field is put first.
>
> Whereas the correct explicit cast to `uint' would uncover the forgotten
> `.v' in the parameter list of `printf'
>
>
> > nobody can prevent you from typing stuff that doesn't make sence, right?
> > :D
>
> :-) very true. But should D be a language where everything makes sense?
>
> So long.
February 06, 2004
Re: D strings
> it's not a bug of casting or anything. it's just the bad design of printf.
>
> we're hard working on motivating walter to extend the language to finally
> get a real replacement.
>
> printf is shit. it will always be.

What a ludicrous statement. Is assembler shit? Is void* shit? Is goto shit?
Are pointers shit? Are break/continue shit? Is for shit?

If it's shit, can you explain why Walter and others (myself included) find
it easy to use, and *very* rarely make errors using it?

Maybe it's a tool, which, as with all others, have pros and cons. Once
you've grokked it, you avoid the cons and experience only the pros. And the
pros of printf are considerable, which is why half the C-language family
programming community prefer it over all the alternatives.

How is any of what I'm saying not obvious to anyone/everyone?

(Shakes his head in despair ...)
February 06, 2004
Re: D strings
Matthew wrote:
...
>>printf is shit. it will always be.
> 
> What a ludicrous statement. Is assembler shit? Is void* shit? Is goto shit?
> Are pointers shit? Are break/continue shit? Is for shit?

Maybe he just meant that printf can make a mess in the wrong hands, and 
most of our wouldn't want to use printf as a salad topping.

> If it's shit, can you explain why Walter and others (myself included) find
> it easy to use, and *very* rarely make errors using it?
> 
> Maybe it's a tool, which, as with all others, have pros and cons. Once
> you've grokked it, you avoid the cons and experience only the pros. And the
> pros of printf are considerable, which is why half the C-language family
> programming community prefer it over all the alternatives.
> 
> How is any of what I'm saying not obvious to anyone/everyone?
> 
> (Shakes his head in despair ...)

-- 
Justin
http://jcc_7.tripod.com/d/
February 06, 2004
Re: D strings
davepermen wrote:

>it's not a bug of casting or anything. it's just the bad design of printf.
>
>we're hard working on motivating walter to extend the language to finally
>get a real replacement.
>
>printf is shit. it will always be.
>  
>
Maybe - but it's dam - useful particularly because of non-type-safety.  
But a type safe printf (as well) would be useful.

-- 
-Anderson: http://badmama.com.au/~anderson/
1 2 3
Top | Discussion index | About this forum | D home