[SOLVED] So, I decided to try and learn C

Michael Uplawski · 12-11-2018, 01:13 AM

All is said and as the other contributors are mastering not only the 'C' language but also English (thus earned some more rating-points), I will dwell on something completely different, rather than add cryptic palaver ...

When I learned 'C' it was because I wanted to contribute. When I gave up the effort, it was because of a deep frustration in front of a diversity of programming styles, which I had not even been able to recognize as such. This was a world completely opaque to me.

I admire your effort and courage and felicitate you to have this community around.

They had to teach me 'C' and made me abide to only 1 style-guide at a time, and finally it went in... and what a chore it was!!

This said. Once you are over that.., and once, that you can do as you please, C may still be mind-bending but you will enjoy it, when the sound in your head is not a tinnitus but simply the wind from the worm-hole blowing from a different universe.., many of them, actually.

hazel · 12-11-2018, 02:01 AM

Quote:

Originally Posted by jsbjsb001

Thanks for that - didn't realise exit had a man page. I've now added the header in there. I've just read the man page for exit, but while some of it makes sense, I'm not sure I fully understand.

Every C function has a man page! Didn't you know that? The man system was originally the Unix Programmers' Manual.

In future I suggest you run man on every new function you try. It's a mine of information. System calls are in chapter 2, library functions in chapter 3. You don't need to give the chapter number unless the function has the same name as a unix command in chapter 1 (like exit for instance). Among other things, the page will show the name of the header you need to include in your code to get access to this function.

As far as exit codes are concerned, I disagree with Mina86. I like all my programs to provide a valid exit code because it's what shells expect. Therefore I use exit(0) and not return() at the end of the main function. Error branches should end with exit(1). Of course this will only work if main() returns type int, but I think it does that by default.

Michael Uplawski · 12-11-2018, 02:07 AM

Quote:

Originally Posted by hazel

Error branches should end with exit(1). Of course this will only work if main() returns type int, but I think it does that by default.

See?
That is exactly, what I meant above.

I remember to have written many DOS batch-routines which evaluated four or more different exit-codes from 0 to n (n being 1 or not 1). That was the first remark.

Secondly: “I think it does”.
I think it may or may not. I think we prepare someone who just started learning 'C'. Do not nail him to a rock, exposed to the tides, while this language can make him scrunch rocks and raise his own tsunamis in the future. I think, that “return 0” is an extremely good convention and that “exit(0)” is a completely acceptable alternative.

Please let him.

jsbjsb001 · 12-11-2018, 02:36 AM

Quote:

Originally Posted by hazel

Every C function has a man page! Didn't you know that? The man system was originally the Unix Programmers' Manual.
...

Nope, but I do now.

I guess it shows the rock I've been living under, doesn't it? Thanks again for responding Hazel, your help has been excellent, thank you.

Anyway, I decided to practice both more than just exit 0 and exit 1, as well as the nested if statement. But, yet again, I done something wrong. I created a new c file this time rather than adding to my old one - just to try and less confuse myself. From the error messages I'm getting, I think (or was before I tried fixing it) it's a syntax issue, but every time I try to fix, I just get more errors. I wanna also practice the return statement once I've got exit and the nested if statement under control.

I tried what listed in this link and this, but added my own conditions, but it still give me errors when trying to compile it.

These are the latest errors gcc is giving me;

Code:

     ^
[james@jamespc devel]$ gcc test3.c -o test3
test3.c: In function ‘main’:
test3.c:21:5: error: expected ‘}’ before ‘else’
     else if ( c == 100 ) 
     ^
test3.c:26:7: error: ‘else’ without a previous ‘if’
       else ( c == 200 ) 
       ^
test3.c:28:2: error: expected ‘;’ before ‘puts’
  puts("it's 200, exit 3");
  ^
test3.c: At top level:
test3.c:31:1: error: expected identifier or ‘(’ before ‘}’ token
 }
 ^
test3.c:32:1: error: expected identifier or ‘(’ before ‘return’
 return 0;
 ^
test3.c:33:5: error: expected identifier or ‘(’ before ‘}’ token
     }
     ^
[james@jamespc devel]$ gcc test3.c -o test3
test3.c: In function ‘main’:
test3.c:21:5: error: expected ‘}’ before ‘else’
     else if ( c == 100 ) 
     ^
test3.c:26:7: error: ‘else’ without a previous ‘if’
       else ( c == 200 ) 
       ^
test3.c:28:2: error: expected ‘;’ before ‘puts’
  puts("it's 200, exit 3");

I've tried several times to fix it, so the code is different from the last time I tried to compile it. I called it "test3" this time because I've got another c file called "test2" on my system.

I've attached my "latest effort". Thanks again.

mina86 · 12-11-2018, 04:05 AM

Quote:

Originally Posted by hazel

As far as exit codes are concerned, I disagree with Mina86. I like all my programs to provide a valid exit code because it's what shells expect. Therefore I use exit(0) and not return() at the end of the main function. Error branches should end with exit(1).

Again, you don’t need to use exit to specify exit code. All you need is return it from main. So again, don’t use exit now. First understand what status code is by returning from main. Then step forward to exit to understand what are the differences and why there is a need for exit. In many programs there is none so I recommend you concentrate on other aspects of C and deal with exit later down the road.

Quote:

Originally Posted by hazel

Of course this will only work if main() returns type int, but I think it does that by default.

It’s not ‘by default’. It’s the only valid prototype for main.

Quote:

Originally Posted by Michael Uplawski

Do not nail him to a rock, exposed to the tides, while this language can make him scrunch rocks and raise his own tsunamis in the future.

That’s precisely my point. Forget about exit for now because it’s not needed and only adds another concept. Returning from main is sufficient and analogous to returning from other functions thus it adds only minimal complexity (i.e. understanding what exit status of a program is).

Quote:

Originally Posted by jsbjsb001

the nested if statement

Well, the error messages literally tell you what the problem is. You’re missing } before else.

Every block must have beginning – indicated by { – and an end – indicated by }. In your code braces are not balanced.

To nest if statements, you put one if statement inside of a block of another if statement, e.g.:

Code:

if (c > 0) {
    puts("c is positive");
    if (c % 2 == 1) {
        puts("positively odd even");
    }
} else {
    puts("c is non-positive");
    if (c < 0) {
        puts("negative even");
    }
}

Notice that the condition of the inner if must be a subset of the condition of the outer if for the code to make sense. In your example:

Code:

if (c == 0) {
    …
    if (c == 100) {
        …
    }
}

The second condition is always false because we know that at this point in code c is zero thus cannot equal 100.

jsbjsb001 · 12-11-2018, 04:54 AM

Thank you mina86!

I think I've fixed it - both it not compiling issue and my nested if statement. I think I'm starting to get the hang of it, but just have keep plugging away I guess. As usual, I've attached the code so ya'll can see exactly what I've changed. Many thanks again.

I'll keep ya's updated.

hazel · 12-11-2018, 05:20 AM

Here's a trick I use for braces. I visually match those that are supposed to go together by always putting the opening and closing brace in the same column. Then, in a syntax-checking editor like geany or vim, I move the cursor onto each opening brace in turn and check that the correct closing brace lights up in blue. In other words, the arithmetical matches should match the visual ones.

If the wrong closing brace lights up, you have a missing brace somewhere in between. If a brace lights up in red, you have a surplus brace.

Andy Alt · 12-11-2018, 11:28 AM

Quote:

Originally Posted by jsbjsb001

Code:

[james@jamespc devel]$ gcc -Wall -Werror test.c -o test
test.c: In function ‘main’:
test.c:61:5: error: implicit declaration of function ‘value_less_than_100’ [-Werror=implicit-function-declaration]
     ret = value_less_than_100();
     ^
test.c:66:5: error: implicit declaration of function ‘value_not_less_than_100’ [-Werror=implicit-function-declaration]
     ret = value_not_less_than_100();
     ^
test.c:72:10: error: expected expression before ‘return’
     if ( return = 1 ) {
          ^
test.c:80:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

So I changed it, and:

Code:

[james@jamespc devel]$ gcc -Wall -Werror test.c -o test
test.c: In function ‘main’:
test.c:61:5: error: implicit declaration of function ‘value_less_than_100’ [-Werror=implicit-function-declaration]
     ret = value_less_than_100();
     ^
test.c:66:5: error: implicit declaration of function ‘value_not_less_than_100’ [-Werror=implicit-function-declaration]
     ret = value_not_less_than_100();
     ^
test.c:72:10: error: expected expression before ‘return’
     if ( return = 1 ) {
          ^
test.c: At top level:
test.c:84:1: error: return type defaults to ‘int’ [-Werror=return-type]
 value_less_than_100()
 ^
test.c:119:1: error: return type defaults to ‘int’ [-Werror=return-type]
 value_not_less_than_100()
 ^
test.c: In function ‘main’:
test.c:80:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

I'm thinking the problem is something with this bit of code below:

Code:

 if ( c = 0 ) {
      
      puts("an error has occured - program exiting...");
      exit (1);
      }
      else {
    puts("No errors reported - good news!"); }

Quote:

Does anyone know where I can see some examples? As the only way I learn is by doing, just reading about just won't give me a complete picture - I could read it 100 times, and still not get the complete picture - unless maybe it's in really, really simple terms. Or I can actually see how it works in code that does work.

As usual I've attached what I've got so far. Thanks.

There were examples on the links you looked at. But I could see why it may not have been clear, even from the example.

I completely understand about needing to "do" and not "read". But I usually don't like to give the answer outright. I think the "student" will remember better if they get enough hints so they can figure out the problem.

By the way, sometimes plugging in the compiler warnings into a search engine will give you some good clues. Try it with "implicit declaration of function". Did you figure out what was causing that error message?

But I'll share one of the most important pieces of information you'll need to know as a programmer: Sometimes the best thing you can do to solve a problem is walk away from it. If you're going in circles, getting nowhere, and making a lot of "guesses" at how to fix things, then that's usually the best time to just STOP, and put some space between you and the problem.

For me, sometimes after trying to solve a problem and getting nowhere... the solution will pop into my head 5 minutes after I walk away (though sometimes it takes longer

).

Another piece of advice I'll give you is to make the problems smaller. It seems you were working with a lot of new concepts in one file. In the future, you might find it easier just to practice one new thing in one program. It will be a lot easier to track down bugs.

As for other learning tools, you might like this free online course: Introduction to Computer Science. I took part of the course a couple years ago and learned quite a bit, even though I started coding C over 20 years ago.

hazel · 12-11-2018, 11:56 AM

Quote:

Originally Posted by Andy Alt

But I'll share one of the most important pieces of information you'll need to know as a programmer: Sometimes the best thing you can do to solve a problem is walk away from it. If you're going in circles, getting nowhere, and making a lot of "guesses" at how to fix things, then that's usually the best time to just STOP, and put some space between you and the problem.

For me, sometimes after trying to solve a problem and getting nowhere... the solution will pop into my head 5 minutes after I walk away (though sometimes it takes longer

).

Hear, hear! I usually get my solutions while walking the dog.

jsbjsb001 · 12-11-2018, 09:17 PM

Quote:

Originally Posted by Andy Alt

There were examples on the links you looked at. But I could see why it may not have been clear, even from the example.

I completely understand about needing to "do" and not "read". But I usually don't like to give the answer outright. I think the "student" will remember better if they get enough hints so they can figure out the problem.

I figured you were trying to give me enough hints so I could figure it out, so thank you for that. I think once I get some more experience it will be much easier for me to understand with just some hints given. It kinda does depend on exactly what it is as to whether I'll be able to understand just from hints being dropped. I'm sorry if I come off as a little rude - I didn't mean to, but just thought it was worth telling ya's how I learn. I was never any good at school, because it's like, they just dump a load theory on to you, then expect you to be able to read something from cover to cover, and then have a complete understanding of it. And it's like, it's just not going to happen with me - I can't help that - I wish I could, but just can't. So it's no-ones fault at all - it's just me - I'm a practical person not an academic. But, if I can actually see how it works, then I can understand it a LOT better.

Nearly everything (or close to it) I know about Linux wasn't learn't by reading about it - it was learnt because I could sit there and actually use it and play around with it. Something the public education system where I live simply does not understand - and it's complete joke, but that's another story and off-topic too - so I'll stop digressing there.

Quote:

By the way, sometimes plugging in the compiler warnings into a search engine will give you some good clues. Try it with "implicit declaration of function". Did you figure out what was causing that error message?

If I'm thinking of the right error I got, then I'm thinking it was because of the comment mentioned in your post #21. In that, the comments were not ended properly, and there the compiler thought that my #include for the header files were also just comments. Because as soon as I fixed that, the warnings went away. So hopefully I'm right there.

Quote:

But I'll share one of the most important pieces of information you'll need to know as a programmer: Sometimes the best thing you can do to solve a problem is walk away from it. If you're going in circles, getting nowhere, and making a lot of "guesses" at how to fix things, then that's usually the best time to just STOP, and put some space between you and the problem.

For me, sometimes after trying to solve a problem and getting nowhere... the solution will pop into my head 5 minutes after I walk away (though sometimes it takes longer

).

Another piece of advice I'll give you is to make the problems smaller. It seems you were working with a lot of new concepts in one file. In the future, you might find it easier just to practice one new thing in one program. It will be a lot easier to track down bugs.

As for other learning tools, you might like this free online course: Introduction to Computer Science. I took part of the course a couple years ago and learned quite a bit, even though I started coding C over 20 years ago.

Thanks for that Andy. It was actually thinking a very similar thing myself - which is why in my last "effort", I created a new c file - as it was really starting to get quite confusing. So thank you again for both your advice as well as helping me out (and the link - I'll try and have a look at within the next couple of days), thank you so much. And a big thank you for continuing to take an interest in this thread. Thanks Andy!

I'm going to see if I can "nest" my if statements even more, so I can understand them better.

Quote:

Originally Posted by hazel

Hear, hear! I usually get my solutions while walking the dog.

I'll remember that when I get a dog to walk. Thanks again Hazel!

Michael Uplawski · 12-12-2018, 03:14 AM

... I have developed a whole program picking apples in my friend's fruit orchard.

After two weeks of doing this, I just noted down the code and “Crèmefraiche” is about all that I had thought of, balancing on a ladder in those apple-trees. The code may be cleaner nowadays and some functions have been re-coded after a while, but all in all.., these are more or less just those harvested ideas.

YesItsMe · 12-12-2018, 03:39 AM

Quote:

Originally Posted by hazel

Not really. C isn't a simple language. It was written to be powerful, not simple.

In fact, C was a descendant of BCPL with enough features removed so it could fit on the PDP machines.

mina86 · 12-12-2018, 04:03 AM

Quote:

Originally Posted by jsbjsb001

If I'm thinking of the right error I got, then I'm thinking it was because of the comment mentioned in your post #21. In that, the comments were not ended properly, and there the compiler thought that my #include for the header files were also just comments. Because as soon as I fixed that, the warnings went away. So hopefully I'm right there.

You still have implicit declarations in your code and if you compile with -Wall -Werror (as you should) you still get those errors.

Also, I strongly recommend that you get into habit of properly indenting your code. In both your examples so far your code is hard to read and follow because all the lines are all over the place. You can use Linux coding style (beware that it has some kernel-specific rules), K&R¹ or here’s a first Google search result I got when looking for ‘C coding style’: https://users.ece.cmu.edu/~eno/codin...gStandard.html which looks reasonably legit.

¹ Note that K&R is a book about ANSI C. C has moved past that since 1990 and now has some convenient features like bool so keep that in mind when reading the book.

jsbjsb001 · 12-12-2018, 05:03 AM

Alright gang, I've been practising my "nested" if statements and the exit status, and while I got the following errors, guess what, I managed to fix them! (I *think*)

Code:

[james@jamespc devel]$ gcc -Wall -Werror test3.c -o test3
test3.c: In function ‘main’:
test3.c:14:1: error: implicit declaration of function ‘myfunction’ [-Werror=implicit-function-declaration]
 ret = myfunction();
 ^
test3.c:32:6: error: expected ‘;’ before ‘exit’
      exit (2);
      ^
test3.c:37:8: error: expected ‘;’ before ‘exit’
        exit (3);
        ^
test3.c:42:3: error: expected ‘;’ before ‘exit’
   exit (4);
   ^
test3.c:69:1: error: expected declaration or statement at end of input
 }
 ^
test3.c:69:1: error: expected declaration or statement at end of input
test3.c:69:1: error: expected declaration or statement at end of input
test3.c:69:1: error: expected declaration or statement at end of input
test3.c:69:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
[james@jamespc devel]$ gcc -Wall -Werror test3.c -o test3
test3.c: In function ‘main’:
test3.c:14:1: error: implicit declaration of function ‘myfunction’ [-Werror=implicit-function-declaration]
 ret = myfunction();
 ^
test3.c:69:1: error: expected declaration or statement at end of input
 }
 ^
test3.c:69:1: error: expected declaration or statement at end of input
test3.c:69:1: error: expected declaration or statement at end of input
test3.c:69:1: error: expected declaration or statement at end of input
test3.c:69:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors

And it was of course the { } braces that was the issue - I didn't have enough of them. And they are going to be vain of my existence too.

Quote:

Originally Posted by mina86

You still have implicit declarations in your code and if you compile with -Wall -Werror (as you should) you still get those errors.

Yeah, you're right. While if I compile without gcc treating warnings as errors, my latest "effort" compiles, but if I do treat warnings as errors, it won't as per above, so I'll just have do some more reading. But things are slowly becoming more clear - it's just going to take some time. I'm not sure I really understand yet what it's complaining about, but I imagine in time, hopefully I will.

And while I think I'm starting to get a better handle on things, I'm not really sure what it's on about below;

Code:

james@jamespc devel]$ gcc -Wall -Werror test3.c -o test3
test3.c: In function ‘main’:
test3.c:14:1: error: implicit declaration of function ‘myfunction’ [-Werror=implicit-function-declaration]
 ret = myfunction();
 ^
cc1: all warnings being treated as errors

Also, I'm sure the conditions in my nested if statements are not right, as I'm trying to get it to go to an particular exit status depending on the letter I type in, but I'm sure it's not working properly. I think it's the "operator" I've used in my if statements, but I keep drawing a blank when it comes the correct one for what I want it to do. I think (and from what I can tell), the exit status IS working, but because the condition and/or "operator" I've used is wrong, it's not going to the correct exit status.

I've attached my latest "effort". Thanks for the help.

hazel · 12-12-2018, 05:13 AM

You do know, don't you, that coding is seriously addictive?