Is C++ easy to understand

Operator overloading is for when you want an homologous syntax and semantics between representations not related hierarchically. That's the basis for how the entire Iterators and Ranges concepts work in C++, one of the best examples, IMHO. The syntax is there to be used in the cases where it aids semantics. If you don't need to aid the semantics, just don't use it, and you have then the advantage that if someone tries to impose semantics on the usage of your type representations, they get compile errors.

As for the whole "memory is not important", "migh as well have infinite memory" and "Java is easier to learn", I'm not in the mood to fetch the link to the article yet again, but you can just go google "Perils of Java Schools" and learn quite some interesting stuff.

That said, C++ is definitively not the language to begin doing stuff. That's more for languages like Python.

Okay well it seems the OP asked the worst question possible cuz of all the deeeeeraaaaaaail.

But let me answer it clearly here.

Easiest languages (in order of easiest to hardest) to learn are:

• VB (and I will punch you in the face if this is what you are learning)
• Java or C#
• C++ or C
• Assembly

Now I will tell you the purpose of learning ALL of those.

• VB -> Gets me to punch you. Getting punched builds character.
• Java/C# -> Teaches you OO design very well. I think it is excellent for this.
• C++ or C -> Teaches you to do everything yourself, learning code from ground up with no library assistance. It also teaches you about pointers and memory management. It's all about efficiency. The main reasons you learn this before Java despite it being harder is so that you don't become those Java jackasses that don't care about efficiency or memory (ie. writing code worth paying you a hefty salary for) and not being a total frigging douchebag about exceptions or memory boundaries. You do something wrong, KABOOM your program explodes.
• Assembly -> It's good to know how things are actually working to get a better sense of what is happening "behind the scenes". This is also good if you pair it with in-line C assembly, so you see direct conversion between for-loops and so on with actual assembly code. While dealing with assembly, you'll likely be learning hardware concepts (hardware interrupts, drivers) and also operating system concepts (how context switching works is the most important)

edited 1st Jun '11 5:12:20 PM by breadloaf

Can't say I'm a fan of operator overloading. It doesn't make anything any clearer to me.

Anyway, I recently discovered Vala: http://live.gnome.org/Vala

C# syntax, but with the performance of C! And with a single stroke, as far as I could care C++ was rendered completely obsolete. Of course, I never liked C++ myself anyway (tending to take views more like these), so that's coming from a ridiculously biased starting point (plus the zeal of a new convert).

C++ also doesn't have any proper support yet for functional programming, which many would argue is actually a better way to start learning. It's certainly an entire separate world from OOP that you'd be missing out on, as well as quite possibly the best programming textbook ever written.

(Context: I get to use whatever I want for my work, so I spend most of my time writing in Lisp/Scheme; therefore all of my opinions are pretty much automatically stupid.)

edited 1st Jun '11 5:17:11 PM by Jinren

This reasoning stopped making sense to me after TAOCP made me wonder how malloc worked.

I wanted to ask a TON of questions about programming, languages, and learning, and was wondering whether I should make my own thread, or ask in this one, though I'm afraid that's rude and hijacking. But making a thread about all this stuff ALSO seems to be rude and hijacking attention away from this one >.<

We have a "Coding/Programming" thread in Yack Fest.

+1

edited 1st Jun '11 5:18:05 PM by Tzetze

Ugh, yack fest?

...I don't think so xD

(Gonna check it out still)

edited 1st Jun '11 5:20:33 PM by ViralLamb

Memory pretty much IS infinite, as long as you don't leak. No matter how big your memory is, if your program leaks, you're going to run out of it pretty damn fast.

As if that ever stopped anybody.

That is, of course, assuming you're programming for a PC architecture. For small integrated things, it's a whole 'nother ballgame (which is, of course, why virtually everyone programming for these things uses C or assembly).

I read once that Firefox's memory bloat problems were due to overestimating the necessary size of buffers rather than a lack of deallocation, for what it's worth...

It looks like the person who wrote the FQA is Completely Missing The Point. And has apparently never heard of Pimpl either.

The only legitimate criticism I've seen is that the syntax is too complicated and loaded with legacy c junk.

edited 1st Jun '11 6:10:18 PM by storyyeller

My main gripe with C++ on a theoretical level is due to its hybrid nature, which makes it feel it's not the best choice for any application. It doesn't do C level stuff as well as C or high-level OOP stuff as well as the more modern OOP languages. It's more of a jack of all trades, master of none language, but even Python feels like it fits that role better.

However on a practical level, C++ does benefit a lot from being widely known and having great library and tool support - which counts for an awful lot.

C++ has the disadvantage of stealing features from other languages (such as Smalltalk), but only half-heartedly.

For educational purposes, I would completely skip C++. Just go from C straight to C# / Java, then skip straight to Lisp/Scheme or Groovy to learn about funky things you can do with functions.

For work: C++ is not something that people do to have a fun, satisfying, fulfilling career in which they can bring in new things like garbage collection and STL libraries when they think they need them. Maybe if it's for an open-source project, it might be worth it. Otherwise, stick with a language that is completely on one side of the fence, either pure C or something else.

Of C++? I think that's the main gripe, yes, though again I'm given to understand that the binaries are hard to deal with, not that that matters for anything but somewhat esoteric projects.

By the way, re:smalltalk, does anyone know a good way to learn it? Squeak looks wrong on my screen.

The binary issue is has to deal more with libraries. Basically, any library, static or shared, compiled with one compiler has no guarantee to work with another compiler. This only applies to code compiled as c++ code.

As for smalltalk I would check out GNU smalltalk.

To the OP, C++ is a big language and growing, so I would say it is hard to understand all of it.

Totally shilling here, but after you check out Smalltalk you might be interested in Objective-C. It's basically C with Smalltalk OO syntax. It looks like how you'd expect a chimera of two different languages to look, but you can do some interesting stuff with it and it's the thing to use for Mac and iOS programming.

I also hear Ruby uses Smalltalk-based syntax, but I haven't ever used that language so I can't say for sure.

I'd ask what's so bad about Visual Basic, but I'm afraid I'd get my head shot off. I know it gets a lot of disrespect, but I suspect that's because it's so easy that any nitwit can write crappy code in it. I will say that if you need to code something for an Office application, you need to learn VBA or do without.

All this conversation makes me wish I had paid more attention to C++ than I did back in the day, but as it turns out, enterprise application development, which is where I landed, rarely uses third-level languages. It's all fourth-level stuff.

edited 1st Jun '11 9:33:43 PM by Fighteer

From what I gathered from reading the Daily WTF and making my own judgement calls I say you got it right. I would just word it: With visual basic, morons can write horrible code but have the app be functional and business critical too easily.

Also depending on how long "back in the day" was, it may not help too much with modern c++ code. You can blame the introduction of templates and the fact that modern c++ templates are turning complete.

And of course, now you've got partially implemented C++0x features to play with. Unfortunately, I'm stuck with GCC 4.4 so I can't use constexprs yet.

VB's syntax contains a bunch of inconsistencies and things that make the C programmers go "?!" For instance:

 Dim Foo(1 to 10) as Integer
Dim Bar(0 to 9) as Integer

 Dim Baz(-5 to 5) as Integer 

Just to add to the confusion, Baz is an item longer than either Foo or Bar.

edited 2nd Jun '11 3:59:14 AM by Yej

My main gripes with C++:

• Multiple inheritance: Very doubtful, maybe useful in some very rare cases, but mustly just something you want to avoid
• Operator overloading: Very nifty on the surface, but an open invitation to abuse

And my most beloved feat:

• Pointers AND references in the same language. To me, having two nigh-but-not-quite-identical features is something of a "language design smell". Yeah I know one can learn to understand the difference and why and how to use it, but I always found it rather unintuitive.
  • Actually, pointers AND references, objects AND primitive types like int. Duh.

I still do have a lot of perverse love for C++ though, since it was my first flirt with OOP, and I will always fondly remember how voodoo those concepts seemed to me back then. ;-)

Is it easy to learn? I don't think so. The headaches start as soon as you try to transform code that was written without const-correctness into const-correct code, and they just do not end.

Basically, a "perfect language" for me (which I know cannot really exist of course) might have the following features:

• No pointers
• Interfaces
• No inheritance (syntactically encouraged composition instead)
• Everything is an object
• Parameters are always by-ref
• An easy way to return a list of values from a method (might be useless because of by-ref, but yeah)
• A flexible, generic and uniform method of delegation
• Inclusion of functional features
• A good way to annotate parts without side-effects for concurrency
• No way of using literals in the code - putting them in a centralized, easy to find location is enforced
• Strong types
• STATIC TYPES!
• STATIC TYPES!!
• STATIC TYPES!!!

edited 2nd Jun '11 6:24:38 AM by vijeno

Actually, I did have a situation recently where multiple inheritance would have been quite nice. I was trying to bolt on some (common) functionality to all of the GUI element classes at once. (But it included member variables, so extension methods didn't help.)

Also, how do you compose classes in a way that isn't just inheritance by another name?

edited 2nd Jun '11 6:32:08 AM by Yej

What to you call "static types" exactly?

PS: If by "everything is an object" you mean "no primitive types, gc-heap-allocated stuff only" then your language will encourage bloatware.

However, if you mean "primitive types are actually value types with special handling" like C# does, then I'd support it.

edited 2nd Jun '11 6:33:05 AM by Medinoc

I mean static types as in, the compiler can determine the type of each expression. I freely admit that dynamic typing has a lot of advantages, but I've dealt with so many excellent coders who came to prefer static over dynamic typing because it helps them discover potential bugs much faster, and I finally became convinced that the advantages outweigh the disadvantages.

Well, yes you do need operators for primitive types, and I wouldn't demand that they be actual objects behind the scenes - to me, that's an optimization issue more than anything else. They should seamlessly tie into the object world, though.

Maybe without inheritance, operator "overloading" (or in this case, defining) might actually be beneficial. There should be a uniform way to define those operators for the "primitive" types, obviously.

PS: It's not as if this was a well-thought-out, lasting strategy of mine. Just a few ideas going through my head, rather.

edited 2nd Jun '11 6:47:21 AM by vijeno