www.digitalmars.com         C & C++   DMDScript  

D - D strings

reply imr1984 <imr1984_member pathlink.com> writes:
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 ?
Feb 02 2004
parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Feb 02 2004
next sibling parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Feb 02 2004
parent reply imr1984 <imr1984_member pathlink.com> writes:
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.
Feb 02 2004
parent reply Vathix <vathix dprogramming.com> writes:
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
Feb 02 2004
parent reply imr1984 <imr1984_member pathlink.com> writes:
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
Feb 02 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
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.
Feb 03 2004
parent reply "Luna Kid" <lunakid neuropolis.org> writes:
"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.
Feb 03 2004
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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.
Feb 05 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
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.
Feb 06 2004
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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.
Feb 06 2004
parent reply "davepermen" <davepermen hotmail.com> writes:
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.
Feb 06 2004
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 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 ...)
Feb 06 2004
next sibling parent J C Calvarese <jcc7 cox.net> writes:
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/
Feb 06 2004
prev sibling parent reply "davepermen" <davepermen hotmail.com> writes:
how outdated do you have to be? this is D, not assembler. this is a language
wich promotes type savety, ease of use, genericy, extendability, etc. none
of these exist in printf, and besides that, printf has much too much runtime
overhead for most tasks.

it is a tool yes. it can be used yes. doesn't make it good by any means. its
an improper tool, its an unsave tool, its a slow tool, a proprietary tool, a
monolithic tool, a non-type aware tool, etc.

it's about the worst piece of software existing in D and in c++. it has, in
both languages, no place to exist.

it was nice in c, yes. possibly.

the reason walter included it, is because at the start, D wasn't able to do
much more than calling functions (it's the first thing you have to get
working if you write a compiler), and printf is a function, you can rip the
source (he works at digital mars, he HAS the source for printf), and just
reuse it.

it was easy to insert. THATS why he used it. he even stated that. he knows
by himself it's shit.

"Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
news:c0182c$2k6g$1 digitaldaemon.com...

 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 ...)
Feb 06 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
First, _you_ brought the invective into this by saying printf() is shit.

There are few flaws in printf() you could posit that I would not
acknowledge, and I neither maintain that it's great, nor superb, nor a model
of IO (or O) perfection. But to say that it is shit is ludicrous, and makes
you look like a fool.

More importantly, your characterisation doesn't help the ever increasing
numbers of people who are joining this group and getting interested in D,
many of whom may not be from C or C++, but will be inclined to wonder about
the whole quality of D if the (current) default output mechanism is shit.

Can I ask what modernity's got to do with anything? Are you saying that only
new things are good, and all chronological advances mark advances in
quality? If that's the case, why didn't Java become the pre-eminent language
of our time, as it was very "new" 7 or 8 years ago? If that's your criterion
for success, you need to stop software engineering and take up marketing.

Perhaps a better set of criteria would be Efficient, Robust, Maintainable
and Easy-to-use? What do you think? Given that, we should perhaps look at
printf() again with a considered mind.

Efficient? It's not the fastest thing in the world, to be sure, but it beats
the pants off the IOStreams. It's far from the zenith of performance. A
couple of years ago I had a "debate" with an ardent C programmer who said it
was impossible to write a type-safe, generic, streaming mechanism (in C++;
his challenge) that would outperform C streams. Needless to say I proved him
wrong. But since we don't currently have any alternative in D the efficiency
issue is moot.

Robust? This depends on your experience and perspective. IIRC sometime in
the last several months Walter asserted that he no longer makes mistakes
with printf()-family format specifiers. I can tell you that I don't either
(in C and C++); and I've only done the %s / %.*s mistake twice in my 2 years
of D. Maybe we're lying? That's up to you to decide. But if we're not, then
perhaps the robustness (or lack thereof) of printf() is, as I said in my
previous post, dependent on point of view. People crap on about Java being
far more robust than C++. Three years ago I had the unpleasant role of
Software Quality Manager for a group of Java developers working on an
internet banking product, already 12 months running past deadline when I was
recruited. I can tell you that I've never seen worse code or more dangerous
and fragile implementation (on all scales, from the individual function all
the way up to the system architecture) in any language, including my first
job in a team doing ISDN server development in assembler/C that had
conditional compilation for 13 targets over 4 different hardware
architectures.

Maintainable? printf() scores low on the maintainability scale. Maybe that
makes it shit? But what is maintainable? The IOStreams? You'll have to do
better than that.

Easy-to-use? It is ridiculously easy to use for 90% of one's requirements.
For the other 10% it can be quite vexing. Does that make it shit? It's no
harder (and in my opinion *far* easier) than the IOStreams for all those
weird border-case formatting stuff.


If you are dissatisfied with the current situation, and want us all to use
something better, then write it. If it's fast, robust, maintainable and
easy-to-use, I'll be the first one to swap over. Just make sure it's not
shit, as we wouldn't want to put off any more new users, would we?



"davepermen" <davepermen hotmail.com> wrote in message
news:c01dch$2t61$1 digitaldaemon.com...

 how outdated do you have to be? this is D, not assembler. this is a


language

 wich promotes type savety, ease of use, genericy, extendability, etc. none
 of these exist in printf, and besides that, printf has much too much


runtime

 overhead for most tasks.

 it is a tool yes. it can be used yes. doesn't make it good by any means.


its

 an improper tool, its an unsave tool, its a slow tool, a proprietary tool,


a

 monolithic tool, a non-type aware tool, etc.

 it's about the worst piece of software existing in D and in c++. it has,


in

 both languages, no place to exist.

 it was nice in c, yes. possibly.

 the reason walter included it, is because at the start, D wasn't able to


do

 much more than calling functions (it's the first thing you have to get
 working if you write a compiler), and printf is a function, you can rip


the

 source (he works at digital mars, he HAS the source for printf), and just
 reuse it.

 it was easy to insert. THATS why he used it. he even stated that. he knows
 by himself it's shit.

 "Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
 news:c0182c$2k6g$1 digitaldaemon.com...

 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 ...)
Feb 06 2004
parent reply "Jan-Eric Duden" <jeduden whisset.com> writes:
Somehow, I have the impression that people either love printf or hate it. :)

I have a suggestion:
How about allowing printf as long as it is needed by the community? Nobody
forces you to use it.
IF someone comes up with something better than printf the majority
will use and printf will be ignored and forgotten.
Then Walter could have the compiler generate a warning that printf is
deprecated
and they should use something else. And of course, there should be a way to
disable the warning.

On the other hand, IF printf is still around after several years,
then I guess it has its place in a modern type-safe language such as D.

-- 
Jan-Eric Duden
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:c01lqi$btq$1 digitaldaemon.com...

 First, _you_ brought the invective into this by saying printf() is shit.

 There are few flaws in printf() you could posit that I would not
 acknowledge, and I neither maintain that it's great, nor superb, nor a


model

 of IO (or O) perfection. But to say that it is shit is ludicrous, and


makes

 you look like a fool.

 More importantly, your characterisation doesn't help the ever increasing
 numbers of people who are joining this group and getting interested in D,
 many of whom may not be from C or C++, but will be inclined to wonder


about

 the whole quality of D if the (current) default output mechanism is shit.

 Can I ask what modernity's got to do with anything? Are you saying that


only

 new things are good, and all chronological advances mark advances in
 quality? If that's the case, why didn't Java become the pre-eminent


language

 of our time, as it was very "new" 7 or 8 years ago? If that's your


criterion

 for success, you need to stop software engineering and take up marketing.

 Perhaps a better set of criteria would be Efficient, Robust, Maintainable
 and Easy-to-use? What do you think? Given that, we should perhaps look at
 printf() again with a considered mind.

 Efficient? It's not the fastest thing in the world, to be sure, but it


beats

 the pants off the IOStreams. It's far from the zenith of performance. A
 couple of years ago I had a "debate" with an ardent C programmer who said


it

 was impossible to write a type-safe, generic, streaming mechanism (in C++;
 his challenge) that would outperform C streams. Needless to say I proved


him

 wrong. But since we don't currently have any alternative in D the


efficiency

 issue is moot.

 Robust? This depends on your experience and perspective. IIRC sometime in
 the last several months Walter asserted that he no longer makes mistakes
 with printf()-family format specifiers. I can tell you that I don't either
 (in C and C++); and I've only done the %s / %.*s mistake twice in my 2


years

 of D. Maybe we're lying? That's up to you to decide. But if we're not,


then

 perhaps the robustness (or lack thereof) of printf() is, as I said in my
 previous post, dependent on point of view. People crap on about Java being
 far more robust than C++. Three years ago I had the unpleasant role of
 Software Quality Manager for a group of Java developers working on an
 internet banking product, already 12 months running past deadline when I


was

 recruited. I can tell you that I've never seen worse code or more


dangerous

 and fragile implementation (on all scales, from the individual function


all

 the way up to the system architecture) in any language, including my first
 job in a team doing ISDN server development in assembler/C that had
 conditional compilation for 13 targets over 4 different hardware
 architectures.

 Maintainable? printf() scores low on the maintainability scale. Maybe that
 makes it shit? But what is maintainable? The IOStreams? You'll have to do
 better than that.

 Easy-to-use? It is ridiculously easy to use for 90% of one's requirements.
 For the other 10% it can be quite vexing. Does that make it shit? It's no
 harder (and in my opinion *far* easier) than the IOStreams for all those
 weird border-case formatting stuff.


 If you are dissatisfied with the current situation, and want us all to use
 something better, then write it. If it's fast, robust, maintainable and
 easy-to-use, I'll be the first one to swap over. Just make sure it's not
 shit, as we wouldn't want to put off any more new users, would we?



 "davepermen" <davepermen hotmail.com> wrote in message
 news:c01dch$2t61$1 digitaldaemon.com...

 how outdated do you have to be? this is D, not assembler. this is a


 language

 wich promotes type savety, ease of use, genericy, extendability, etc.




none

 of these exist in printf, and besides that, printf has much too much


 runtime

 overhead for most tasks.

 it is a tool yes. it can be used yes. doesn't make it good by any means.


 its

 an improper tool, its an unsave tool, its a slow tool, a proprietary




tool,

 a

 monolithic tool, a non-type aware tool, etc.

 it's about the worst piece of software existing in D and in c++. it has,


 in

 both languages, no place to exist.

 it was nice in c, yes. possibly.

 the reason walter included it, is because at the start, D wasn't able to


 do

 much more than calling functions (it's the first thing you have to get
 working if you write a compiler), and printf is a function, you can rip


 the

 source (he works at digital mars, he HAS the source for printf), and




just

 reuse it.

 it was easy to insert. THATS why he used it. he even stated that. he




knows

 by himself it's shit.

 "Matthew" <matthew.hat stlsoft.dot.org> schrieb im Newsbeitrag
 news:c0182c$2k6g$1 digitaldaemon.com...

 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 ...)
Feb 07 2004
parent reply "MikkelFJ" <mikkel dvideNOSPAMDOT.com> writes:
"Jan-Eric Duden" <jeduden whisset.com> skrev i en meddelelse
news:c02fd4$27fr$1 digitaldaemon.com...

 Somehow, I have the impression that people either love printf or hate it.


:)

...
 On the other hand, IF printf is still around after several years,
 then I guess it has its place in a modern type-safe language such as D.


If you can call vargs with C linkage from D, you can just use the C std
library or some support C library could be added for D. In this way printf
will be available if you link with it.

As for a typesafe variant of printf: I haven't given it a lot of thought in
the context of D, however, I think it is perfectly doable to provide at
least runtime safety such that you get an exception if there is no valid
conversion. It may require special compiler support but then this is
probably the one construct where it is worthwhile.

If you require the formatting string to be a constant, the compiler can
typecheck all arguments in advance, effectively rolling a new printf
function each time it is called:

printf("hello %s world", "nice");
==>
printf("hello nice world"); // compile time substitution

printf("hello %s world", 1+1);
==>
printf("hello %s world", int_to_string(1+1)); // runtime conversion
printf("hello 2 world"); // or compile time conversion if possible


Having special compiler support allows for highly efficient code generation
because you do not need to parse the formatting string at runtime.

In case where the formatting string is not a constant, a slower version can
be called that does typeconversion to the formatting string on the fly with
possible exceptions for missing arguments or arguments with no conversion -
or perhaps such a construct is simply not permitted.






This is just a more convenient version of the above.

Mikkel
Feb 07 2004
parent "davepermen" <davepermen hotmail.com> writes:
the problem with this is, it means certain functions get special treatment.
this is unfair (an own printf would not work as fast then, and would not get
typechecking).

premature optimisation.

drop printf.

iostreams are much bether. the c++ version are rather bad implemented, but
you can do much bether if you want. but they are

faster
more robust
typesave
scalable

but anyways. some people are rather braindump sticking with printf praising
it as some holy grail. since 10 years people know its simply shit. but we
never get rid of it, as a lot simply let it stay alive. for what? for
nothing.

"MikkelFJ" <mikkel dvideNOSPAMDOT.com> schrieb im Newsbeitrag
news:c039q0$fs1$1 digitaldaemon.com...

 "Jan-Eric Duden" <jeduden whisset.com> skrev i en meddelelse
 news:c02fd4$27fr$1 digitaldaemon.com...

 Somehow, I have the impression that people either love printf or hate




it.

 :)

...
 On the other hand, IF printf is still around after several years,
 then I guess it has its place in a modern type-safe language such as D.


 If you can call vargs with C linkage from D, you can just use the C std
 library or some support C library could be added for D. In this way printf
 will be available if you link with it.

 As for a typesafe variant of printf: I haven't given it a lot of thought


in

 the context of D, however, I think it is perfectly doable to provide at
 least runtime safety such that you get an exception if there is no valid
 conversion. It may require special compiler support but then this is
 probably the one construct where it is worthwhile.

 If you require the formatting string to be a constant, the compiler can
 typecheck all arguments in advance, effectively rolling a new printf
 function each time it is called:

 printf("hello %s world", "nice");
 ==>
 printf("hello nice world"); // compile time substitution

 printf("hello %s world", 1+1);
 ==>
 printf("hello %s world", int_to_string(1+1)); // runtime conversion
 printf("hello 2 world"); // or compile time conversion if possible


 Having special compiler support allows for highly efficient code


generation

 because you do not need to parse the formatting string at runtime.

 In case where the formatting string is not a constant, a slower version


can

 be called that does typeconversion to the formatting string on the fly


with

 possible exceptions for missing arguments or arguments with no


conversion -

 or perhaps such a construct is simply not permitted.






 This is just a more convenient version of the above.

 Mikkel
Feb 07 2004
prev sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
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/
Feb 06 2004
prev sibling parent reply Matthias Becker <Matthias_member pathlink.com> writes:
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.
Feb 06 2004
parent Georg Wrede <Georg_member pathlink.com> writes:
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.
Feb 06 2004
prev sibling parent reply Patrick Down <Patrick_member pathlink.com> writes:
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.
Feb 02 2004
parent reply Burton Radons <loth users.sourceforge.net> writes:
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.
Feb 02 2004
parent "Jan-Eric Duden" <jeduden whisset.com> writes:
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.
Feb 04 2004