I finished my first C++ book and while I have gotten most of the examples and exercises to work. I'm having doubts I can do this. I'm not really getting the OOP stuff.
I guess what I'll do is go through another intro book. The one laserlight suggested: Accelerated C++ and see if I can re-enforce some of the concepts.
I also picked up "Programming Pearls" for after this one. Looks a bit advanced for me but I'll give it a shot.
any sugestions, comments, critques?
I like this book list.
http://rudbek.com/books.html
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Programming Pearls is not so much about C++ per se, but much more about algorithms, optimization, and plain good advice. Definitely a good read, but be sure you are ready for it. It will assume you are familiar with algorithms, and C/C++ in general. Basically, it assumes you are a programmer.
Originally Posted by Adak
Programming is not simple, however, once you begin to understand the concepts it eventually all falls into place. Right now you have taken a 5000 piece puzzle and dumped the pieces out on a table. You cannot expect to finish a puzzle like that in one night. Likewise you cannot expect to become a language guru overnight. Many of us have been programming for a good number of years and yet we still learn new things everyday. Once you master the syntactical sugar then you will get into more about how to apply the language to solve certain problems more than the technical aspect of how to do A or B.
I would not worry too much about the tech overhead right now. Do not let it intimidate you b/c eventually you will figure that part out. The only advice I can give to help is listen to the veterans around here because they would never intentionally steer you in the wrong direction, listen to various book recommendations and go purchase them, do research on your own, and code, code, code, code until your fingers fall off and your eyeballs come out of their sockets. At least you can program today on modern OS's with little fear of crashing the entire system so if your program crashes, throws an exception, seg-faults, de-refs a null pointer, or tries to write to memory it does not own....you won't hose your OS or bring your entire system down. If you ever start doing graphics programming in OGL or Direct3D you can still cause the occasional BSOD but normally this does not happen. I do pride myself every now and then when I cause a BSOD b/c of something I did in Direct3D.
Last edited by VirtualAce; 09-01-2011 at 06:30 PM.
Object orientation is mostly about what goes on inside your head as you program, not the particular language you're programming in.
In old school procedural programming, you primarily think about data, and the things which need to be done to that data. In object oriented programming, you think about the fundamental agents (objects) which interact with each other to accomplish a task.
The language is really just complicated window dressing. The language isn't object oriented, it just provides a set of tools which encourage object oriented thought processes.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
FWIW... I struggled with Object Oriented Programming for a long time. Finally I realized that my head just doesn't work that way... I don't think in objects and classes... I think sequentially... "What do I have to do next..." So, even after much help and encouragement from the people here I finally gave it up and now do everything in C. It's not that I can't program in C++... I've written a few things... it's more that it's a bad fit with the way my head works.
Now, that's just me... Your experience may be quite different... or maybe C++ isn't where your gifts lie, perhaps C or C# or even a different language altogether... You may even find like many of us do that if you pour through the book, do all the examples and exercises, play with the code, break it, fix it, improve it etc. as you go, there will be a period of time when you are profoundly overwhelmed by it all. Take a week off, don't even think about it... and I'll bet when you come back to it, you'll find yourself able to begin understanding it a little better.
Eveyone is a little different... so don't let the sheer enormity of it, that put you off.
That's what advocates of object-oriented programmers tell you. While it is true to a point, I've yet to see any OO design converted to code without some adjustment to cope with (or, alternatively, better exploit) some aspects of the programming language.
Take a single OO design and implement it in two different languages (say, Java and C++) and you are likely to have different adjustments for each language. And that is true even if we avoid design features, like multiple inheritance, that not all OO languages support. It is certainly true if an OO design is implemented in a non-OO language, such as Fortran 77 or C.
Thanks for the pep talk guys; needed that. I'm probably a bit overwhelmed and overreacting.
I'll take it slow and eventually I hope all will be revealed.
There's a point to be made, for sure, if the language supports or not MI for instance, and what are the workarounds if it doesn't. I agree. But I do find these mostly anecdotal and a higher level abstraction. Generally speaking OO does bring in the added benefit that it describes program design as we are describing the data structures. In OO, the former is an integral and unavoidable part of the latter. So it is a very advantageous paradigm, in that once we click our brains into OO mode most of the thinking is entirely orthogonal to the programming language.
Last edited by Mario F.; 09-02-2011 at 09:56 AM.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Yep... start with a cold-write of something relatively simple. (Say, balancing your cheque book) Look stuff up, consult your texts, compile and run in small stages... you'll get there.
(Nothing gives me a bigger belly laugh than these guys who read a 10 page tutorial and figure they're all ready to write the "next best thing".)
I also enjoy the people who write these tutorials all along the way saying this is easy or simple and then proceed to write code that could never be integrated into a larger more complex system. Good books, IMO, are a much better source to learn from.(Nothing gives me a bigger belly laugh than these guys who read a 10 page tutorial and figure they're all ready to write the "next best thing".)
Last edited by VirtualAce; 09-02-2011 at 11:26 PM.
I'm not arguing against that, Mario. My point is that, practically, there is often a step difference between object oriented design and implementing a system based on that design. Design languages "abstract away" implementation details, which can be a strength and a weakness, depending on the person using it.
Noting we have both carefully qualified our comments to avoid making blanket statements, I doubt our views are worlds apart, even though you are highlighting real-world advantages and I am highlighting real-world challenges.
Oh, I misread. I have to agree with that.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
