Originally Posted by dennis.cpp
How do you know that you are "not really moving on"?Quote:
Originally Posted by dennis.cpp
phantomotap suggested learning from the book Accelerated C++. I second that suggestion. I did not learn C++ from that book, but its "high level to low level" pedagogy makes sense in treating C++ as more than just "C with classes". C++ has progressed far beyond that.
In Effective C++, 3rd Edition, Scott Meyers suggests viewing C++ as a federation of languages:Quote:
Originally Posted by MK27
- Object-oriented C++
- Template C++
- The STL (or rather, the parts of the standard library and other libraries based on the STL)
His point is that we should:
Originally Posted by Scott Meyers
I think many/most C programmersQuote:
OOP can be emulated with structs and function pointers.
a) would not refer to OOP in C as an "emulation" unless it was to stop some nut barking; altho it does not have a formal structure, it is still essentially OOP and C is capable of providing the basic OOP framework (inheritable object classing). The OOP terms "class" and "object" are not unusual in C APIs.
b) would not actually use function pointers unless there was a real need for them, and would avoid such a need. Thus the difference between a method call in C and a method call in more formal OO languages is:
Not quite. Exceptions allow you to (easily) write a class or a library or whatever with fatal triggers than can be avoided IF the user does proper error handling. In C using if/else or some other form of testing would allow you to (easily) go unavoidably fatal if a parameter is wrong, OR set/return an error and hope the user does proper error handling. Exceptions allow for a philosophy. They are not necessary to accomplishing any task properly, but they provide an opportunity to be a little more friendly and formal WRT to improper use. However, I believe exceptions come at a cost.Quote:
Exceptions can be done with careful if/else statements
It's probably a lot more fustrating when you're learning programming at the same time as learning C++ I imagine.
Already being very fluent in Object Pascal, learning C++ was mostly just a matter of learning different syntax for me. Of course you don't learn everything at once, so various bits like templates, operator overloading, and SC++L all just come later on to boost ones knowlege.
And of course I'm still learning. I learnt about tag-dispatching just two days ago.
What things do you find hard?
CommonTater, I had no idea you were a proudly non-OOP person. In every case that I've come across someone like that it was because they tried to learn OOP by creating their own OOP stuff. Unfortunately it's so often taught by getting the student to start out writing their own OOP stuff right off the bat. There's no sense trying to write OOP stuff until you know how to use it and have learnt how much easier it makes things.
The best way to learn OOP is actually to initially just use lots of existing OOP stuff, e.g .NET, or *shudder* MFC, or a ton of other object oriented frameworks. Then after some time you progress towards tweaking the existing OOP stuff that you have the souce code for, then adding functionality to it, then replacing existing classes with your own versions, then writing small helper classes like RAII containers, and then writing other larger classes that do more stuff, and finally using polymorphism to grow on top of existing stuff.
You most definitely have the capability in you.
A common mistake is to think of programming as a skill that is "different" from other skills. What I mean is, to have the silly notion that, "Hey, I'm a smart guy. I work hard for a year or two, I'll be making the next big program in no time!"
If you wanted to golf like a pro, you wouldn't entertain the notion that you put in a few hours on the weekend, practice your swing in front of the mirror now and then, and you'll be on your way...you'd understand that you'd need YEARS of dedication...swing after swing after swing....countless hours and repetition before the game really began to sink in.
I heard somewhere that you need to do something 10,000 times before you master it. So, let's say you've built your 30th program now. Just keep building more. Keep going even if you think they suck. You have to get through the first 5,000 crappy efforts before you start to get your groove and approach "perfection" on try number 10,000 or so.
There are people who simply don't think in terms of objects. I'm also one of those who finds OOP very unnatural. As far as the concepts and practices go I "get it", but it all just feels wrong to me. ;)Quote:
No matter what I do I can't distort my head into "OOP Think" and eventually gave up... but not for the lack of trying.
As was mentioned before concerning C++ features, the same goes with OOP. Learn the bare minimum for recognizing when a problem would best be solved with OOP, and don't sweat learning more until one of those problems pops up.
A lot of beginners I meet are shocked to discover that professionals tend to go into projects from a position of ignorance and will learn whatever is needed along the way. That's why the ability to research and figure things out on one's own is so critical in our field.
Ah, I know the feeling.
So how does one deal with it? One way is to simply accept that some things are beyond your skill level (as for right now), and simply concentrate on what you know.
Undoubtedly there will be many things which you simply have no idea what they're useful for or how they work. But that's fine. You don't need to understand just yet.
Continue applying your own knowledge, implement stuff, fix bugs and read books and do exercises.
And above all, do not give up! If you find something you just don't understand, don't throw your hands up in disgust. Take a break, sleep it off and continue the next day.
Higher level stuff is not something you learn at the beginning. Good knowledge always comes with time. As time passes, you get smarter and you will come to realize more and more things.
So to sum it up:
Ignore all the high-level stuff you don't understand. You don't need to understand it just yet.
Continue reading good tutorial/immediate/experts books, do exercises and implement stuff.
And finally, give it time. You don't learn a language (computer science or real world language alike) in a year.
If you feel comfortable with Java, I'm surprised you find C++ baffling. Close your eyes and pretend it's Java. When that crude analogy starts failing for you, maybe we can help.
This isn't something you learn in a day. As you use the language, you will put its features to use, which in turn will "create" the whole "OOP thinking," as you apply design techniques to get the code as you want.
Put simply, if you just use the language features to their extent (and continue practicing!), the "OOP thinking" will grow on you.
OOP is extremely valuable if not a bit hard to grasp at first. OOP concepts are not limited to C++ and C# has used and expanded on a great many of them as well as a host of other languages. The advantages of OOP are best revealed in a large studio with hundreds of programmers. Done right it promotes loosely coupled code which in turn promotes the idea that one department can be working on one portion of the code line and another department on another and when you bring them together there should not be a massive integration effort. However this requires a good design to achieve this level of separation and modularity but once it is built into the code line the advantages of it are enormous both from a developer perspective and a cost perspective. Notice that no new languages are moving back towards a C mindset but are expanding in the spirit of C++ and adding more to OOP than C++ currently supports. OOP is a godsend but just like all tools it can be misused and abused.Quote:
Interestingly enough, I find OOP to be way overrated, it has no real advantage...
"Loosly coupled" software can just as well be written in a non-OOP language.
I simply find it to be overrated (that is, not a "godsend"), I am very comfortable with OOP and non-OOP, and find that what ever I might need to accomplish in OOP can just as well be done in non-OOP, though, at times, at the cost of extra code, this is usually by _very little_.
The frustration I have with learning C++ - when writing code - is the same as I have with any programming language: the mapping of my ideas unambiguously into understandable source code.
I personally don't like C or C++ syntax all that much, but that doesn't frustrate me all that much. My main source of frustration, however, is other students of C or C++. Those who slavishly insist on premature optimisation. Those who delight in squeezing 25 critical side effects into a single unreadable statement. Those who insist on using a bitwise operation to divide by 2, and those who insist on multiplying by 2 in order to shift bits. Those who open their IDE and madly typing away, with no real understanding of the problem they are trying to solve, and then cry for help when their code does not "just work". The programmers who only use one compiler, learn to rely on obscure features of that compiler or its library, and then insist there is nothing wrong with their code when another compiler rejects the code. There are those who don't write code themselves, instead begging, borrowing, or stealing other people's code .... and then asking someone else to adapt that code for a new purpose.
I'm not a particular fan of "loosely coupled" code, but I don't condemn it. I have seen some programmers who use "loosely coupled" as a synonym for "a lot of random bits thrown together". Similarly with paradigms like OO or structured or functional or ..... all of those rely on the programmer (or system designer) thinking in a particular logical manner ..... and the main source of frustration is programmers who use the latest buzz-word techniques or paradigms or libraries without thought.
Every time I see a programmer insisting "this is just a one-off", I cringe. About 90% of the "one-off" programs I see in a professional setting will end up being reused in real-world programs, and become the sources of maintenance and debugging nightmares over years because they were written as a "one-off", the recurring excuse to leave something incomplete and partly functional.
And don't even get me started on the "not invented here" syndrome, and recreation of wheels.