Sean L. Palmer wrote:
*snip*
>>>The main problems with printf are:
>>>
>>>It's not extensible
>>
>>Yup.
> 
> 
> This means you can't add your own formatting commands.  You can't make it
> handle new types.

One could always simply add a %o command, which would assume an object reference, and use its toString method to string-ize it.  voila.

>>>It's not typesafe
>>
>>I've been using printf for 20 years and this just hasn't been an issue.

This has kicked me in the pants a few times, most notably when I wanted to print out an integer to some log file or other, and used %s due to a brain-fart.  blech

> Lucky you.  You will admit however that it is not type safe?  Personal
> issues aside, just a simple yes or no.
> 
> 
>>>It's not retargetable
>>
>>Not sure what you mean.
> 
> 
> Meaning you can't printf to anything you want.  You also have to know the
> size of the buffer before you call, for sprintf.  This is tedious.  It's
> another aspect of not being extensible, but on the back end.

A sprintf derivant could be coded for D to return a char[] or wchar[]. Either that or use the stream classes; they have printf methods, and can be directed around freely.

> It would seriously pay to concentrate on making a truly elegant, *usable*
> I/O foundation for D.  Most of the work can be done by someone here, there
> are people willing to code I/O libraries, but some of the functionality
> needs to be in the language itself, and its early implementations.

I rather like the monad solution, using self-reference-returning methods (or overloaded operators) to specify the data to be formatted.

I'm not sure if this is the cause of C++ streams' purported bloat; if it's not, then I'm fresh out of reasons not to do it this way. :)

"Andy Friesen" <andy@ikagames.com> escribió en el mensaje
news:b9i862$23u0$1@digitaldaemon.com...
| ...
| This has kicked me in the pants a few times, most notably when I wanted
| to print out an integer to some log file or other, and used %s due to a
| brain-fart.  blech
| ...

I had a similar problem too (but with fscanf). Last year I was making a
university project in VC++. I had to read some nodes from a text file, but
at the beginning of the file I had how many nodes were. I accidently wrote
fscanf(file,"%s",&count) and continued like that. I was one day from the
dead-line and my program: 1) didn't work properly, and 2) took 10 minutes to
load! If I ran it twice, I got a "low virtual memory" message. The program
used MapObjects to load an AutoCad drawing, so I thought that could be the
reason. However, when I loaded the same drawing in VB, there was nothing
wrong. So I checked my code, there was that fatal line.
I know it's not exactly the same, but it kinda shows that, just as scanf,
printf can be dangerous sometimes.

-------------------------
Carlos Santander
"Andy Friesen" <andy@ikagames.com> escribió en el mensaje
news:b9i862$23u0$1@digitaldaemon.com...
| ...
| This has kicked me in the pants a few times, most notably when I wanted
| to print out an integer to some log file or other, and used %s due to a
| brain-fart.  blech
| ...

I had a similar problem too (but with fscanf). Last year I was making a
university project in VC++. I had to read some nodes from a text file, but
at the beginning of the file I had how many nodes were. I accidently wrote
fscanf(file,"%s",&count) and continued like that. I was one day from the
dead-line and my program: 1) didn't work properly, and 2) took 10 minutes to
load! If I ran it twice, I got a "low virtual memory" message. The program
used MapObjects to load an AutoCad drawing, so I thought that could be the
reason. However, when I loaded the same drawing in VB, there was nothing
wrong. So I checked my code, there was that fatal line.
I know it's not exactly the same, but it kinda shows that, just as scanf,
printf can be dangerous sometimes.

-------------------------
Carlos Santander

"Carlos Santander B." wrote:
> 
> "Andy Friesen" <andy@ikagames.com> escribió en el mensaje
> news:b9i862$23u0$1@digitaldaemon.com...
> | ...
> | This has kicked me in the pants a few times, most notably when I wanted
> | to print out an integer to some log file or other, and used %s due to a
> | brain-fart.  blech
> | ...
> 
> I had a similar problem too (but with fscanf)...

You violated one of the basic C rules: *never* use fscanf (use fgets, split according to separators, read the fields).

-- 
Helmut Leitner    leitner@hls.via.at
Graz, Austria   www.hls-software.com

What use is a function you can't use?

Sean

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EBD1659.C0E8144F@hls.via.at...
> > I had a similar problem too (but with fscanf)...
>
> You violated one of the basic C rules: *never* use fscanf (use fgets, split according to separators, read the fields).

"Andy Friesen" <andy@ikagames.com> wrote in message news:b9i862$23u0$1@digitaldaemon.com...
> Sean L. Palmer wrote:
> > This means you can't add your own formatting commands.  You can't make
it
> > handle new types.
>
> One could always simply add a %o command, which would assume an object reference, and use its toString method to string-ize it.  voila.

But if you convert to string first, it's less efficient than putting the characters directly into the stream.  What if your object has 4K or more worth of textual representation?

> > Meaning you can't printf to anything you want.  You also have to know
the
> > size of the buffer before you call, for sprintf.  This is tedious.  It's another aspect of not being extensible, but on the back end.
>
> A sprintf derivant could be coded for D to return a char[] or wchar[]. Either that or use the stream classes; they have printf methods, and can be directed around freely.

That's nice.  I need to look at Phobos streams again.

> I rather like the monad solution, using self-reference-returning methods (or overloaded operators) to specify the data to be formatted.

Operators are great for this.  They don't look as ugly and they don't require parenthesis.  Visually they don't get in the way as much as a method call would.

> I'm not sure if this is the cause of C++ streams' purported bloat; if it's not, then I'm fresh out of reasons not to do it this way. :)

Supposedly it's the individual calls to print individual things, instead of one call to print multiple things.

So put your I/O in a function and call those functions multiple times.  ;)

Sean

"Helmut Leitner" <leitner@hls.via.at> escribió en el mensaje
news:3EBD1659.C0E8144F@hls.via.at...
|
|
| "Carlos Santander B." wrote:
| >
| >
| > I had a similar problem too (but with fscanf)...
|
| You violated one of the basic C rules: *never* use fscanf
| (use fgets, split according to separators, read the fields).
|
| --
| Helmut Leitner    leitner@hls.via.at
| Graz, Austria   www.hls-software.com


Now I could do that, then I couldn't. I often go for the easiest way, even if they're not too good.

-------------------------
Carlos Santander


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.478 / Virus Database: 275 - Release Date: 2003-05-06

"Sean L. Palmer" wrote:
> 
> What use is a function you can't use?
> 

Not much use. A lot of C functions are like that.
There are functions that are tremendously useful while
others just don't live up to their potential.

> "Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EBD1659.C0E8144F@hls.via.at...
> > > I had a similar problem too (but with fscanf)...
> >
> > You violated one of the basic C rules: *never* use fscanf (use fgets, split according to separators, read the fields).


--
Helmut Leitner    leitner@hls.via.at Graz, Austria   www.hls-software.com

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9i48s$201b$1@digitaldaemon.com...
> > > The main problems with printf are:
> > > It's not extensible
> > Yup.
> This means you can't add your own formatting commands.  You can't make it handle new types.

Up to a point, you're right. That point is if you write wrappers for your new types that convert them to strings, and then printf a string.


> > > It's not typesafe
> > I've been using printf for 20 years and this just hasn't been an issue.
> Lucky you.  You will admit however that it is not type safe?  Personal issues aside, just a simple yes or no.

You are correct, it is not typesafe.


> > > It's not retargetable
> > Not sure what you mean.
> Meaning you can't printf to anything you want.  You also have to know the size of the buffer before you call, for sprintf.  This is tedious.  It's another aspect of not being extensible, but on the back end.

Check out outbuffer.printf. I believe it handilly resolves that issue, which is a nuisance problem.

> You've heard me bitching about not being able to redirect printf to OutputDebugString for a while now, haven't you?  I'd use fprintf if that would work, but it doesn't.  And there's no way to call the printf core without going thru sprintf, which destroys any buffering possibilities because you have to preallocate enough storage to guarantee it'll be sufficient.  What if sprintf runs out of room?  Oh, wait, there's
snprintf.
> If your vendor supports it.  There's no such thing as smallocprintf, but I suppose someone could figure out a way to make one.

Check out outbuffer.printf! I use that (and variants of it) all the time.

> > That depends on who you are! If you're doing embedded systems, code size
> is
> > still a big deal.
> We've already established that typesafe printf could be had for the same number of bytes as printf would take.  It would however require compiler support.

I thought we established that it would cost an extra vector of types for each printf.


> My gcc compiler for PS/2 is so sloppy, it outputs 4 32-bit NOP's in a row all over the place, just because it feels like it, evidently.  It's
supposed
> to be an optimized build.

I won't make any excuses for that <g>.


> With that kind of overhead who would notice a few
> extra parms pushed or a few extra calls?

I would. I've been paid many times based on my ability to write small/fast code.

>  It's not like printf needs to be
> especially fast;  it's either printing to screen (limited by human
> perception) or disk (limited by mechanical processes), so fprintf probably
> spends most of its time waiting on the OS to flush the buffers.

printf does need to be fast. You'd be amazed how many benchmarks are throttled by it and used (rightly or wrongly) for customer buy decisions. I've many times almost sat down and recoded the entire ugly thing in assembler. In fact, a competitor of mine did so for printf and thereby was able to cover for their poor code generation.


> It would seriously pay to concentrate on making a truly elegant, *usable* I/O foundation for D.  Most of the work can be done by someone here, there are people willing to code I/O libraries, but some of the functionality needs to be in the language itself, and its early implementations.

I agree. Though I think outbuffer can handle quite a bit.

"Helmut Leitner" <leitner@hls.via.at> wrote in message news:3EBD1659.C0E8144F@hls.via.at...
> You violated one of the basic C rules: *never* use fscanf (use fgets, split according to separators, read the fields).

LOL. I never use either. I always read the file in one read operation, then parse it.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9ji54$dil$1@digitaldaemon.com...
> What use is a function you can't use?

Support legacy code.