Learning C/C++ Programming
Discussion
Writing Solid Code is an excellent book which will get you thinking more about how you are designing and developing software.
It won't teach you how to write C, it's not a language reference - but it will help you immensely to learn how to 'think' in C.
A really good book that you can pick up and read again and again - the reviews at the bottom will give you some insight..
It won't teach you how to write C, it's not a language reference - but it will help you immensely to learn how to 'think' in C.
A really good book that you can pick up and read again and again - the reviews at the bottom will give you some insight..
I am also interested in the above
I have been using PIKA software Builder and it doesnt seem to do much
Having downloaded Microsoft Visual Studio Community Edition that was supposedly free I was shocked when a 30 day trial countdown started running on it
Any help will be much appreciated, I only want to build a simple programme
I have been using PIKA software Builder and it doesnt seem to do much
Having downloaded Microsoft Visual Studio Community Edition that was supposedly free I was shocked when a 30 day trial countdown started running on it
Any help will be much appreciated, I only want to build a simple programme
TheExcession said:
Writing Solid Code is an excellent book which will get you thinking more about how you are designing and developing software.
Before that, this is mandatory for any C programmerhttp://www.amazon.co.uk/The-Programming-Language-2...
This is excellent for all the things K & R don't mention.
http://www.amazon.co.uk/C-Traps-Pitfalls-Andrew-Ko...
Once you understand every line of code in both those books, I recommend this:
http://www.amazon.co.uk/Safer-High-Integrity-Safet...
Opara said:
Hi thanks for the links , I have seen the K&R recommended a few places. In your opinion is the fact it was published over 20 years ago likely to be a problem?
Thanks
Nope - you absolutely need it on your bookshelf - it will live on your desk though.Thanks
It's a reference for all the ANSI functions - so for example if you need to copy the contents of one string to another then you'll use the strcpy function - this book will give you everything you need to know about the strcpy function - what parameters it takes, what return code, what it does when you supply duff information to it etc etc.
In terms of a spoken language - this is like a dictionary.
You really need to read through it a few times - not memorising it, just knowing what's in there and how to find it when you need it.
Buy it with the solid code book and you'll have enough to keep you busy for a few years.
dcb said:
This is excellent for all the things K & R don't mention.
http://www.amazon.co.uk/C-Traps-Pitfalls-Andrew-Ko...
ISn't that pre ANSI though? Would it really be useful to a newbie chewing their way through K&R?http://www.amazon.co.uk/C-Traps-Pitfalls-Andrew-Ko...
Opara said:
Hi thanks for the links , I have seen the K&R recommended a few places. In your opinion is the fact it was published over 20 years ago likely to be a problem?
Not at all. ISO C was standardised in 1989. The language hasn't changed much since then.The environment around it has changed a lot, however.
If you haven't already, then you really need to learn and start applying test driven development.
http://www.drdobbs.com/cpp/test-driven-development...
Martin4x4 said:
If you haven't already, then you really need to learn and start applying test driven development.
http://www.drdobbs.com/cpp/test-driven-development...
I got half way through reading that and then go called away to cook my young fella some dinner.http://www.drdobbs.com/cpp/test-driven-development...
At the time I was appalled by statements like
TDD said:
How often have you spent an hour writing code, only to spend the entire day getting it to compile and debugged?
My answer would be never happened to me - as I would always debug/step through my code with each functional step forward - i.e. add a new function or two - test it/them.I've never met a programmer who would code for an hour and then spend a day scratching his head wondering where it all went wrong.
I did once question the development techniques at a certain satellite provider in Denmark where I was told "OK we are compiling your suggested changes now, we go for coffee now it takes forty minutes"
But this is (I assume a young lad) getting into programming - he needs to get a handle on programming - K&R was recommended, which is the bible/dictionary/thesaurus of programming C, I offered Writing Solid Code as a read on how to think in C - think about the problems, think about how you design.
And suddenly we get thrown TDD/eXtreme/Agile environment that a newbie just doesn't need to know yet.
He's looking for a basic grounding in programming - i.e. buy and read the K&R ANSI book, and maybe one other that will teach him a bit about what you need to do in thinking in C.
All the new fangled stuff about TDD will be plainly obvious to him once he really gets a good grasp of the language,
Seems to me everyone here is making it very complex and just spouting crap that he has to learn.
Earlier I thought to ask on this thread does the OP know what a pointer is? Does he know the difference between an '&' and a '*'.
Evidently there's a whole heap of talented programmers here, but can we get the GGS forum back to a point where we're offering a young lad help and not just bombarding him with stuff he allegedly needs to know?
TheExcession said:
I've never met a programmer who would code for an hour and then spend a day scratching his head wondering where it all went wrong.
That's not far off being a description of how I started out with C, because with the development environment I was using at the time the compiler was dog slow, and the process of getting the resultant binary onto EEPROM to then test on the target hardware was even slower. When it could easily take 15 minutes from deciding to compile to having the resultant binary installed on the target, learning to restrict the number of build cycles I went through was a necessity. You can take it as read that I was one very happy bunny the day I switched from EEPROM to flash based systems...TheExcession said:
And suddenly we get thrown TDD/eXtreme/Agile environment that a newbie just doesn't need to know yet.
Or possibly ever. The great thing about C is how universally applicable it is. The great drawback to C is how universally applicable it is... Someone who spends their life writing C for large systems as part of a large development team is going to have a very different perspective on what a C development workflow should look like compared to someone who writes C for small embedded systems in a small team (quite often no larger than themselves), so even if the OP were at the point in their C coding career where they were ready to start thinking about stuff like this it'd still be premature to be making these suggestions without first understanding how and where they were going to be writing their code.TheExcession said:
Nope - you absolutely need it on your bookshelf - it will live on your desk though.
It's a reference for all the ANSI functions - so for example if you need to copy the contents of one string to another then you'll use the strcpy function - this book will give you everything you need to know about the strcpy function - what parameters it takes, what return code, what it does when you supply duff information to it etc etc.
In terms of a spoken language - this is like a dictionary.
You really need to read through it a few times - not memorising it, just knowing what's in there and how to find it when you need it.
Buy it with the solid code book and you'll have enough to keep you busy for a few years.
Thanks mate , just keeping my eye out for a bargain copy nowIt's a reference for all the ANSI functions - so for example if you need to copy the contents of one string to another then you'll use the strcpy function - this book will give you everything you need to know about the strcpy function - what parameters it takes, what return code, what it does when you supply duff information to it etc etc.
In terms of a spoken language - this is like a dictionary.
You really need to read through it a few times - not memorising it, just knowing what's in there and how to find it when you need it.
Buy it with the solid code book and you'll have enough to keep you busy for a few years.
Martin4x4 said:
If you haven't already, then you really need to learn and start applying test driven development.
http://www.drdobbs.com/cpp/test-driven-development...
WTF...http://www.drdobbs.com/cpp/test-driven-development...
TheExcession said:
It's a reference for all the ANSI functions - so for example if you need to copy the contents of one string to another then you'll use the strcpy function - this book will give you everything you need to know about the strcpy function - what parameters it takes, what return code, what it does when you supply duff information to it etc etc.
With reference to the last point, C is for serious professionals who knowwhat they are doing and need *no* handholding from the language.
You asked for it, you got it, is the basic philosophy.
For example, call strcpy with NULL pointers and it will simply crash your process.
More subtly, call it with wrong addresses and it will silently overwrite
anything you asked it to.
Handholding languages like Basic or Java it very much isn't.
Total attention to every detail is pretty much mandatory.
In motoring terms, C is compared with a Ferrari, with no ABS, no
traction control, shoddy brakes and a very large spike pointing out
from the steering wheel, directly at your chest. i.e. get the slightest
thing wrong and you are dead.
Happy coding. I've enjoyed the last 30 years coding with C.
You C/C++ lot are weird. For application levels give me managed (handholding?) code any day.
And dead tree reference guides? Can't remember the last time I looked at one, even in the 90's we'd moved to CD roms. These days there's a whole internet, and intellisense (although I don't get the JavaScript lot and their love of one page scrolly websites for documentation, utterly awful). These days my bookshelf is more about concepts and personal development type books.
Best piece of advise I've read in this thread is test driven development - I came to it late and it fundamentally changed the way I structure code. Plus I'd have thought if the intention is to program something to run in an embedded environment you'll have a hard enough time debugging errors on that side without also using that environment to debug the higher level logic.
Regarding no-one ever writing an entire hour of code before trying it - my former teachers used to code punched cards in their youth and in college we learnt Cobol, for which we wrote the entire program out on 80 col layout sheets first. In both cases you wrote the entire program in one go before you had any chance to debug. In general the faster you can cycle think/code/test/debug the better.
And dead tree reference guides? Can't remember the last time I looked at one, even in the 90's we'd moved to CD roms. These days there's a whole internet, and intellisense (although I don't get the JavaScript lot and their love of one page scrolly websites for documentation, utterly awful). These days my bookshelf is more about concepts and personal development type books.
Best piece of advise I've read in this thread is test driven development - I came to it late and it fundamentally changed the way I structure code. Plus I'd have thought if the intention is to program something to run in an embedded environment you'll have a hard enough time debugging errors on that side without also using that environment to debug the higher level logic.
Regarding no-one ever writing an entire hour of code before trying it - my former teachers used to code punched cards in their youth and in college we learnt Cobol, for which we wrote the entire program out on 80 col layout sheets first. In both cases you wrote the entire program in one go before you had any chance to debug. In general the faster you can cycle think/code/test/debug the better.
TheExcession said:
And suddenly we get thrown TDD/eXtreme/Agile environment that a newbie just doesn't need to know yet.
I disagree, the fact that he is a newbie is all the more reason to establish a solid foundation of best practice. A debugger is fine for working out what is going wrong when there is unexpected behaviour/results, but is no match for the speed of development with TDD gives or proof of correctness from continuous regression with TDD .Coaching both young developers and seasoned veterans in best practice is an inherent part of my role and TDD is one of the first things I instil in them. This works. I've turned around too many dysfunctional failing projects for this to be a fluke. TDD is the foundation that instils a whole host of good software engineering behaviours; starting with ensuring functional correctness, clean interfaces, good encapsulation, low coupling and enabling continuous refactoring. TDD is not that new it is actually built from solid computer science principles of Hoare logic something that is nearly 50 years old.
As for strcpy, surely you mean strncpy
Edited by Martin4x4 on Monday 7th September 21:14
My advice is that the best way to learn C++ is to write it. LOTS of it.
Start with a basic "Hello World" from scratch, using a book/website to learn what each line is doing. Then do a guess-the-number style game. Then a card simulation, etc. Then it just snowballs. The key thing would be to direct it where your interests lie to keep you interested.
One or two books are useful, though to be honest all the C/C++ resource you will ever need is online now - i.e. StackOverflow and the cppprogramming forums.
Start with a basic "Hello World" from scratch, using a book/website to learn what each line is doing. Then do a guess-the-number style game. Then a card simulation, etc. Then it just snowballs. The key thing would be to direct it where your interests lie to keep you interested.
One or two books are useful, though to be honest all the C/C++ resource you will ever need is online now - i.e. StackOverflow and the cppprogramming forums.
Edited by ReallyReallyGood on Monday 7th September 13:38
Martin4x4 said:
I disagree
Good, because that what makes for healthy debate - for a junior programmer just getting his feet wet, TDD/Agile etc etc is utterly irrelevent - read the OP - he wants a bit on insight into the world of C to write a Tetris game - he's not looking to help rewrite the whole of General Motors' outsourced code platform into something that can be actually understood by the latest graduate programmer that all understand C/C++ and all the development techniques that could be/should be or should not be applied.(A GM role that I recently declined once I got wind of how fvcked up their systems really are).
He's a kid at college learning a bit of C programming.
KISS - he needs a language ref book and a guide into where program design goes wrong.
As for those advocating that dead tree reference material is out of fashion, you should try it some time - a few reads of a tech book means you know roughly were in the book the thing you are looking for exists. I books can display only two pages at a time but you can very quickly bookmark varies pages with fingers and postit notes - personally I hate reading PDF/Word Documents and being able to pencil in 'see page 294' in a book beats anything I've ever managed to find with digital media.
Martin4x4 said:
As for strcpy, surely you mean strncpy
No I definitely meant strcpy 
Edited by TheExcession on Monday 7th September 16:14
ReallyReallyGood said:
My advice is that the best way to learn C++ is to write it. LOTS of it.
Start with a basic "Hello World" from scratch, using a book/website to learn what each line is doing. Then do a guess-the-number style game. Then a card simulation, etc. Then it just snowballs. The key thing would be to direct it where your interests lie to keep you interested.
One or two books are useful, though to be honest all the C/C++ resource you will ever need is online now - i.e. StackOverflow and the cppprogramming forums.
Absolutely, the only way to learn a language properly is to use it. Get your head around it, come up with examples and write lots of code, explore the various aspects and techniques.Start with a basic "Hello World" from scratch, using a book/website to learn what each line is doing. Then do a guess-the-number style game. Then a card simulation, etc. Then it just snowballs. The key thing would be to direct it where your interests lie to keep you interested.
One or two books are useful, though to be honest all the C/C++ resource you will ever need is online now - i.e. StackOverflow and the cppprogramming forums.
Edited by ReallyReallyGood on Monday 7th September 13:38
I would leave agile and all the advanced stuff until understand enough about what you are doing.
Agile on your own is pretty pointless anyway. You can understand these methodologies and practices later on, they apply regardless of the language you are using.
A good grounding in C/C++ will give you a good understanding about home computers work and a good grounding into understanding memory/performance etc before moving onto languages that do it all for you.
Gassing Station | Computers, Gadgets & Stuff | Top of Page | What's New | My Stuff