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.

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.

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


 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


 we're hard working on motivating walter to extend the language to


 get a real replacement.

 printf is shit. it will always be.

What a ludicrous statement. Is assembler shit? Is void* shit? Is goto

 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

 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

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

 overhead for most tasks.

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

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

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

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

 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

 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

 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


 we're hard working on motivating walter to extend the language to


 get a real replacement.

 printf is shit. it will always be.

What a ludicrous statement. Is assembler shit? Is void* shit? Is goto

 Are pointers shit? Are break/continue shit? Is for shit?

 If it's shit, can you explain why Walter and others (myself included)


 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

 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

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

 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

 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

 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

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

 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

 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

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

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

 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

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

 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

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

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

 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

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


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

 overhead for most tasks.

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

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


 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,

 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

 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

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


 reuse it.

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


 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


 we're hard working on motivating walter to extend the language to


 get a real replacement.

 printf is shit. it will always be.

What a ludicrous statement. Is assembler shit? Is void* shit? Is goto

 Are pointers shit? Are break/continue shit? Is for shit?

 If it's shit, can you explain why Walter and others (myself included)


 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.



 the
 pros of printf are considerable, which is why half the C-language



 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. You could of course also support embedded expressions as in Ruby and C# printf("hello #{2+2}"); // conversion to string printf("hello #%x{2+2}"); // conversion according to specified formatter 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


 :)
...
 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

 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

 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

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

 possible exceptions for missing arguments or arguments with no

 or perhaps such a construct is simply not permitted.

 You could of course also support embedded expressions as in Ruby and C#

 printf("hello #{2+2}"); // conversion to string
 printf("hello #%x{2+2}"); // conversion according to specified formatter

 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.
  

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




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