Thread: Frustration in learning C++

  1. #16
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    Quote Originally Posted by memcpy View Post
    C has an answer to almost everything that C++ can do, with the added bonus of lower-level control of the system.
    wrong. C has no lower level control of anything than C++ has. C++ is nearly 100% backwards compatible with C, so that nearly any valid C program is a valid C++ program. what C has as an advantage in system programming is its type-safety on pointers. you cannot simply assign one pointer to another of a different type in C++. you must perform an explicit cast, and that is a good thing. if C had type-safe pointers, many, if not all, pointer bugs could be completely avoided.

  2. #17
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Quote Originally Posted by dennis.cpp
    How did you guys manage to get over a beginner's frustration due to C++'s learning curve?
    I was taught C++ in school after having experimented with Javascript and PHP. Frankly, I did not experience a frustration with the learning curve, any more than say, the learning curve of the economics or physics syllabus. It was just a matter of: okay, there's this assignment to complete, what do I need to know to complete it? Taking it one step at a time helped, even though we were using a pre-standard compiler in the standard era (MSVC6, and the year was 2002) with a teacher who used the "start with C and C++ I/O only" approach and never talked about useful stuff like the standard containers.

    Quote Originally Posted by dennis.cpp
    I've tried several languages, Java, Python, C... in all of which I actually saw my progress. Not so with C++. I like working with my textbook, I like the language... but I do have the feeling I'm not really moving on.
    How do you know that you are "not really moving on"?

    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.

    Quote Originally Posted by MK27
    Beyond the elementary types and flow control, I think you do need to get comfortable with, in order:

    1) the basic OO methadology including inheritance,
    2) the more common STL containers such as vector and map,
    3) how templating works.
    In Effective C++, 3rd Edition, Scott Meyers suggests viewing C++ as a federation of languages:
    • C
    • 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:
    Quote Originally Posted by Scott Meyers
    Keep these four sublanguages in mind, and don't be surprised when you encounter situations where effective programming requires that you change strategy when you switch from one sublanguage to another.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #18
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by memcpy View Post
    C has an answer to almost everything that C++ can do, with the added bonus of lower-level control of the system.
    That's not really true, since you can use pure C in C++ when and if you want to.

    OOP can be emulated with structs and function pointers.
    I think many/most C programmers

    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:

    Code:
    //C
    method(object, params);
    //eg, C++
    object.method(params);
    Exceptions can be done with careful if/else statements
    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.
    Last edited by MK27; 01-01-2012 at 08:39 AM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  4. #19
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by CommonTater View Post
    But both Pelles C and LCC have full try-except-finally SEH support.
    It also occurred to me that GCC can compile C with exceptions too.

    Quote Originally Posted by phantomotap View Post
    "RAII" is a part of C++ because it supports scoped construction and destruction of objects. It has nothing to do with "OOP". You will not find "RAII" techniques in a "OOP" book aimed at any other language.
    True as that may be, I've always seen it as a part of OOP because of the whole reliance on a class. However you prompted me to find that GCC supports a "cleanup" variable attribute C extension which is pretty neat...

  5. #20
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    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.
    Last edited by iMalc; 01-01-2012 at 03:00 PM.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  6. #21
    Registered User
    Join Date
    Jul 2010
    Posts
    86
    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.
    I made a pair of "Braille Gloves" which have 6 vibration motors in six finger tips and vibrate in the relevant patterns. I have used this to read stuff while out walking. Given there is a fairly well defined programmer-oriented Braille encoding I should imagine it would work in this situation. Diagrams could be a pain still.

    Note: I am not blind but have learnt Braille fairly easily so for me it works quite well

    Disclaimer: I haven't tried this while driving yet...

  7. #22
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    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.
    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.

    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.
    My best code is written with the delete key.

  8. #23
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #24
    Officially An Architect brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,396
    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.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  10. #25
    Banned
    Join Date
    Aug 2010
    Location
    Ontario Canada
    Posts
    9,547
    Quote Originally Posted by Prelude View Post
    There are people who simply don't think in terms of objects.
    Did somebody mention my name?

  11. #26
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  12. #27
    Registered User
    Join Date
    Oct 2006
    Posts
    3,445
    that's actually a really good article. too bad the formatting sucks.

  13. #28
    Registered User VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,607
    Interestingly enough, I find OOP to be way overrated, it has no real advantage...
    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.

  14. #29
    Unregistered User Yarin's Avatar
    Join Date
    Jul 2007
    Posts
    2,158
    Quote Originally Posted by VirtualAce View Post
    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.
    Don't get me wrong, I know OOP (including C++, Python, & JS), mostly through Python, which makes heavy use of it (and duck typing too, which is interesting in it's own right).
    "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_.

  15. #30
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    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.
    Last edited by grumpy; 01-05-2012 at 10:21 PM.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Frustration with tutorial.
    By A34Chris in forum C Programming
    Replies: 19
    Last Post: 03-18-2008, 03:08 AM
  2. Frustration
    By curlious in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 09-29-2003, 02:22 PM
  3. Frustration ...
    By goran in forum A Brief History of Cprogramming.com
    Replies: 8
    Last Post: 08-06-2003, 11:21 PM
  4. DLL frustration
    By robid1 in forum C Programming
    Replies: 4
    Last Post: 06-22-2003, 03:37 AM
  5. Frustration
    By kas2002 in forum C++ Programming
    Replies: 4
    Last Post: 05-29-2002, 05:00 PM