View mode: basic / threaded / horizontal-split · Log in · Help
February 10, 2005
std.printf
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.
February 10, 2005
Re: std.printf
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
February 10, 2005
Re: std.printf
>> 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?
February 10, 2005
Re: std.printf
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
February 10, 2005
Re: std.printf
> 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.
Top | Discussion index | About this forum | D home