function

S

santosh

CBFalconer said:
Barry said:
CBFalconer said:
santosh wrote:
Bill Cunningham wrote:

You code and the suggestions of others hav prompted me to check
fgets more closely. I guess it adds the newline. Now the \0 Is
added by my understanding by the compiler to a string and that's
the only time \0 is added.

No. In this case, it's fgets that adds the terminating null
character. The compiler is not the only entity that adds null
characters. Several standard library functions also do this.

In your case the problem is not the '\0' but the '\n' before it.
Use strchr to find and remove it before doing the comparison
with strcmp.

That's the slow way. Since fgets always ends operation when it
receives a '\n', any such character is at the end of the line
(otherwise it is a maximul line, and not complete). Therefore
the code:

lgh = strlen(s);
if ('\n' == s[lgh]) s[lgh] = '\0';

Why do you think strlen is faster than strchr? Both step through the
string looking for something. strchr will usually stop looking one
character sooner.

strchr has to check each value against '\n'. strlen just looks for
a zero. Something like:

s = str;
while (*s++) continue;
return s-str-1;

while strchr has make the loop portion:

while ('\n' - *s++) continue;

which does a lot more many times. Zero is usually detectable by
hardware.

I doubt that the code is all that different under most modern hardware.

In anycase, your suggestion to use strlen and look behind is a classic
case of micro-optimisation that's frequently condemned in this group.

Also note that in your code above the expression s[lgh] will yield the
terminating null character of the string in 's', not the '\n'
character, if any.
There is also a complication returning the "NULL if not
found".

Which is exactly what we want to know, and which is what you manually
did above.
 
S

santosh

CBFalconer said:
At this moment, my newsreader shows 57 messages in the thread.

Why mention Bill's name while retaining none of what he wrote and
snipping the proper attribution for the text you have quoted?
 
S

santosh

Bill said:
I tried C++ first and wizzed through it compared to C.

Okay. This is the first time I've ever heard someone say that C++ was a
walk in the park compared to C.

<snip>
 
D

Default User

santosh said:
Bill Cunningham wrote:

Okay. This is the first time I've ever heard someone say that C++ was
a walk in the park compared to C.

I don't believe for a minute that Bill can program any significant
problem in C++. He might be a whiz in his own mind, but as I recall
from discussions on comp.lang.c++ it was this same business. He never
learned basic concepts.




Brian
 
B

Bill Cunningham

Okay. This is the first time I've ever heard someone say that C++ was a
walk in the park compared to C.
It is easier to me to use the iostream and file headers and the using
directive for the std namespace and infile and outfile than FILE pointers
testing for errors and such. Also cout and cin are easier to work with than
printf and scanf for example. There are so many *printf functions to
understand. I am not obviously a pro at this at all but I can write small
compilable programs. Perl I have examined I am not interested in python.
Java is a nice language. C++ is higher level to me than C and I discovered
C++ first.

Bill
 
B

Bill Cunningham

Okay. This is the first time I've ever heard someone say that C++ was a
walk in the park compared to C.
Sorry I mean ifstream and ofstream to be precise.

Bill
 
S

santosh

Bill said:
Okay. This is the first time I've ever heard someone say that C++ was
a walk in the park compared to C.
[ ... ] There are so many *printf
functions to understand. [ ... ]

Ninety-nine percent of the time a working knowledge of fprintf and
snprintf (or sprintf for die-hard C90 programmers) will do. The
v??printf set of functions are not likely to be needed at a beginner
level.

Similarly for the scanf family.
 
K

Keith Thompson

Bill Cunningham said:
My problem has been solved. I will ask clc only in extreme circumstance
when I can't solve something. Thanks to everyone I caught right onto this.
As far as style is


main(){

permisssable as long as I put the closing brace as such
} and on a line by it's self. I've seen pretty tough code. Look at linux
kernel code. I'm lost in that because of the shortcuts I don't know yet.

There are differing opinions on brace placement. I'll describe two
common styles; you can use whichever one you prefer.

So-called "K&R style" (because it's the style used by Kernighan and
Ritchie in their book) puts each closing brace at the end of the line,
and each opening brace on a line by itself, aligned under the
beginning of the construct. For example:

if (condition) {
while (something) {
do_something_else();
}
}

You can see at a glance that the final closing brace is associated
with the "if", and the other is associated with the "while".

In this style, it's still common (for historical reasons) to put the
opening brace for a function on a line by itself:

int main(void)
{
if (...) {
...
}
}

but you can be more consistent if you like:

int main(void) {
if (...) {
...
}
}

(An opening brace still goes on a line by itself if, for example, the
"if" condition is very long, or if it introduces an independent block
not controlled by a conditional.)

Another style puts opening and closing braces on their own lines:

if (condition)
{
while (something)
{
do_soemthing_else();
}
}

And there are various ways to indent this; I've seen this:

if (condition)
{
while (something)
{
do_soemthing_else();
}
}

and even this:

if (condition)
{
while (something)
{
do_soemthing_else();
}
}

One thing all these styles have in common is that the closing brace is
on a line by itself, aligned with *something* at the top of the
construct. Another is that the braces are all clearly visible; when
the '{' is at the end of a line, it's preceded by a space.

Your style:

main(){

is harder to read because the '{' is not visually separated from what
precedes it. You need to add more whitespace to make your code
legible.

And, of course, the correct declaration is not "main()", but
"int main(void)". That's a separate issue but you need to fix that as
well.
 
S

santosh

Keith said:
There are differing opinions on brace placement. I'll describe two
common styles; you can use whichever one you prefer.

So-called "K&R style" (because it's the style used by Kernighan and
Ritchie in their book) puts each closing brace at the end of the line,
and each opening brace on a line by itself, aligned under the
beginning of the construct. For example:

if (condition) {
while (something) {
do_something_else();
}
}

You have got the description backwards.

<snip>
 
C

CBFalconer

santosh said:
Why mention Bill's name while retaining none of what he wrote and
snipping the proper attribution for the text you have quoted?

Because I was sloppy.
 
K

Keith Thompson

santosh said:
You have got the description backwards.

<snip>

Whoops, you're right. The corrected paragraph is:

So-called "K&R style" (because it's the style used by Kernighan and
Ritchie in their book) puts each *opening* brace '{' at the end of the
line, and each *closing* brace '}' on a line by itself, aligned under
the beginning of the construct. For example:
[...]
 
B

Bill Cunningham

[snip]
You can see at a glance that the final closing brace is associated
with the "if", and the other is associated with the "while".

In this style, it's still common (for historical reasons) to put the
opening brace for a function on a line by itself:

int main(void)
{
if (...) {
...
}
}

but you can be more consistent if you like:

int main(void) {
if (...) {
...
}
}

(An opening brace still goes on a line by itself if, for example, the
"if" condition is very long, or if it introduces an independent block
not controlled by a conditional.)

Another style puts opening and closing braces on their own lines:

if (condition)
{
while (something)
{
do_soemthing_else();
}
}

And there are various ways to indent this; I've seen this:

if (condition)
{
while (something)
{
do_soemthing_else();
}
}

and even this:

if (condition)
{
while (something)
{
do_soemthing_else();
}
}

One thing all these styles have in common is that the closing brace is
on a line by itself, aligned with *something* at the top of the
construct. Another is that the braces are all clearly visible; when
the '{' is at the end of a line, it's preceded by a space.

Your style:

main(){

is harder to read because the '{' is not visually separated from what
precedes it. You need to add more whitespace to make your code
legible.

And, of course, the correct declaration is not "main()", but
"int main(void)". That's a separate issue but you need to fix that as
well.

Ok I'll try this method and see if I can become consistent using it

int main {
if {
}
}

Now that's right right?

Bill
 
C

CBFalconer

Bill said:
.... snip about styles ...

Ok I'll try this method and see if I can become consistent using it

int main {
if {
}
}

Now that's right right?

Too much missing. Try:

int main(void) {
if (condition) {
}
return 0'
}

where you have to replace condition by the appropriate test.
 

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

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top