[zehawk]

I bet one of have been there. You learn Java, or some other Higher Level Language and find out about C++. You become interested in it, and want to use it for it's speed, flexibility, some-what low level functionality. All of a sudden, you hear that it's a hard language and shouldn't be learned in today's market.(Which is complete bs I mind you!)
Now, I've taken this road and decided to self-teach C++. I mean, with no mentors and only a book, C++ For Dummies. It's the one with seven sub-books in it or something. But all the while, I program and I begin to ask myself, why do people find C++ so freaking hard? I find it easier than Java at times, and Is now my favorite language. Yes, I have a few times where I need to look for bugs, but it's no different than any other language. Here's my list of common arguments against C++ and why I find them invalid:

-"It's a bloated language". Um, and Java isn't? Java has a larger API to work with, and sometimes you have to find the easier way to get it done. Also, take C++ peice by peice. Learn only what you need to at the moment.

-"Pointers are very scaarryy." Ok, I find pointers incredibly EASY. when you call new, call delete. Set the pointer to NULL. When using a pointer, always check to see if it's null. Is that too hard?

-"OMG HEADER FILES!" Seriously? For each variable in a header file call extern, for a function, just use the declaration. And if header gaurds confuse you, google is your friend.

-"Pointers to Pointers!" Ok, people make this sound worse than it actually is. Yes, I try to avoid this at all time, but the truth is, it's pretty darn neccesary in some instances. I'll say that if you have issues one real quick google search can solve your problems.

-"No ffing garbage collection!" You better be thanking the creators of C++ for that rather than scolding them.

-"Arrays arrays arrays!" There are several websites out there to help you tackle problems like these. I understand them pretty easily, an array just points to an address in memory where there's a list of values of the same type, and the pointer points to the first one in memory.

-"Preproccesor?!" I only ever use define and include in my code. Define for constants(I'm not really into allocating memory for constants if I can help it, but I'm not sure if this is bad practice? Someone tell me?) and include for header files... duh...

-"Not a beginner's language." I started out using basic functions with cout << and cin. I eventually started to learn about file systems, and then a small part of WINAPI so I could work on OpenGL.(I wanna be a video game designer when I'm older). Start simple. Just because arrays exist doesn't mean you have to use it until you're comfortable with the basics. That's how I was and I'm sure no proffesional programmer started out teaching themselves the hardest things about a language either.

-"C++ is often taught wrongly." The only claim that scares me. Can anyone give examples of well known mis-taught concepts?

Now, I don't try to think I'm an expert on this, but c'mon. C++ isn't really that hard. Maybe I haven't worked with the harder stuff like templates, structs, or macros yet? I've been experimenting with OpenGL and made a library, so perhaps C++ just comes easy to me? I rarely gbet bugs and I can smash them rather simply, although they often surprise me. Can someone tell me why they thought C++ was hard or some things that ARE hard about it? Thanks in advance:)

p.s., yes I acknowldge it's a hard language to fully master, but it's not a hard language to get your feet into big projects and say, make a game with. Really, it's not. Unless of course, you're trying for the 100% most speed and absolute memory management with. I still a learning. It'll come when I learn it.

[ButchDean]

What makes a language hard, or the actual ability to determine if you really understand it or not, would be to write complex software using that language. Going through a book doesn't make you a guru.

[sepp2k]

"Use delete once for every time you call new" might sound simple on paper or in small and in small programs, but until you've written a large(ish) project in C++, you won't know how much pain memory management can be if you don't carefully design your project. Memory management issues are the most common source of mistakes in C and C++ programs and I'm not talking about programs written by beginners.

Regarding header files: I don't think the reason that people complain about them is that they make C++ hard to learn or understand. It's that maintaining your header files is additional work that wouldn't be necessary if the language were designed in a different way. They're also one additional thing you have to keep in mind when specifying dependencies in your Makefiles.

Regarding the preprocessor: Using it for advanced use-cases is very error-prone and rightly discouraged in C++. Using #define for constants isn't really all that error-prone, but it's not type-safe, so it should still be avoided. Note that global (or static member) variables that are const, will be inlined by your compiler and thus not take up any memory space unless you take their address somewhere (which of course isn't the case if the variable can be replaced with a #define).

The fact that header files are included using the preprocessor, i.e. pure text substitution, leads to a couple of problems. Specifically you can get horribly misleading error messages when you include a header file that contains a syntax error (like a missing semicolon at the end) because the compiler only sees the preprocessed cpp file and might tell you the error is in your cpp file and not in the header.

It can also lead to horribly long compilation times (especially in combination with templates) and there's plenty of tricks and patterns that have been invented solely to keep down the amount of code and #includes you need to put in header files. So clearly this is recognized as a problem.

[baavgai]

The very things that many C++ desirable, it's flexibly, multiparadigm support, ability to get close to the hardware, etc, make it a challenge. Simply, it's easier to screw up in C++. Much easier than C, actually, because C++ bugs often come with cloaking devices.

In contrast, you have to go out of your way to make a memory leak in Java or .NET. You can still do it, but you have to work for it.

No matter what language you're using, large projects are an exercise in complexity control. There is no easy path to reduce complexity, because it comes from the programmers themselves. A language that imposes limitations does the programmer a favor in some ways. C++ is big on no limitations, so the ability to also produce complexity is unhindered.

[darek9576]

Wow. You read C++ for Idiots and you are the master.

Awesome.

This post has been edited by darek9576: 11 July 2012 - 10:56 AM

[vividexstance]

I'm not going to go through the whole list, but most of the items in that list are either misinformed or just flat out wrong. Being that C++ is compatible to C, it encompasses all of C and all that C++ has to offer. The new C++ standard adds many new things to the library and also the language itself. To take a quote from Bjarne Stroustrup, the creator of C++:

Quote

Question: What do you think of C++11?
Answer: That's a (to me) amazingly frequent question. It may be the most frequently asked question. Surprisingly, C++11 feels like a new language: The pieces just fit together better than they used to and I find a higher-level style of programming more natural than before and as efficient as ever.

If you don't mind reading an e-book, there's a free one that's pretty in-depth: Thinking in C++. And if you are truly serious about learning C++, here's a list of some tutorial / reference books:

• The C++ Programming Language: Special Edition
  
• The Annotated C++ Reference Manual
  
• The C++ Standard Library: A Tutorial and Reference (2nd Edition)

There's obviously more books than that, but those books deal mostly with the language itself and the standard library. There's another post somewhere in the C/C++ forums (might be stickied) that has a good book list as well.

*EDIT*: Here's a link to Bjarne Stroustrup's website. Here's a link for a very nice C/C++ reference site and you should definitely bookmark it. This one is just C++ and is probably the most up-to-date reference site on C++11: http://en.cppreference.com/w/.

The Boost C++ libraries are also nice to have and they're free so here's a link: http://www.boost.org/.

You mentioned you learned a little of the Windows API and OpenGL, here is IMO a very nice multimedia/graphics library that is portable and can be used with OpenGL and many other libraries: SFML.

This post has been edited by vividexstance: 11 July 2012 - 11:08 AM

[ishkabible]

raw pointers are confusing if your new to programing, some might find it more difficult to understand than Java objects. as baavgai, errors in C++ tend to be clocked or horribly obfuscated(templates), some compilers handle this better however(clang). memory managements is hard, even for me. I try to keep all memory management well encapsulated and use STL containers as much as possible; GC helps quite a bit. it's also lower level and has implicit truncation(int to char, float to double, float to int, int to float, etc...).

side note: as a language, C++ is very complex. Java, as a language, is very simple. C++'s standard library is very simple, Java's is very large. it's a trade off in a way.

[Skydiver]

zehawk, on 11 July 2012 - 09:07 AM, said:

Now, I don't try to think I'm an expert on this, but c'mon. C++ isn't really that hard.

Look at the documentation for the class std::pair<>. Looks simple enough. It's just a struct that hold two values, and some support functions, right?
http://en.cppreferen...pp/utility/pair

Now crack open the utility header file and look at the implementation. Can you say with a straight face that you understand how auto pair1 = make_pair(n, a[i]); works just looking at the code for less than 5 minutes?

[sepp2k]

Skydiver, on 11 July 2012 - 09:29 PM, said:

Now crack open the utility header file and look at the implementation. Can you say with a straight face that you understand how auto pair1 = make_pair(n, a[i]); works just looking at the code for less than 5 minutes?

In the util header on my platform (or more accurately bits/stl_pair.h which is #included by the util header), the implementation of make_pair looks like this:

template<class _T1, class _T2>
inline pair<_T1, _T2>
make_pair(_T1 __x, _T2 __y)
{ return pair<_T1, _T2>(__x, __y); }

That looks straight-forward enough to me. The C++11 version looks more complicated though.

Either way I don't think the implementation of the standard library is a good measure of how complicated a language is. Most language's standard library implementations won't be very easy to understand. They're not usually written with readability in mind. After all you don't need to understand their exact implementation to use them.

[zehawk]

Hey, I think some of you guys made some good points. I'm here to say that from what I've experienced, with making the library, I've never found C++. I'm as far to say it's because I've used Java for awhile. Also, I know some of the things in my list where false. Pointers aren't scary really, Header files aren't really all that bad(I was enlightened to some of their problems though, so thanks!), and about the whole standard library being complicated -Just use what you need to use. I mean, learn the basics of the important things, but don't learn everything by heart. I'm learning something new everyday. Well, I am a beginner of course.

I've come up with some good points that I've seen:
-C++ is a huge language whereas Java is a huge API. This was a great point, and now that I see it, it's pretty true! That may be what makes it harder to learn, but C++'s library isn't as big of a part of the language is as opposed to Java, as boost and WinApi have their own libraries. So I'm focused on the language, not the API.

-Header files have their own pitfalls. Yes, header files do have problems. I know what you mean too, about bugs being in the object files instead of the header files, so it's harder to debug. However, I never put source code in header files, only method declarations and variables. Class and enum declarations also go in header files, and all source goes to .cpp files. So in my experience, it hasn't been too big of a deal.

-Bigger projects get harder. Yes, true true! I've noticed that writing a small OpenGL program is harder than a console application(If you're using cout to learn about c++, obviously console applications can get complex fast if you're a proffesional). But, bigger projects == harder work is true of all languages, not just C++. So I'll just have to see what happens when I learn more and advance to more projects.

-Bigger projects and pointers. I can actually see how this gets complex real fast. I'm talking mostly about learning C++, and I think that it isn't really that hard to learn. All languages can get hard if complex enough, so I'm mostly talking about why people think C++ is hard to learn.

Thanks everyone for the answers, I've learned quite a bit. I'll do my hardest to try studying C++ harder as I now saw how hard the language can get at times. I would like to close telling you guys that I AM A BEGINNER. Meaning, I have a lot to learn and maybe C++ will get harder to learn as I advance. I never said that I was a guru or a master just because I read a book. I'll be checking out the websites recommended to me, and thanks everyone:)

[sepp2k]

zehawk, on 12 July 2012 - 02:19 AM, said:

-Header files have their own pitfalls. Yes, header files do have problems. I know what you mean too, about bugs being in the object files instead of the header files, so it's harder to debug. However, I never put source code in header files, only method declarations and variables. Class and enum declarations also go in header files, and all source goes to .cpp files. So in my experience, it hasn't been too big of a deal.

That is the right approach, but it doesn't work with templates (and inline functions). With templates you have to have the function implementations in the header files.

That said it really isn't that big of a deal. The big issues with header files are really the additional effort and the effect on compile times.

[Bench]

zehawk, on 11 July 2012 - 05:07 PM, said:

-"Pointers are very scaarryy." Ok, I find pointers incredibly EASY. when you call new, call delete. Set the pointer to NULL. When using a pointer, always check to see if it's null. Is that too hard?

But what if you've called new and then some part of your code throws an exception before the delete is called? Or perhaps if you've passed a copy of the pointer to somewhere else and you end up calling delete on the object prematurely?

If it were really as simple as you describe, code which uses manual memory management would never cause any problems, and there would be no need for smart pointers, but the fact is that considerable effort has been made within the C++ community over the past 20 years to ensure that raw pointers can be avoided 99.9% of the time; and luckily we are finally in a position in 2012 where you can write large amounts of C++ code without ever needing to touch a 'raw' pointer yourself.

zehawk, on 11 July 2012 - 05:07 PM, said:

-"OMG HEADER FILES!" Seriously? For each variable in a header file call extern

Seriously? extern variables (a.k.a Global variables) in a header file?

Alternatively, delete the variable from the header file completely and come up with a better designed solution which doesn't involve global variables or singleton classes in the first place; Creating stateful objects which are modifiable from any part of your code is a very sloppy habit which results in complex spaghetti-code that can be difficult and time consuming to debug when something goes wrong (especially if that code uses multiple threads)

zehawk, on 11 July 2012 - 05:07 PM, said:

-"Pointers to Pointers!" Ok, people make this sound worse than it actually is. Yes, I try to avoid this at all time, but the truth is, it's pretty darn neccesary in some instances. I'll say that if you have issues one real quick google search can solve your problems.

I can't even remember the last time I encountered any real situation where it was actually necessary. again, references and smart-pointers makes this scenario more-or-less obsolete. Perhaps there's some legacy code lying around where its unavoidable, but that should be wrappable quite easily so that it doesn't spill out and make a mess

zehawk, on 11 July 2012 - 05:07 PM, said:

-"No ffing garbage collection!" You better be thanking the creators of C++ for that rather than scolding them.

Garbage collection is not a bad thing, in fact the ISO C++ committee were in more-or-less unanimous agreement that C++ would benefit from it, so C++11 has added deterministic garbage collection in the form of std::shared_ptr and std::unique_ptr. (In fact C++98 already had a very primitive kind of smart pointer called std::auto_ptr, but that has now been deprecated since it was borderline useless). Resource cleanup (not just memory!) is one of the main challenges found in C++ code, so anything which makes it simpler can only be a good thing.

zehawk, on 11 July 2012 - 05:07 PM, said:

-"Arrays arrays arrays!" There are several websites out there to help you tackle problems like these. I understand them pretty easily, an array just points to an address in memory where there's a list of values of the same type, and the pointer points to the first one in memory.

No it doesn't, an array is a contiguous block of memory, there are no pointers involved in declaring an array whatsoever. Please read these two FAQ answers:
http://www.c-faq.com...tr/aryptr2.html
http://www.c-faq.com...ryptrequiv.html

zehawk, on 11 July 2012 - 05:07 PM, said:

-"Preproccesor?!" I only ever use define and include in my code. Define for constants(I'm not really into allocating memory for constants if I can help it, but I'm not sure if this is bad practice? Someone tell me?) and include for header files... duh...

This is a FAQ, definitively answered here: http://www.parashift...-vs-define.html

zehawk, on 11 July 2012 - 05:07 PM, said:

-"Not a beginner's language."

That depends; a beginner who wants to learn C++ wouldn't help themselves by wasting time learning Java, Python, or any other language; and Bjarne Stroustrup successfully uses C++ to teach his first-year university students C++ as their first language. However, not everyone who wants to learn to program wants to be a C++ programmer, and plenty of universities don't teach C++ - the best beginner language always depends on the beginner in question.

zehawk, on 11 July 2012 - 05:07 PM, said:

-"C++ is often taught wrongly." The only claim that scares me. Can anyone give examples of well known mis-taught concepts?

I've encountered plenty of graduates who have 'C++' on their list of programming languages, yet they're often completely unaware of many issues described on this webpage, which are things that all C++ programmers absolutely need to know before I'd feel comfortable allowing them to touch a commercial C++ project.

The education problem stems from books and universities teaching C++ as 'a better C', they ignore discussions on essential topics such as vectors, iterators, smart pointers, const correctness, etc; It's not a complete disaster, but it means graduates start out being C programmers rather than C++ programmers, and learning C++ from C is a much harder struggle than going the other way since it involves un-learning things which you probably struggled to learn in the first place.

It's not uncommon to see junior C++ programmers (Who have been taught C++ as C-with-classes) writing code with their own hand-rolled linked lists/trees with their justification being that they don't trust/understand the standard library containers; usually that's the start of a long rally of code-review-tennis and a painful process of persuading them to stop using arrays, pointers and singleton classes all over the place.

To compound the problem, most books out there haven't been properly updated in 15-20 years (At best most have merely had a few chapters added); unfortunately those old books seem to get naively positive reviews on amazon. The worst offenders are 'C++ for dummies', 'Sams C++ in 21 days', Dietel+Dietel 'C++ How to Program' and 'C++ Primer Plus'.
To contrast, there are a few books such as Koenig's Accelerated C++ and Stroustrup's Principles and Practice using C++ which put a much greater emphasis on treating C++ as a language in its own right instead of leading its readers down the garden path with all kinds of antiquated C techniques.

zehawk, on 11 July 2012 - 05:07 PM, said:

Now, I don't try to think I'm an expert on this, but c'mon. C++ isn't really that hard. Maybe I haven't worked with the harder stuff like templates, structs, or macros yet? I've been experimenting with OpenGL and made a library, so perhaps C++ just comes easy to me? I rarely gbet bugs and I can smash them rather simply, although they often surprise me. Can someone tell me why they thought C++ was hard or some things that ARE hard about it? Thanks in advance:)

The real difficulty which any programmer faces is understanding and using somebody else's code. If you've never worked with anyone else's code before, then you probably won't see the difference (But I bet if someone else came along to try working with your code they'd run into all kinds of problems).
It's fairly well known that all projects suffer degredation of quality over time; it happens just as much in Java and C# - and maybe even more so. Yet in C++ the effect of degredation can be far more pronounced due to legacy code and the ways that a little change "over here" can have a drastic unintentional consequence for something "over there", but diagnosing such problems can be painstaking - especially where the original code has been written in a 'C' style.

Sometimes it may be something as simple as holding onto a new'ed object for longer than the original creator of the program intended, at which point that pointer may be destroyed under your feet without you ever knowing (until the software ships out to the customer and you get a bug report back). These sorts of problems are not always consistently reproducible either - if you're lucky, it'll be a simple step-by-step mechanical scenario, but often it's something "weird", and you might be stuck without any exception/stack trace info from a bug report to help you out. (C++ Smart pointers actually address this problem, but unfortunately they're not used enough yet)

The other major issue which really sets C++ apart from newer language is that of tooling; Unfortunately there'll probably never be tools for C++ which have the same kind of static code analysis as some of the Java and .NET tools which you can get ahold of (e.g. ReSharper and CodeContracts for C#); and while tools such as Lint are fairly good at picking up some mistakes, they can only do so much with a language which is notoriously difficult to parse.

[baavgai]

Bench, on 14 July 2012 - 04:55 AM, said:

graduates start out being C programmers rather than C++ programmers

I think it's actually worse than that. A C programmer learns to write C code; period. A C programmer in C++ is generally writing neither C nor C++.

I'm on the fence with C++ as a starter language. Some concepts are universal. Learning them without C++ adding extra esoteric considerations might be beneficial. Then again, programmers from other languages often make really bad assumptions about how C++ might do something...

I think, rather than C++ as smarter C or more complex Java, you might be better off with plain old C first. Then you might apreciate what C++ has to offer without ingnoring the C underbelly.

Bench, on 14 July 2012 - 04:55 AM, said:

issues described on this webpage, which are things that all C++ programmers absolutely need to know before I'd feel comfortable allowing them to touch a commercial C++ project.

Agreed. Love Scott Meyers' books. But that haircut, man. That's just not doing anyone any favors...

[TheAnonymouse]

I think C++ is a little a confusing at time. Also, how reasonable/trustworthy is C++ for dummies? The Programming for Dummies books are usually very weak.

[NickDMax]

There is an old piece of advice that if someone claims to "know C++" then they probably don't. The idea being that C++ is a complex and deep language and you never really stop learning.

I think there is a lot of kick back away from C++ and Native code in general because people get their fingers burnt and move on. I am not just talking about Programmers either. Project Managers watch projects fail as overly ambitious teams tackle and fail at complex projects. Some "wiz kid" on a project writes a function with a memory leak that haunts the project for years of intermittent crashes. The kinds of troubled waters C++ covers can leave you longing for the safety of managed languages.

Complexity expands. It is like a really sticky paste that once on your hands keeps snagging other things no matter how many times you try to contain it. This is C++.

Quote

-"C++ is often taught wrongly." The only claim that scares me. Can anyone give examples of well known mis-taught concepts?

This has always been true (C++ is generally taught as an enhancement to C) but is even MORE true with modern C++ since C++ was ALWAYS taught wrongly! Our view of the language has changed so much over the years and modern C++ really looks very little like the 1980 or 1990's books make it out to be.

C++ is not a procedural language, it is not an OOP language, it is not a "generic" language, it is not a functional language, it really defies most classifications. "Nobody puts baby in a corner".

So to really "Master C++" you have to take a Zen-like approach and realize that you can never "Master" the language but you will learn balance.

Don't just scoff an all of the concerns you listed as problems "Amateurs" run across. They are all "valid" concerns that come out of experience with C++. It is your job to find ways to keep them manageable.