How long does it usually take to become fluent in C++, but not exactly a master? I heard that this is one of the easy ones, so I want to start practicing soon.
By the way, what books/tutorials do you recommend?
> I heard that this is one of the easy ones, so I want to start practicing soon.
Whoever told you that is yanking your leg. C++ is a particuarly complicated beast as far as languages go.
>>1
I learned the basics of C++ from "C++ In Plain English," and then found "Tbe C/C++ Programmer's Bible" as a useful reference for more of the complex details. But I had also learned C before C++, which I personally suggest you do as well.
>>1
go for bjarne stroustrup's C++ book. That is the best reference out there.
This is true, but you missed the original question. One can safely become fluent in C++ while completely ignoring most of the complexity, and focusing on a simple subset of the language.
> focusing on a simple subset of the language.
C?
> One can safely become fluent in C++ while completely ignoring most of the complexity, and focusing on a simple subset of the language.
Pretty much everything on that page is academic, and not an issue in practice, and certainly not if you are limiting yourself to writing simple C++, so it's hardly relevant.
All right. Let's talk fluency of a simple subset of C++.
What do you consider that simple subset? C + objects? Or the more recent 'right' way that involves Boost, RAII and all that?
I think that nobody says "fluent in cabbie english", and nobody says "fluent in japornime japanese", and these are spoken languages- languages designed for redundancy. Languages designed to impart partial understanding as a kind of graceful degradation.
Programming languages aren't like that. They're designed to be specific and exact and to not degrade at all. Learning a programming language is about learning how to be specific- and becoming good at that language is about learning how to read and understand that specificity well.
There is no simple subset of C++ because there's no way, looking at a >> b that you or any other C++ programmer is going to know what is going on. Unless you're comfortable with that fact, you're simply not going to be able to be very specific with C++, and as a result what you learn will be nearly useless.
Instead, learning to be specific is easiest in a language with what is called context free grammar. That means you can learn (within a few hours) what a >> b actually means. Exactly. Specifically. Lots of languages have this property. C++ doesn't.
> How long does it usually take to become fluent in C++, but not exactly a master?
Took me about a month, but I was stuffed into a small room with a Maths PhD and a CompSci MS who had powerful motivation to teach me -- I was to take over most of their mundane workload once proficient. I was also already fluent in several of the more cushy languages (C#, ECMAScript, Java, Ruby), which helped a lot. The killer with C++ is not necessarily the language spec (although >>2 is correct, it's a beast) but learning the 15,000,000 different libraries that everyone uses.
> I heard that this is one of the easy ones
This is simply not true at all. Writing real applications (that don't suck ass) in C++ is one of the hardest programming tasks. As >>10 points out, C++ is a pretty fungible language. Things like Duff's device are a good example of this.
> what books/tutorials do you recommend?
"The Annotated C++ Reference Manual" by Margaret E. Ellis and Bjarne Stroustroup. Any other C++ book is pretty much a waste of time. If you can't understand the language in this book, gb2/vb or php or w/e over-glorified scripting language you came from and learn how to read the technical specs of those languages. Once you're more comfortable reading technical spec docs in general, this book can more or less teach you C++ in a few days assuming you're relatively intelligent. However, it will not teach you how to structure code and such (e.g., applied programming). For this, your best bet is to just start hacking on large projects, keeping your mind open to new heuristic techniques.
An open mind is really key over all, as becoming proficient with C++ will likely change the way you think. Also, anyone who advocates fluency in C++ while only looking at a small subset of the language is in for some serious pwnage the first time they have to debug someone else's code that's riddled with shit like bit shifting, two's complements, stl containers, pointers, *_cast<>, and multiple inheritance. In fact I kind of want to be there when that happens -- I've never actually seen a soul crushed in person before.
> the first time they have to debug someone else's code that's riddled with shit like bit shifting, two's complements, stl containers, pointers, *_cast<>, and multiple inheritance.
two's complement? what are you talking about sir? (i know what two's complement is, do you?)
I'm talking about the tilde (~) operator in C++ that is used to determine the bitwise complement of a number. Sorry if I was not specific enough to begin with. First time I saw that in production code was a big WTF moment for me, at least. I don't have a traditional compsci (or even math) education though, so perhaps the observation was a bit too subjective?
D is a pretty good alternative to C++. It avoids a lot of bullshit like having to take into account type sizes being different on every platform, although I don't think it lets you ignore the endianness being different on different platforms. :-/
It has garbage collection too, although this isn't a magic wand.
I see it kind of like an alternative to Java but which compiles to native code (Java can compile directly to native code too, but it isn't supposed to do this by design whereas D is.)
If you can't handle a simple bitwise not or shift, you're really not much of a programmer, I'm sad to say.
> The result of ~ operator is the bitwise complement of its promoted operand.
> That is, each bit in the result is set if and only if the corresponding bit in the converted operand is not set).
> The integer promotions are performed on the operand, and the result has the promoted type.
> If the promoted type is an unsigned type, the expression ~E is equivalent to the maximum value representable in teat type minus E.
No, it's called "complement". One's complement and two's complement are related to the bitwise complement, but mean different things:
http://en.wikipedia.org/wiki/Signed_number_representations#Ones.27_complement
http://en.wikipedia.org/wiki/Signed_number_representations#Two.27s_complement
Fluent? 10 years.
>>10 That means you can learn (within a few hours) what a >> b actually means.
That's easy. It's a bit shift.
>>20 except in C++ where it can mean anything.
Well no, doesn't >> simply mean "invoke the method called operator>>" ?
Only for very useless definitions of the term "mean", and only if you're wrong, too: It might be a primitive data type which doesn't really have a method. The operator precedence rules can be confusing on exactly what >> is operating on.
A more useful definition of the term "mean" would say that it "means" whatever the body of that function means. The fact that you have to cross-reference every lexeme in C++ is why nobody likes C++ programmers.
a > b means that a is greater than ba >> b means that a is really greater than b
Retards.
>>27
That makes perfect sense! Thank you.
>>28
that is not an english word why did you say it
those are not roman characters why did you read them