printf format
David Rubin
printf("\nsome text");
in a lot of different places, mostly in MS or MS-inspired code. Where
did this practice come from?
david
--
If 91 were prime, it would be a counterexample to your conjecture.
-- Bruce Wheeler
Joona I Palaste
> I've seen code like
> printf("\nsome text");
> in a lot of different places, mostly in MS or MS-inspired code. Where
> did this practice come from?
Maybe newbies understand the term "new line" wrongly. It gives you a
new line to print the NEXT line, not the CURRENT one.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"It's not survival of the fattest, it's survival of the fittest."
- Ludvig von Drake
pete
>
> David Rubin <dlr...@hotmail.com> scribbled the following:
> > I've seen code like
>
> > printf("\nsome text");
>
> > in a lot of different places, mostly in MS or MS-inspired code. > > Where
> > did this practice come from?
>
> Maybe newbies understand the term "new line" wrongly. It gives you a
> new line to print the NEXT line, not the CURRENT one.
newline is just newline.
There's nothing wrong with starting output on a new line,
just as long as your stream terminates with a newline character.
If all the output fits on a screen,
I think it looks better,
separated from the previous command prompt.
--
pete
Joona I Palaste
I agree with all the above, but:
The ISO C standard says that the program output is only guaranteed to
be visible if the stream terminates with a newline character.
It does not say anything about whether or not the stream *begins* with
a newline character.
So if the requirement about stream terminating is satisfied, the stream
can begin with any printable character the implementor pleases.
Therefore putting newlines at the end instead of at the beginning saves
you not two, not three, but ONE (count it!) whole printf() call (well
it's a positive number nevertheless), and you avoid printing a blank
line every time you start your program.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The obvious mathematical breakthrough would be development of an easy way to
factor large prime numbers."
- Bill Gates
Mark McIntyre
wrote:
>Joona I Palaste wrote:
>>
>> David Rubin <dlr...@hotmail.com> scribbled the following:
>> > I've seen code like
>>
>> > printf("\nsome text");
>>
>> > in a lot of different places, mostly in MS or MS-inspired code. > > Where
>> > did this practice come from?
>>
>> Maybe newbies understand the term "new line" wrongly. It gives you a
>> new line to print the NEXT line, not the CURRENT one.
>
>newline is just newline.
>There's nothing wrong with starting output on a new line,
but there _is_ something wrong with not ending output with a newline.
It won't necessarily appear for one thing.
>just as long as your stream terminates with a newline character.
agreed.
>If all the output fits on a screen,
>I think it looks better,
>separated from the previous command prompt.
so send a newline before starting any output, but also put a newline
at the end of each line, to ensure output.
After all, do you /start/ each sentence with a full stop? No, they go
at the end to tell you it _is_ the end.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Geoff Field
news:fj237usg1rimdhuil...@4ax.com...
> On Mon, 18 Feb 2002 17:52:10 -0500, pete <pfi...@mindspring.com>
> wrote:
>
> >Joona I Palaste wrote:
> >>
> >> David Rubin <dlr...@hotmail.com> scribbled the following:
> >> > I've seen code like
> >>
> >> > printf("\nsome text");
> >>
> >> > in a lot of different places, mostly in MS or MS-inspired code. > >
Where
> >> > did this practice come from?
> >>
> >> Maybe newbies understand the term "new line" wrongly. It gives you a
> >> new line to print the NEXT line, not the CURRENT one.
> >
> >newline is just newline.
> >There's nothing wrong with starting output on a new line,
>
> but there _is_ something wrong with not ending output with a newline.
> It won't necessarily appear for one thing.
>
> >just as long as your stream terminates with a newline character.
>
> agreed.
>
> >If all the output fits on a screen,
> >I think it looks better,
> >separated from the previous command prompt.
>
> so send a newline before starting any output, but also put a newline
> at the end of each line, to ensure output.
OR fflush(stdout);
> After all, do you /start/ each sentence with a full stop?
.Only if I want it to be hidden on a *nix platform. ;-)
> No, they go at the end to tell you it _is_ the end.
Sensible answer, but it stretches the metaphor a bit. After all,
not every sentence ending corresponds to a line ending. Does
it?
Geoff
--
Geoff Field, Professional geek, amateur stage-levelling gauge.
Spamtraps: geoff...@hotmail.com, gcf...@bigmailbox.net, or
geoff...@great-atuin.co.uk; Real Email: gcfield at optusnet dot com dot
au
My band's web page: http://www.geocities.com/southernarea/
pete
>
> pete <pfi...@mindspring.com> scribbled the following:
> > Joona I Palaste wrote:
> >>
> >> David Rubin <dlr...@hotmail.com> scribbled the following:
> >> > I've seen code like
> >>
> >> > printf("\nsome text");
> >>
> >> > in a lot of different places, mostly in MS or MS-inspired code. > > Where
> >> > did this practice come from?
> >>
> >> Maybe newbies understand the term "new line" wrongly. It gives you a
> >> new line to print the NEXT line, not the CURRENT one.
>
> > newline is just newline.
> > There's nothing wrong with starting output on a new line,
> > just as long as your stream terminates with a newline character.
>
> > If all the output fits on a screen,
> > I think it looks better,
> > separated from the previous command prompt.
>
> I agree with all the above, but:
> The ISO C standard says that the program output is only guaranteed to
> be visible if the stream terminates with a newline character.
> It does not say anything about whether or not the stream *begins* with
> a newline character.
It doesn't say whether or not a stream begins with a printable
character either, but sometimes I like to start a stream with a
printable character anyway.
4.9.2 C89
"Data read in from a text stream will necessarily
compare equal to the data that were earlier written out to that stream
only if: the data consist only of printable characters and the control
characters horizontal tab and new-line; no new-line character is
immediately preceded by space characters; and the last character is a
new-line character. Whether space characters that are written out
immediately before a new-line character appear when read in is
implementation-defined."
> So if the requirement about stream terminating is satisfied,
> the stream
> can begin with any printable character the implementor pleases.
> Therefore putting newlines at the end instead of at the beginning
You're using the word "instead" as if to say that the reason
that the string isn't newline terminated,
is because it starts with a newline.
That would be a really bad reason.
Starting a string with a newline doesn't prevent *me* from
ending it with a newline also.
OP's example is inadequate to describe why it's written that way.
The printf could be followed by a scanf
that he wants to see on the same screen line.
That's a common reason for not ending a string with a newline.
> saves
> you not two, not three, but ONE (count it!) whole printf() call (well
> it's a positive number nevertheless),
OP asked why, without providing context:
(well, some context; he said MS, as if he wanted the answer to be
"Because the programmer had his head up his ass.")
Why ? :
1 newline at the begining of the string
2 no newline at the end of the string
My answer is: "Whatever context might justify it."
Your answer is: "Newbie's poor judgement."
Could be either, I suppose.
> and you avoid printing a blank
> line every time you start your program.
Avoid?! But the point of starting the stream with a new line, is
*only when I want*
a blank line every time I start that program.
All of my different programs' outputs,
don't all start with the same string.
I like this one starting with a newline; it looks more better.
/* BEGIN aname.c */
#include <stdio.h>
int main(void)
{
char array_name[1 + sizeof(char (*)[])] = {0};
if(sizeof array_name == sizeof &array_name + 1)
puts("\nThis may be a conforming compiler.\n");
else
puts("\nThis is not a conforming compiler.\n");
puts("char array_name[1 + sizeof(char (*)[])] = {0};\n");
printf("sizeof(char (*)[]) is %lu\n",
(long unsigned)sizeof(char (*)[]));
printf("sizeof(array_name) is %lu\n",
(long unsigned)sizeof(array_name));
printf("sizeof(&array_name) is %lu\n",
(long unsigned)sizeof(&array_name));
return 0;
}
/* END aname.c */
--
pete
pete
I like to break up the representation
of the single string in the source code using quotes,
while writing a whole bunch of lines with one string.
I've really never considered that there should be any
equivalence between the number of lines of output,
and the number of strings in source code to generate them.
When I review code, I skip over the strings.
There's no program flow control in a string.
The bigger and fewer that strings are,
the easier they are to skip over.
When I review strings,
I just don't generally consider them challenging.
void
Receipt(struct product *items, size_t n_products, unsigned *quantity)
{
size_t index;
double subtotal, increase, tax;
puts("\n"
"Item Price Quantity T-Price\n"
"-----------------------------------------");
for(subtotal = index = 0; index != n_products; ++index){
increase = quantity[index] * items[index].price;
subtotal += increase;
printf("%-7s%6.2f%12u%16.2f\n",
items[index].name,
items[index].price, quantity[index], increase);
}
tax = TAX(subtotal);
printf("\n"
"%13s%-11s%17.2f\n"
"%13s%-11s%17.2f\n"
"%13s%-11s%17.2f\n",
"", "Subtotal ", subtotal,
"", "Sales Tax ", tax,
"", "Total Sales", subtotal + tax);
}
--
pete
Minti
say you have a printer printing and you flush the output but the
printer might be printing the line only when it itself encounters the
newline.
Villy Kruse
Minti <mintisp...@yahoo.com> wrote:
>Note that this is not so I discussed this with Dan sometime back. If
>say you have a printer printing and you flush the output but the
>printer might be printing the line only when it itself encounters the
>newline.
That is entirely up to the printer hardware, isn't it. Often these
days the printer won't print anything until it gets a form feed (\f).
As far as your program is concerned the data is sent to the printer and
it is out of your hands.
Old programmers often had the habbit if starting a print job with a form
feed instead of ending it with a form feed, just in case the previous job
left the fanfold paper in the middle of a page. With comtemporary printer
hardware this won't do any more.
Villy
willem veenhoven
>
> Geoff Field wrote:
>
> > > so send a newline before starting any output, but also
> > > put a newline at the end of each line, to ensure output.
> >
> > OR fflush(stdout);
> Note that this is not so I discussed this with Dan sometime
> back. If say you have a printer printing and you flush the
> output but the printer might be printing the line only when
> it itself encounters the newline.
Unless you're using a very old printer with tractor feed, you
won't see the page without sending a formfeed anyhow :)
willem
Dan Pop
>"Mark McIntyre" <markmc...@spamcop.net> wrote in message
>news:fj237usg1rimdhuil...@4ax.com...
>>
>> so send a newline before starting any output, but also put a newline
>> at the end of each line, to ensure output.
>
>OR fflush(stdout);
No guarantee that this would make the output visible on the terminal
device, which might do some line buffering of its own.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
Dan Pop
>I've seen code like
>
> printf("\nsome text");
>
>in a lot of different places, mostly in MS or MS-inspired code. Where
>did this practice come from?
It *probably* comes from MSDOS automatically appending a newline
character after the program's output, which makes terminating the last
line of output with a newline character unnecesary (and, in some cases,
even undesirable).
If you don't know in advance if the current line is going to be the
last one, it makes sense not to newline-terminate it. But then, you
have to prefix each new line of output by the newline character that
ends the previous line. This explains the coding practice you have
observed.
David Rubin
[snip]
> OP's example is inadequate to describe why it's written that way.
> The printf could be followed by a scanf
> that he wants to see on the same screen line.
> That's a common reason for not ending a string with a newline.
To clarify, no. People just seem to want to print a newline at the
beginning of their output rather than the end. This is rather illogical,
IMO.
[snip]
> OP asked why, without providing context:
> (well, some context; he said MS, as if he wanted the answer to be
> "Because the programmer had his head up his ass.")
Actually, I *was* expecting this answer :-) I've seen in in varous
newbie posts in c.l.c as well which means that they must be learning it
somewhere...
> Why ? :
> 1 newline at the begining of the string
> 2 no newline at the end of the string
> My answer is: "Whatever context might justify it."
> Your answer is: "Newbie's poor judgement."
>
> Could be either, I suppose.
>
> > and you avoid printing a blank
> > line every time you start your program.
>
> Avoid?! But the point of starting the stream with a new line, is
> *only when I want*
> a blank line every time I start that program.
> All of my different programs' outputs,
> don't all start with the same string.
> I like this one starting with a newline; it looks more better.
[snip code]
Your code seems to miss the point. If you want to start your output with
a blank line, that's one thing, but I'm talking about putting the
newline at the *beginning* of every printf rather than at the end. You
don't do this in your code, probably because you know better.
willem veenhoven
>
> pete wrote:
>
> > That's a common reason for not ending a string with a
> > newline.
>
> To clarify, no. People just seem to want to print a newline
> at the beginning of their output rather than the end. This is
> rather illogical, IMO.
No, it isn't. It prevents the printer spitting out an empty
page if the content just fits the number of lines specified.
I use bookkeeping software that also contains this error,
which is very annoying, IMHO ...
willem
William D. Tallman
[beginning with newline...]
> Actually, I *was* expecting this answer :-) I've seen in in varous
> newbie posts in c.l.c as well which means that they must be learning it
> somewhere...
I had the misfortune to waste a few bucks on a used edition of:
Charles Siegel: "teach yourself..... C" 2nd edition. It is not
recommended by the ACCU (?) folk. Perhaps one reason is because it
recommends that sort of thing.
Bill Tallman
Daniel Fox
"David Rubin" <dlr...@hotmail.com> wrote in message
news:3C71750A...@hotmail.com...
> I've seen code like
>
> printf("\nsome text");
>
> in a lot of different places, mostly in MS or MS-inspired code. Where
> did this practice come from?
>
In some circles this was thought to be easier to maintain.
printf("some text\n");
If the intent of this is to print "some text" on its own line, it relies on
the code above it to have properly output a newline to execute as expected.
However
printf("\nsome text");
will output on a new line no matter what, since it provides its own newline...
...but of course now you have to check the subsequent output statement,
instead of the preceding one. I guess some people find it easier to look
forward than back.
-Daniel
pete
> void
> Receipt(struct product *items, size_t n_products, unsigned *quantity)
Bulletproof input, Do your worst!
/* BEGIN products.c */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <ctype.h>
#define ARRAYSIZE 12
#define TAX(S) (0.06 * (S))
#define N_PRODUCTS (sizeof items / sizeof *items)
struct product {
char *name;
double price;
};
void Intro(void);
void Prompt(struct product *, size_t);
void Receipt(struct product *, size_t, unsigned *);
int OK_input(char *, size_t);
int OK_unsigned(long unsigned *);
int main(void)
{
struct product items[] = {
{"milk" , 2.59},
{"candy" , 1.21},
{"meat" , 1.69},
{"juice" , 1.29},
{"fruit" , 2.33}
};
unsigned quantity[N_PRODUCTS];
long unsigned quantity_temp;
size_t index = 0;
Intro();
do {
Prompt(items, index);
if (OK_unsigned(&quantity_temp)) {
quantity[index++] = quantity_temp;
}
} while (index != N_PRODUCTS);
Receipt(items, index, quantity);
return 0;
}
void Intro(void)
{
puts("");
}
void Prompt(struct product *items, size_t index)
{
printf("How much %s would you like to order: ",
items[index].name);
fflush(stdout);
}
void
Receipt(struct product *items, size_t n_products, unsigned *quantity)
{
size_t index;
double subtotal, increase, tax;
puts("\n"
"Item Price Quantity T-Price\n"
"-----------------------------------------");
for (subtotal = index = 0; index != n_products; ++index) {
increase = quantity[index] * items[index].price;
subtotal += increase;
printf("%-7s%6.2f%12u%16.2f\n",
items[index].name,
items[index].price, quantity[index], increase);
}
tax = TAX(subtotal);
printf("\n"
"%13s%-11s%17.2f\n"
"%13s%-11s%17.2f\n"
"%13s%-11s%17.2f\n",
"", "Subtotal ", subtotal,
"", "Sales Tax ", tax,
"", "Total Sales", subtotal + tax);
}
int OK_unsigned(long unsigned *quantity_ptr)
{
char array[ARRAYSIZE] = {'\0'};
int length;
length = OK_input(array, sizeof array);
if (length) {
if (strchr(array, '-')){
fputs("\nDon't use - in the number.\n", stderr);
length = 0;
} else {
char *endptr;
errno = 0;
*quantity_ptr = strtoul(array, &endptr, 10);
if (array != endptr - length) {
if(isdigit(endptr[-1])) {
size_t spindex = 0;
while (isspace(endptr[spindex])) {
++spindex;
if (endptr[spindex] == '\n') {
return 1;
}
}
}
fprintf(stderr, "\n"
"Don't use %-2s in the number.\n\n",
isspace(*endptr) ? "\bblank spaces"
: isprint(*endptr) ? endptr[1] = '\0', endptr
: "\bnonprinting characters");
length = 0;
} else {
if (errno || *quantity_ptr > ~0u) {
fputs("\nThat number is too high.\n\n", stderr);
length = 0;
}
}
}
}
return length;
}
int OK_input(char *array, size_t arraysize)
{
int length;
if (!fgets(array, arraysize, stdin) || feof(stdin)) {
if (ferror(stdin)) {
fputs("\n\n\nferror 1\n\n", stderr);
exit(EXIT_FAILURE);
}
if (strlen(array)) {
fputs("\n\n\nfeof 1\n", stderr);
exit(EXIT_FAILURE);
} else {
fputs("\n\n\nDon't do that!\n\n", stderr);
clearerr(stdin);
length = 0;
}
} else {
length = strlen(array) - 1;
if (length) {
if (array[length] != '\n') {
do {
if(!fgets(array, arraysize, stdin) || feof(stdin)){
if (ferror(stdin)) {
fputs("\n\n\nferror 2\n", stderr);
exit(EXIT_FAILURE);
} else {
fputs("\n\n\nfeof 2\n", stderr);
exit(EXIT_FAILURE);
}
} else {
length = strlen(array) - 1;
}
} while (array[length] != '\n');
fprintf(stderr, "\n"
"Don't type more than %lu character%s\n"
"before hitting the Enter key.\n\n",
arraysize - 2lu, arraysize == 3 ? "" : "s");
length = 0;
}
}
}
return length;
}
/* END products.c */
--
pete
Mark McIntyre
(Peter "Shaggy" Haywood) wrote:
>Groovy hepcat willem veenhoven was jivin' on Tue, 19 Feb 2002 17:51:43
>+0100 in comp.lang.c.
>Re: printf format's a cool scene! Dig it!
>
>>> To clarify, no. People just seem to want to print a newline
>>> at the beginning of their output rather than the end. This is
>>> rather illogical, IMO.
>>
>>No, it isn't. It prevents the printer spitting out an empty
>>page if the content just fits the number of lines specified.
>
> What are you talking about? How does putting a newline at the
>beginning of a line prevent a printer ejecting an empty page? Many
>printers won't even print a line unless it is properly terminated.
What are you talking about? Most printers won't print a page till they
receive a \showpage command....
Daniel Fox
My printer won't print at all :(
-Daniel
CBFalconer
Maybe some of you remember when all printed output lines needed to
have a leading 'carriage control' character. A blank usually
meant "print on next line".
It really doesn't matter where you put the \n. The result is
going to a stream. The only thing you need to worry about is that
there is a final \n.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@XXXXworldnet.att.net)
Available for consulting/temporary embedded and systems.
(Remove "XXXX" from reply address. yahoo works unmodified)
mailto:u...@ftc.gov (for spambots to harvest)
Larry Jones
>
> I've seen code like
>
> printf("\nsome text");
>
> in a lot of different places, mostly in MS or MS-inspired code. Where
> did this practice come from?
I believe the standard practice in MS-DOS is to print a newline at the
beginning of each line rather than at the end. I suspect that people
who write such code learned that convention before learning C. As to
why MS-DOS has that convention, I suspect it comes from the dark ages of
line printers where there was always contention about whether to advance
the paper before or after printing -- some systems did it one way and
some did it the other.
-Larry Jones
I sure wish I could get my hands on some REAL dynamite. -- Calvin