February 04, 2004
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
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
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
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
>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
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
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
> 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
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
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/