Frustration in learning C++

Printable View

12-31-2011
spaghetticode

Frustration in learning C++

This language is driving me crazy. How did you guys manage to get over a beginner's frustration due to C++'s learning curve?

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. I know that C++ takes a longer time to learn than most other languages, but still...

Sometimes I really think I shoul jack it in and stay with Java or Python. But then again, I *want* to learn C++. No reasons for it except I somehow like the language.

How did you cope with such frustrating moments when you were learning C++?
12-31-2011
cyberfish

Don't worry about learning every little detail about the language. C++ is a very big language and most people don't use 50% of the features.

Just learn the basics, and start having some fun making programs, games, etc.
12-31-2011
manasij7479

(Probably because it was the first one I learnt..) I did not have to deal with much frustration.
But as cyberfish suggested, I learnt stuff like templates and the weird intricacies of OOP...etc. only when I needed them to write a program, not because they were in the next chapter.
12-31-2011
cyberfish

The most important thing is understanding OOP conceptually. If you can explain, in words, what classes, instances, and inheritance mean, the rest is mostly just details.
12-31-2011
MK27

I already had a good grasp of OOP when I went to study C++ and did not feel particularly frustrated, altho it does have it's own particular, very rigidly structured approach.

I still find the syntax more awkward and long-winded than other languages I know (but most of those are interpreted, and so probably less constrained). There are also a lot of slightly bizarre idiosyncracies I find counter-intuitive, such as iostream. Put that together -- into "long-winded idiosyncracies" and it might seem a bit masochistic unless you are using the language a lot.

I do like it tho. I think C++ has a lot going for it; but while some of the features are great, there are others that don't interest me at all, probably because of the nature of what I do with it. I think C++ was designed from the beginning with a strong emphasis on safety mechanisms that make most sense in large, team settings, but that are somewhat irrelevant or irritating on a smaller scale.

What is it specifically you find frustrating? 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.

After that, you may not know everything, but you should be fairly comfortable and able to undertake a serious project without being too hackish.
12-31-2011
CommonTater

Quote:

Originally Posted by dennis.cpp

How did you cope with such frustrating moments when you were learning C++?

If you've been following me on these forums you know I share that frustration BIG TIME. 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.

I coped by bailing on it... perminently.

As I told a friend just the other day... OOP ranks somplace below self-castration on my list of things (not) to do.
12-31-2011
Yarin

I learned C++ along side C as my first true language(s). Only with time did I pick up details, and I still far from know them all.
Of the language's design, I find templates to be the most frustrating. There must be a million better ways to implement meta-programming than the way it's done in C++!
Interestingly enough, I find OOP to be way overrated, it has no real advantage... except in the matter of RAII. Oh how I love RAII. And exceptions.
If C had RAII and exceptions (sorry, context saving doesn't count), then C++ would be a complete waste of bytes.
12-31-2011
CommonTater

Quote:

Originally Posted by Yarin

I learned C++ along side C as my first true language(s). Only with time did I pick up details, and I still far from know them all.
Of the language's design, I find templates to be the most frustrating. There must be a million better ways to implement meta-programming than the way it's done in C++!
Interestingly enough, I find OOP to be way overrated, it has no real advantage... except in the matter of RAII. Oh how I love RAII. And exceptions.
If C had RAII and exceptions (sorry, context saving doesn't count), then C++ would be a complete waste of bytes.

Can't help you with the auto-destruct functions...

But both Pelles C and LCC have full try-except-finally SEH support.

You can always do your cleanups in the try-finally block...
12-31-2011
memcpy

C has an answer to almost everything that C++ can do, with the added bonus of lower-level control of the system.

Exceptions can be done with careful if/else statements, and OOP can be emulated with structs and function pointers.
12-31-2011
whiteflags

Quote:

Exceptions can be done with careful if/else statements,

That's exactly what exceptions avoid.
12-31-2011
memcpy

Quote:

Originally Posted by whiteflags

That's exactly what exceptions avoid.

What's the point of avoiding them? There's no reason to have any abstraction from what's actually happening (don't exceptions rely on some sort of if-else, at an assembly level?), and they serve the same purpose.
12-31-2011
manasij7479

Quote:

Originally Posted by memcpy

What's the point of avoiding them? There's no reason to have any abstraction from what's actually happening (don't exceptions rely on some sort of if-else, at an assembly level?), and they serve the same purpose.

By that logic, the loop constructs are unnecessary... after all, they are all conditional jumps in assembly level, easily done with if and goto !
The result is the same, only more cumbersome; the same can be said for exceptions.
12-31-2011
phantomotap

Quote:

How did you cope with such frustrating moments when you were learning C++?

Don't try to take on the entire language at a single go.

Get the book "Accelerated C++"; take your time doing the exercises. Actually, take your time with every little chunk. For example, don't try to learn the science of programming templates at first; learn to use the templates the standard library provides first.

Quote:

There must be a million better ways to implement meta-programming than the way it's done in C++!

O_o

Naturally. That is a consequence of using facilities to do meta-programming that were not designed for that.

Using C++ templates to do meta-programming is really pushing C++; it literally never has to be understood or directly used.

Quote:

Interestingly enough, I find OOP to be way overrated, it has no real advantage... except in the matter of RAII.

"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.

Quote:

There's no reason to have any abstraction from what's actually happening (don't exceptions rely on some sort of if-else, at an assembly level?), and they serve the same purpose.

O_o

Abstractions are awesome. They ease the burden of handling details. `FILE' is an abstraction. Do you really want to get rid of all of them?

Soma
12-31-2011
whiteflags

Exceptions are more than just if-else, conceptually anyway. The basic point of exceptions is to refrain from handling errors in the code that raised them. It let's the calling code handle the exception however it wants to handle it. In the conditional branching approach you basically have to handle the error right there, or call some sort of handler function. If you want to look at it that way, exceptions just reorganize some very familiar code.
12-31-2011
CommonTater

Quote:

Originally Posted by memcpy

Exceptions can be done with careful if/else statements, and OOP can be emulated with structs and function pointers.

A Crash Course on theDepths of Win32 Structured Exception Handling, MSJ January 1997

Trust me, you can't if/else your way out of that...
12-31-2011
Elkvis

Quote:

Originally Posted by memcpy

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.
12-31-2011
laserlight
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.
01-01-2012
MK27

Quote:

Originally Posted by memcpy

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.

Quote:

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);

Quote:

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.
01-01-2012
Yarin

Quote:

Originally Posted by CommonTater

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

"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...
01-01-2012
iMalc

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.
01-01-2012
wildcard_seven

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.
01-03-2012
Prelude

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.

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.
01-03-2012
Elysia

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.
01-03-2012
brewbuck

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.
01-03-2012
CommonTater

Quote:

Originally Posted by Prelude

There are people who simply don't think in terms of objects.

Did somebody mention my name? :D
01-04-2012
Elysia

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.
01-04-2012
Elkvis

Quote:

Originally Posted by CommonTater

A Crash Course on theDepths of Win32 Structured Exception Handling, MSJ January 1997

that's actually a really good article. too bad the formatting sucks.
01-05-2012
VirtualAce

Quote:

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.
01-05-2012
Yarin

Quote:

Originally Posted by VirtualAce

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_.
01-05-2012
grumpy

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.
01-05-2012
phantomotap

Quote:

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.

++And it is an infection that just spreads and spreads!

Soma
01-06-2012
Epy

Quote:

Originally Posted by grumpy

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.

I used to be like that...there are a lot of older articles on optimization in C that will swear by doing these sorts of things. However, one eventually learns that modern compilers are made to take the simpler statements and perform these optimizations automatically. Modern optimizing compilers want you to simply tell them what you want the program to do in the simplest terms, and hopefully will produce the most optimized product available while preserving a readable code.
01-06-2012
whiteflags

That's a fair point but I think grumpy's is more to the effect it has when you're really doing one thing (bit fiddling) and deliberately trying to be cute (using arithmetic).

There is a certain productivity to being able to do a lot with a line, but that's easier in higher level languages.

Both of these things kind of make you wonder what people really care about.
01-06-2012
Epy

Being in the programming "business", so often one programmer will quickly throw some code together, completely undocumented and cryptic in nature. Then they leave the company, leaving the next person completely lost. People ought to care about readability first and foremost, and if you have to do something cryptic, comment the hell out of that line so that an idiot can understand it. Code can almost be described as beautiful when you program in this way, and it makes it's courteous to the next man.
01-08-2012
VirtualAce

Quote:

comment the hell out of that line so that an idiot can understand it

Comments are great so long as they are correct. Often times code sections get updated and yet the comments do not which is essentially the same as having no comments. Heavily commented code usually results in large incorrect sections of comments b/c most programmers fail to update the comments. As well various integrations and merges can cause the comments to be out of place. I have seen comment sections that began 1 line out of place and about a year later the section was almost 50 lines out of place.

Most of the time when I am learning a new code line I rarely, if ever, rely on the comments. I may refer to them when I just cannot figure the code out but more often than not I will ask someone or find someone to ask that has worked on the code. That sure beats sitting there spinning my wheels all day long.

And remember no matter how much you idiot proof your code there is always a bigger idiot out there. Readability is key but going overboard actually hurts readability. I believe it is a balancing act that you learn through experience.

All times are GMT -6. The time now is 02:13 PM.