puts vs fputs

B

boltar2003

Is there any logic behind puts() adding a newline but fputs() not doing it?
Or was it just a design **** up in the early days of C?

B2003
 
J

jacob navia

Le 20/07/12 11:15, (e-mail address removed) a écrit :
Is there any logic behind puts() adding a newline but fputs() not doing it?
Or was it just a design **** up in the early days of C?

B2003

The standard output stream is line buffered by default, i.e. it will
never output something unless it sees a carriage return. That is why
puts() that writes its output to standard output needs a new line.

fputs() doesn't need a new line since the stream is in most cases not
the standard output and it is buffered, not line buffered.

Before treating things like that as "design fuckups" try to understand
why they are so designed.

jacob
 
B

boltar2003

The standard output stream is line buffered by default, i.e. it will
never output something unless it sees a carriage return. That is why
puts() that writes its output to standard output needs a new line.

fputs() doesn't need a new line since the stream is in most cases not
the standard output and it is buffered, not line buffered.

Thats not a good enough reason for the inconsistent behaviour IMO.
Before treating things like that as "design fuckups" try to understand
why they are so designed.

I didn't, I asked whether it was one. Perhaps your understanding of english
isn't as good as you think.

B2003
 
J

jacob navia

Le 20/07/12 12:41, (e-mail address removed) a écrit :
Thats not a good enough reason for the inconsistent behaviour IMO.

If you do not put the new line, when you write:

puts("Please enter a number");

you will not see anything...


Thats a good enough reason for the inconsistent behaviour IMO.
 
B

boltar2003

Le 20/07/12 12:41, (e-mail address removed) a écrit :

If you do not put the new line, when you write:

puts("Please enter a number");

you will not see anything...


Thats a good enough reason for the inconsistent behaviour IMO.

Really, so why didn't they use the same logic with the printf functions then?
Why didn't they specify printf() to do an automatic newline but fprintf() not?

B2003
 
J

jacob navia

Le 20/07/12 13:13, (e-mail address removed) a écrit :
why didn't they use the same logic with the printf functions then?
Why didn't they specify printf() to do an automatic newline but fprintf() not?

Because printf is a run time interpreter of its format string.

When you use printf you do want EXACT control of the output,
not just put a string (puts) in the screen, adding a new line
would break the precise formatting instructions.

Puts(string) is equivalent to printf("%s\n", string);

jacob
 
B

boltar2003

Le 20/07/12 13:13, (e-mail address removed) a écrit :
not?

Because printf is a run time interpreter of its format string.

When you use printf you do want EXACT control of the output,
not just put a string (puts) in the screen, adding a new line
would break the precise formatting instructions.

You're just making this up as you go along arn't you? Your argument lacks
any logic whatsoever. A family of functions should have consistent
functionality. End of.

B2003
 
J

jacob navia

Le 20/07/12 14:54, (e-mail address removed) a écrit :
You're just making this up as you go along arn't you? Your argument lacks
any logic whatsoever. A family of functions should have consistent
functionality. End of.

B2003

OK. Look, you are unhappy?

Please complain to the committee. I can only give you the reasons why
this is so.

Should be changed?

Maybe, personally I do not mind about the extra newline of puts() since
I seldom use it.

End of story.
 
M

Mark Storkamp

Anders Wegge Keller said:
Not really. It looks more like your own guesses.

Take a look at
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>


7.19.7.10 The puts function
puts(s) is not exactly equivalent to fputs(stdout,s); and puts also
writes a newline after the argument string. This incompatibility
reflects existing practice.

How is that different than what Jacob (with more patience than I have)
explained? All you quoted was that it 'reflects existing practice'.
Jacob explained why that practice existed.
 
A

Anders Wegge Keller

Mark Storkamp said:
How is that different than what Jacob (with more patience than I
have) explained? All you quoted was that it 'reflects existing
practice'. Jacob explained why that practice existed.

The OP asked why the standadrs committee defined the semantics thus.
 
J

jacob navia

Le 20/07/12 18:14, Anders Wegge Keller a écrit :
The OP asked why the standadrs committee defined the semantics thus.

And I explained the reasons. By the way, you do not put those reasons
in doubt apparently.

1: Since stdout is line buffered it makes sense to put a new line
character at the end of the string
2: Since fputs would use a stream different than stdout or stderr
those streams are not line buffered so the new line is not needed.

3: In printf you want tight contro over the output so adding a new line
to each printf would break most format instructions.

Is there anything wrong with those explanations?

Please explain.

Thanks
 
K

Keith Thompson

Is there any logic behind puts() adding a newline but fputs() not doing it?
Or was it just a design f*** up in the early days of C?

The C standard library is not a model of consistency, and I
don't recall anyone claiming that it is. It evolved over a period
of several years, and the committee had to standardize existing
practice. (They could have invented a new and more consistent runtime
library, but that would have hindered adoption of the standard.)

My guess (and it's only a guess) is that puts() was designed first,
and adding a newline to text written to stdout was thought to be
convenient (and in fact it *is* convenient), and that fputs() was
added later, and it was thought that having tighter control over
what's written to a file was more important.

Note that you can print a string to stdout either with or without
an added newline:

puts(s); /* adds newline */
fputs(s, stdout); /* doens't add newline */

We don't have the same option for files other than stdout, which
is admittedly inconsistent; see above.

Oh, and you might consider being less rude. The people who have
responded to your question are simply trying to answer your question;
reacting as if the inconsistency is their fault is not constructive.
 
M

Mark Storkamp

Anders Wegge Keller said:
The OP asked why the standadrs committee defined the semantics thus.

And the real answer to that is because the language pre dates the
standard. They were documenting what already existed. Which really
doesn't answer the question of why it is the way it is.
 
A

Anders Wegge Keller

jacob navia said:
And I explained the reasons. By the way, you do not put those
reasons in doubt apparently.

No, you made a *guess*. A plausible explanation, but nevertheless a
*guess*. And then you tried to pass it on as fact.

Mixing printf/fprintf in with puts/fputs, really made you look like
grasping for straws, btw.
 
P

Philip Lantz

Anders said:
The OP asked why the standards committee defined the semantics thus.

No he didn't. He asked if there was any logic behind the functions
behaving differently.

Obviously, the standard committee defined them that way because it was
existing practice. But that doesn't answer the original question, which
was why they were implemented that way. Jacob's answers are reasonable
ones, but I agree with those who say that they are just his guesses.

I don't recall ever having seen a definitive answer.
 
M

Malcolm McLean

בת×ריך ×™×•× ×©×™×©×™, 20 ביולי 2012 18:26:35 UTC+1, מ×ת Mark Storkamp:
And the real answer to that is because the language pre dates the
standard. They were documenting what already existed. Which really
doesn't answer the question of why it is the way it is.
Probaby made sense on the original system that C ran on.

Nowadays I never use any text output function except printf() or fprintf().The overhead in printf("%s\n", str) is too trivial to worry about.
 
T

Tim Rentsch

Keith Thompson said:
Is there any logic behind puts() adding a newline but fputs() not doing it?
Or was it just a design f*** up in the early days of C?

The C standard library is not a model of consistency, and I
don't recall anyone claiming that it is. [snip]

This gets my vote for "Best in Thread" award. A model response.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top