hi, i have just joined the forums. I have some experiance in C programming and just started learning files in C by myself. I wrote this following C code to create a text file and display back the text in the file i have initially created.
I know it has a lot of mistakes, the control gets struck at the line:
putc(ch,fp);
please point out my mistakes, thanx in advance.

One way:

Use getchar() to read characters from stdin and then use putc() to send them to the output file.

Note that for many (most?) Windows compilers you have to enter Ctrl-Z to indicate EOF from the console. Linux gcc and gcc/cygwin ports to Windows use Ctrl-D for EOF from the console.


Regards,

Dave

yaa, modified it, now i have
while(ch!=EOF)
{
ch=getchar();
putc(ch,fp);
}
but the rest of the code below that has problem
i can't display back the file. thnks for ur reply.

Are you saying that it doesn't exit the input loop? Or are you saying that it displays something other than what you expected? Does it create the file that you designated? Do the contents of that file differ from your expectations? Or what?

When asking for help for a particular problem my advice is: Be specific!

Also: Instead of making your code show up in the almost-unreadable-on-some-monitors dark orange, many (most?) of us would really appreciate if you would use code tags as described in the Guidelines for posting requests for help

Specifically:

Put the following before the first line of code:
[c]

Put the following after the last line of code:
[/c]

Then your code shows in a nice monospace font (so that spacing and indentation are preserved), and C syntax elements are highlighted in colors that most of us can actually see.

Regards,

Dave

...and are accustomed to seeing in code editors and consoles.


MxB

thanx for replying again, i shall be more specific this time

The control is exiting the input loop, i have checked that by putting some printf statements after the input loop and they are appearing on the screen too. Also, i can open the files i have created in command prompt. So, i am sure the program till the input loop is fine.
Please look at the following modification i have made to the code to highlight the problem:

the rest of the program is as it was in the first post.
the output is as follows:

All the printf statements execute ine by one as soon as i press enter after ctrl+z
i could not input the filename. and after last line,when i press a key, it takes me back to the editor console. problem is, it's not takin the file name input.

sorry, there is also this slight modification in the last while loop of the program.
i am using putchar instead of printf
:

Every time you read a single character from the keyboard using getchar() you are leaving the \n in the buffer for the next read.

Please format your code. It is still hard to follow.

Also, see this about gets()

__________________

The 3 Laws of the Procrastination Society:
1) Never do today that which can be put off until tomorrow
2) Tomorrow never comes

Your main function should return an int and you should avoid using conio.h if possible. I also recommend using more whitespace:


Output:



MxB

Perhaps some recommended modifications to that article?

...like suggesting that jamming the #include<stdio.h> together should be avoided?

The format "I use" shows a contradiction to the recommended whitespace usage:

int i,j;
for (i=1; i<5; i++)

...unless this is one of those cases where "and in many cases between the operators" does not apply.

...and main does not explicitly return an int. A compiler warning in waiting?

Under the "Indentation" section:

"The biggest aid to understanding."

...is not a complete sentence.

The "bottom line" contradicts the Whitesmiths style example shown.

"Some free, some shareware."

...is not a complete sentence.

"Small but useful."

...probably needs some help, too. "Small" is usually an adjective and is intended to describe the code that precedes it, so it is not a complete sentence as (apparently) intended. Perhaps as an interjection it would work?

Small, but useful!

The problem is that "what is small" is the difference between the first example that uses whitespace and the second example, that pushes everything together. But, we have to go all the way back to the section heading to relate the adjective to the noun that it modifies. That is a recipe for confusing readers--particularly those who are not native English readers/speakers. In general, avoiding common speaking habits in writing will likely aid readers in understanding if not too-terse wording is used. "Speaking" to your readers as if they are your friends is usually a good choice, but when "speaking" to a global audience of varied friends, one should lean toward clearer presentation of content and less "familiar voice" that is more difficult for others to follow.

I once worked with a Chinese mathematician. He embodied all things "geek." He was a nice guy, but definitely lived as a "full time" geek. He had incredibly bad dandruff, nearly always walked around with his fly down, wore plaid with stripes, blue socks with brown sandals and had very severe halitosis. He even had the "Coke bottle bottom" glasses. Counter-balancing these attributes was his ability to create amazingly good algorithms in exceptionally poor (visually) code. His code was a pure reflection of his exterior AND his interior! Very brilliant, but not incredibly "presentable."

This guy could read English rather well. He was practically incapable of speaking or writing something of use to anyone else, except for ugly, but effective C code without a single comment ever. I once found a "comment" that took out a variable declaration that apparently he decided that he didn't need any more. I also found a one-line declaration that used 47 one-character named variables--all of them doubles.

I used to work with him to make his code more readable. He seemed fascinated that I could "straighten out" his code to make it arguably "more presentable." I would sit with him asking him what things were what in his code and then commented them and pulled from him notations about the complexities that spun around inside his head. He was amazed that I always greeted him with offerings of Altoids or chewing gum as he seemed to find such gestures overwhelmingly generous. One day he brought me a pack of Chinese gum as a symbol of friendship and repayment of my previous generosity. I'm sure that it was an extravagant purchase on his part. I can't imagine what he was paid, but peanuts may have been an improvement!

The guy had a black leather belt that was perhaps a foot or so too long and he literally tied it about his none too-thin waist. I suspected that he shopped at the Goodwill store before they placed the items on display; rather, he pulled them from the incoming bin of jumbled up articles at bulk rates. I can't imagine that he ever laundered any thing that he wore. The underarm stains in his shirts looked like the rings of Saturn on a clear day.

I secretly hoped that someday he would meet some incredibly hot Chinese model who would bathe him and buy him coordinated "fashions" and comb his hair in exchange for the likely fantastic combination of offspring they'd produce.

I'm not sure what was the meaning of the ZZ Top song "Velcro Fly," but that was one case where it would have been practical and responsible. (I'm guessing that Velcro Fly refers to rapid deployment groupie management practices. Pearl necklace is yet another similar symbol?)

While you may have met someone similar in your 20+ years of programming experiences, you may not have considered writing your articles for that person who may be reading it. His native language is not English and his experiences are not likely "familiar" when compared to yours. However, if you are able to communicate effectively with him, perhaps his coding style will improve?

Of course, my Chinese friend's coding style did not improve, at least, not by any amount that I could notice. So, perhaps none of my recommendations will have a measurable impact, either!


HTH


MxB