"Walter" <walter@digitalmars.com> wrote in message news:b9v38i$30qd$1@digitaldaemon.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.

But that's slower (as has been pointed out) since you first have to convert your type to the string, then print the string.  It forces the intermediate data into memory, for one thing.  But not in its final resting place, in a temporary buffer.  It then has to be moved.

Besides then you need a separate object.tostring() property for every type,
anyway.  Or is it .toString()?  I forget.

It wouldn't always necessarily be slower to make the string first.  The CPU data cache will help alot.  I don't have a firm argument here.

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

I just wanted to get that on record.  ;)

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

Hmm.  I gotta admit to not being terribly familiar with D's standard library yet.

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

I guess I should.

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

And those are two bytes each, indexing into an additional array of real pointers to typeinfo's for each type in the program, each of which is four bytes.  That's competitive with printf, surely.  Format specifiers are at least 2 bytes, don't forget the trailing NUL.

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

And you know that 90% of the time gets spent in 10% of the code.  Well, 50% or so percent of the ram gets spent on 50% of the data structures as well. If you want to save ram you may be able to get the savings elsewhere.  If that's what it takes to get good semantics, ease of use, and extensibility, I'm willing to sacrifice a couple of CPU cycles or a couple of bytes.

btw 80% of programmer time is dealing with 20% of the crufty codebase consisting of ugly inelegant hacks and riddled with nightmarish bugs and memory leaks.  And 98.75% of statistics are bullshit.

I do have one more argument:  How do you put a color change into a result of a .tostring() operation?  ANSI escape codes?  Then you have to modify the backend processor to.  Done as a mutator it merely requires a flush then a direct color change.  If it's auto it could change color back when it goes out of scope.

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

Then you're surely aware of the above "statistic".   ;)

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

Then I definitely _must_ research it.

Sean

You get into trouble with portability if you read directly into structs.  Be careful.  And parsing takes time;  we find it to be significantly impacting our game's load times.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b9v38j$30qd$2@digitaldaemon.com...
>
> "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.

Good answer!

Sean

"Walter" <walter@digitalmars.com> wrote in message news:b9v38j$30qd$3@digitaldaemon.com...
>
> "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.

Walter wrote:
> 
> "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.

That's that best way, but it's sometimes not general enough. (You can't analyze Apache access logs this way, because you don't want to burden your server with e.g. 5-50 MB of RAM usage)

This is a Windows / Unix issue. Unix has so efficient text file handling that you won't win a cent reading whole files. In fact using Perl it turned out to be the slower method although it is widely used as an optimization method.

If you "think client" (Windwos) you don't care about memory usage, because you own your machine and any free RAM buys you nothing, but if you "think server" (Unix) any memory or resource used by one process is lost for the other users.

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

I didn't mean that, I meant I read it into one array of bytes. Then I parse or cut it up as needed.

"Sean L. Palmer" <palmer.sean@verizon.net> wrote in message news:b9v9kp$5op$1@digitaldaemon.com...
> You get into trouble with portability if you read directly into structs.
Be
> careful.  And parsing takes time;  we find it to be significantly
impacting
> our game's load times.
>
> Sean
>
> "Walter" <walter@digitalmars.com> wrote in message news:b9v38j$30qd$2@digitaldaemon.com...
> >
> > "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.
>
>

"Helmut Leitner" <helmut.leitner@chello.at> wrote in message news:3EC32F66.732C71E5@chello.at...
> Walter wrote:
> > "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.
> That's that best way, but it's sometimes not general enough. (You can't analyze Apache access logs this way, because you don't want to burden your server with e.g. 5-50 MB of RAM usage)

Not necessary - use memory mapped files!


> This is a Windows / Unix issue. Unix has so efficient text file handling that you won't win a cent reading whole files. In fact using Perl it turned out to be the slower method although it is widely used as an optimization method.

I can see how that can happen because if you're reading the entire file in one gulp, you cannot do any processing until the entire file is read in. If buffered, you can start working on the file while the OS anticipates you wanting the rest and reads it in. (In such cases, I'd switch to memory mapped files which brings things back to par.) In any case, I find reading the file in one operation to not only be faster, but LESS code to write and fewer errors to check for and recover from.


> If you "think client" (Windwos) you don't care about memory usage, because you own your machine and any free RAM buys you nothing, but if you "think server" (Unix) any memory or resource used by one process is lost for the other users.

Point taken. But I'll counter that many C programs spend a lot of time allocating memory for strings parsed out of files and then copying those strings byte by byte. I just point into the file buffer. If you're clever you can avoid making any dirty pages and get some really screaming code.