www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.printf

reply "Charlie Patterson" <charliep1 excite.com> writes:
I want to say first that I'm really impressed with D.  I found it at 
Slashdot about 6 months ago or so and I remembered it all this time.  Just 
found it again as I'm pretty tired of C++ and refuse to learn Java.  So I 
hope to have a few *constructive* things to say here.  I hope I'm not 
nitpicking.

As I read the docs I can find on D, I was imagining introducing it at work 
as a great arbitrator between the complexity of C++ and the ideology of 
Java.  I think it is time for prudent garbage collection (selectably) and I 
think it is time for any work-horse language to have a fully-functional, 
first-class string.  But I don't like the "everything is an object" 
mentality and I think it shows a lack of "engineering prowess" on the part 
of its rabid Java fans.  (am I pissing anyone off? :-))

The idea of connecting to any C library was also awesome and very important. 
What a clever way to avoid full backwards compatability (like C++) while 
also allowing the use of 15 year old code bases!

So for my first "complaint"...

I understand using old C libraries, especially ones for esoteric things and 
in-house libraries, but I'm not so sure about std.c.stdio and std.c.stdlib. 
This is the first D code that shocked me:

    return strcmp(std.string.toCharz(s), "foo\0");
    printf("my string is: %.*s\n", string);

So, if I understand, it will be common practice to use printf and then 
require either "%.*s" or "foo"~"\0".  Ouch!  This will be a huge source of 
forgetful bugs.  And yet I love printf as much as the next person.  (The 
above is also approaching the hard to read category of coding.)  This is the 
first time I felt like NOT showing D to colleagues, I hate to say.

A possible solution might be a std.printf.  It would recreate these 
important c functions in a way that is D safe.  (Again, C backwards 
compatibility is awesome, but we wouldn't have to be ideological in it's 
application.)  Yeah, I don't love this implementation either but it might be 
worth a debate.  I like the idea of having printf, of course, but 
"std.print" might get confused with "std.c.printf" while the newbie stares 
at it for an hour wondering what went wrong.

Would it possible to force a c.printf() for functions in std.c.stdio?  Then 
printf() would be the new D version.
Feb 10 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Charlie Patterson wrote:

 A possible solution might be a std.printf.  It would recreate these 
 important c functions in a way that is D safe.  (Again, C backwards 
 compatibility is awesome, but we wouldn't have to be ideological in it's 
 application.)  Yeah, I don't love this implementation either but it might be 
 worth a debate.  I like the idea of having printf, of course, but 
 "std.print" might get confused with "std.c.printf" while the newbie stares 
 at it for an hour wondering what went wrong.

 Would it possible to force a c.printf() for functions in std.c.stdio?  Then 
 printf() would be the new D version.

You need to look up the new writef function. It is the D version of printf, and then some. It's located in std.stdio. "sprintf" is in std.format. --anders
Feb 10 2005
parent reply "Charlie Patterson" <charliep1 excite.com> writes:
 Would it possible to force a c.printf() for functions in std.c.stdio? 
 Then printf() would be the new D version.


Oops. Everytime I wrote std.c.printf I meant std.c.stdio and when I wrote std.printf I meant std.stdio as a replacement.
 You need to look up the new writef function.
 It is the D version of printf, and then some.

Sounds good. But my concern is that there are lots of C functions that use C strings and also have a lot of mental stickiness. You renamed printf to writef for this case, but what about strcpy, fopen, connect, etc? I could see converting people much more easily if somehow these names stayed and also behaved well with D strings. (And there would be a lot less bugs.) Maybe the C libraries could somehow require c. prepended if there is also a D version of the string?
Feb 10 2005
parent =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Charlie Patterson wrote:

You need to look up the new writef function.
It is the D version of printf, and then some.

Sounds good. But my concern is that there are lots of C functions that use C strings and also have a lot of mental stickiness. You renamed printf to writef for this case, but what about strcpy, fopen, connect, etc? I could see converting people much more easily if somehow these names stayed and also behaved well with D strings. (And there would be a lot less bugs.)

D uses a lot of standard C functions... Usually in modules prefixed by an extra .c, such as std.c.stdio and std.c.stdlib i.e. std.stdio does a "import std.c.stdio;" std.zlib does "import etc.c.zlib"; and so on and so forth So the C standard library is required, and using external libraries usually just means doing a import module for D and linking to the standard C libraries, not rewriting it...
 Maybe the C libraries could somehow require c. prepended if there is also a 
 D version of the string?

The full module names can be used to separate, if conflicts ? All D strings can be casted to (char*), but you usually want to add a terminating NUL to it (and possibly convert encoding) --anders
Feb 10 2005
prev sibling parent Vathix <vathix dprogramming.com> writes:
 So for my first "complaint"...

 I understand using old C libraries, especially ones for esoteric things  
 and
 in-house libraries, but I'm not so sure about std.c.stdio and  
 std.c.stdlib.
 This is the first D code that shocked me:

     return strcmp(std.string.toCharz(s), "foo\0");
     printf("my string is: %.*s\n", string);

 So, if I understand, it will be common practice to use printf and then
 require either "%.*s" or "foo"~"\0".  Ouch!  This will be a huge source  
 of
 forgetful bugs.  And yet I love printf as much as the next person.  (The
 above is also approaching the hard to read category of coding.)  This is  
 the
 first time I felt like NOT showing D to colleagues, I hate to say.

 A possible solution might be a std.printf.  It would recreate these
 important c functions in a way that is D safe.  (Again, C backwards
 compatibility is awesome, but we wouldn't have to be ideological in it's
 application.)  Yeah, I don't love this implementation either but it  
 might be
 worth a debate.  I like the idea of having printf, of course, but
 "std.print" might get confused with "std.c.printf" while the newbie  
 stares
 at it for an hour wondering what went wrong.

 Would it possible to force a c.printf() for functions in std.c.stdio?   
 Then
 printf() would be the new D version.

The docs have a lot of really outdated stuff. toCharz() has been deprecated for ages. D now has a printf replacement called writef (and writefln) from std.stdio: writefln("my string is: %s", string); and it's type safe. You might also want to check out this page http://www.prowiki.org/wiki4d/wiki.cgi?ShortFrequentAnswers and other stuff from the wiki.
Feb 10 2005