Jump to page: 1 2
Thread overview
replacements for printf and scanf?
Jan 05, 2004
Nikita Proskourine
Jan 05, 2004
Matthew
Jan 05, 2004
Andy Friesen
Jan 05, 2004
kinghajj
Jan 05, 2004
Andy Friesen
Jan 05, 2004
Matthew
Jan 05, 2004
davepermen
Jan 05, 2004
Matthew
Jan 05, 2004
davepermen
Jan 05, 2004
Matthew
Jan 05, 2004
davepermen
Jan 05, 2004
Matthew
Jan 05, 2004
davepermen
Jan 05, 2004
Matthew
Jan 05, 2004
J Anderson
Jan 05, 2004
J Anderson
Jan 10, 2004
Georg Wrede
Jan 10, 2004
Ilya Minkov
January 05, 2004
D currently uses printf for printing strings. This has a number of
disadvantages:
1. Number of arguments is not validated.
2. Types of arguments are not validated.
3. Non-primitive types can't be printed.

The solution could be something in the style of Java, with overridable toString() in every object or in the style of C++ with << operators and streams. Or it could be some intrinsic feature of D.

scanf has the same type of problems.

Something should be done about it. What do you think?

Nikita.


January 05, 2004
It's a topic that comes up often. Those of us who don't have problems with printf - largely because we're recalcitrant old duffers who've had printf() instincts honed by long and unhappy experience - are content with the current situation. Those who do not are encouraged to propose an alternative that is neither unacceptably verbose or unacceptably slow. There's little doubt that D can support a good solution, so by all means have a go. :)

"Nikita Proskourine" <Nikita_member@pathlink.com> wrote in message news:btafe0$1sl$1@digitaldaemon.com...
> D currently uses printf for printing strings. This has a number of
> disadvantages:
> 1. Number of arguments is not validated.
> 2. Types of arguments are not validated.
> 3. Non-primitive types can't be printed.
>
> The solution could be something in the style of Java, with overridable toString() in every object or in the style of C++ with << operators and
streams.
> Or it could be some intrinsic feature of D.
>
> scanf has the same type of problems.
>
> Something should be done about it. What do you think?
>
> Nikita.
>
>


January 05, 2004
Nikita Proskourine wrote:
> D currently uses printf for printing strings. This has a number of
> disadvantages:
> 1. Number of arguments is not validated.
> 2. Types of arguments are not validated.
> 3. Non-primitive types can't be printed.
> 
> The solution could be something in the style of Java, with overridable
> toString() in every object or in the style of C++ with << operators and streams.
> Or it could be some intrinsic feature of D.
> 
> scanf has the same type of problems.
> 
> Something should be done about it. What do you think?
> 
> Nikita.

The trouble is implementing variable argument functions in a way that has no (or very little) runtime performance, and does not result in mounds of code. (either generated machine code, or source)

Many, *many* solutions to this have been proposed. (I like XL's approach the best)

 -- andy
January 05, 2004
printf() and scanf() are just fine IF u take the time to learn them! (though, I
do like std::cin for input...). printf() is better than std::cout (it's faster).


January 05, 2004
kinghajj wrote:

> printf() and scanf() are just fine IF u take the time to learn them! (though, I
> do like std::cin for input...). printf() is better than std::cout (it's faster).

printf is unsafe and has to do string parsing at runtime; cout is ugly. (subjective, I know)

Just about every other modern language on the face of the earth offers something that's better than either.  D should at least match them.

 -- andy
January 05, 2004
"Andy Friesen" <andy@ikagames.com> wrote in message news:btas77$m4k$1@digitaldaemon.com...
> kinghajj wrote:
>
> > printf() and scanf() are just fine IF u take the time to learn them!
(though, I
> > do like std::cin for input...). printf() is better than std::cout (it's
faster).
>
> printf is unsafe and has to do string parsing at runtime; cout is ugly.
> (subjective, I know)
>
> Just about every other modern language on the face of the earth offers something that's better than either.  D should at least match them.

I'm not aware of any language that offers an efficient alternative to
printf(). I look forward to seeing D be the first! :)


January 05, 2004
In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
>
>printf() and scanf() are just fine IF u take the time to learn them! (though, I
>do like std::cin for input...). printf() is better than std::cout (it's faster).
>
>
no, it's not


January 05, 2004
"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
> >
> >printf() and scanf() are just fine IF u take the time to learn them!
(though, I
> >do like std::cin for input...). printf() is better than std::cout (it's
faster).
> >
> >
> no, it's not

Not faster? I'd be very surprised if this was not true for the majority of test cases. Each output to cout has to go through significant locale management.



January 05, 2004
cout is buffered, printf not.

but technically, the design of the streams in c++ need less runtime work than printf.

they are as well typesave and extendable.

its true that cout itself is not that fast. but it has other reasons, _NOT_ the "multiple function calls are slow" ones.. reasons that wouldn't mather in D

In article <btb7aj$1ihl$1@digitaldaemon.com>, Matthew says...
>
>
>"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
>> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
>> >
>> >printf() and scanf() are just fine IF u take the time to learn them!
>(though, I
>> >do like std::cin for input...). printf() is better than std::cout (it's
>faster).
>> >
>> >
>> no, it's not
>
>Not faster? I'd be very surprised if this was not true for the majority of test cases. Each output to cout has to go through significant locale management.
>
>
>


January 05, 2004
> cout is buffered, printf not.

That's implementation-defined, and not a stipulated characteristic. In fact, printf is often implemented in terms of, or shares implementation with, fprintf (stderr).

> but technically, the design of the streams in c++ need less runtime work
than
> printf.

I don't find this credible. Have you implemented either/both, or equivalent functions?

> they are as well typesave and extendable.

No-one's contesting that. As with just about anything, the contest is between robustness and efficiency.

> its true that cout itself is not that fast. but it has other reasons,
_NOT_ the
> "multiple function calls are slow" ones.. reasons that wouldn't mather in
D

Disagree. There are several reasons for the high performance costs of the iostreams, only some of which pertain to the multiple calls.


> In article <btb7aj$1ihl$1@digitaldaemon.com>, Matthew says...
> >
> >
> >"davepermen" <davepermen_member@pathlink.com> wrote in message news:btb741$1hsd$1@digitaldaemon.com...
> >> In article <btaqtk$j8i$1@digitaldaemon.com>, kinghajj says...
> >> >
> >> >printf() and scanf() are just fine IF u take the time to learn them!
> >(though, I
> >> >do like std::cin for input...). printf() is better than std::cout
(it's
> >faster).
> >> >
> >> >
> >> no, it's not
> >
> >Not faster? I'd be very surprised if this was not true for the majority
of
> >test cases. Each output to cout has to go through significant locale management.
> >
> >
> >
>
>


« First   ‹ Prev
1 2