Author Topic: Best way to start learning C++? (Read 50,593 times)

Eóin · « **Reply #25 on:** December 29, 2007, 10:11 PM »

Quote from: superboyac on December 29, 2007, 12:01 AM

Which book shall I get?

When I switched from VB to C++ I found Complete Idiot's Guide to C++ very helpful. It takes you through the language and onto initial OOP concepts. That should be a good base to have, even if the course ended up using Java those basics should still be a big help.

ssb · « **Reply #26 on:** January 03, 2008, 07:43 AM »

I've taught C and Assembly (and C++ later) at college. Twentyfive years later, I still read books about C/C++ (libs, adv techniques etc) discovering something new every day.
So my suggestion to anyone who wants to learn C/C++ is: "Don't expect to get it in a few weeks or months".
Get a few good books and consider some seminars or practice next to an experienced C developer. Despite what you hear, learning to code in C++ (and C) is not an easy task.

f0dder · « **Reply #27 on:** January 03, 2008, 10:34 AM »

Learning to code in C++ is a relatively easy task.

Learning to write great code and understanding the language, however, is quite a task

ssb · « **Reply #28 on:** January 03, 2008, 09:30 PM »

Quote from: f0dder on January 03, 2008, 10:34 AM

Learning to code in C++ is a relatively easy task.

Learning to write great code and understanding the language, however, is quite a task

Exactly

CWuestefeld · « **Reply #29 on:** January 03, 2008, 10:54 PM »

I can't believe that no one is asking what foundational knowledge we're trying to layer C/C++ on top of. (actually, I can't believe that no one is asking why the heck you feel you need C++ in the first place).

There are a few hurdles in C++ development: embracing real object orientation, dealing with pointers, and memory management.

If you've got an OO background from a language like java, or C#, then you might have this covered already. If not, I would suggest first learning one of these, because you'll get an understanding of OO without having to deal with that other hard stuff. Also, their syntax is an evolution of C++ (which is, of course, and evolution of C) so much of what you learn will be directly applicable. These languages also don't offer honeypots of unnecessary complexity like multiple inheritance or (as much) operator overloading, so you'll stay out of bad habits.

Once you've got the OO thing, I would suggest first wading into plain old C to get an understanding of pointers and basic memory management. I started learning C with the classic K&R - the nice, thin, well-written "The C Programming Language" by Brian Kernighan and Dennis Ritchie.

Then layer the C++ on top of that, getting the patterns of C++ memory management (with destructors, structured exception handling, etc.). I'm not sure where to tell you to go for a reference on this. I can tell you that what I did was wrong: if you just pick up Stroustrup's "C++ Annotated Reference Manual" (aka "The ARM") like I did (because that's the kind of reference I was used to for C), you'll immediately get lost.

superboyac · « **Reply #30 on:** January 03, 2008, 11:09 PM »

OK, I'll tell you why I would be interested in learning C++. There are quantitative analyst jobs out there ("quants") that I'm trying to get into. You have to have a strong math and analytical skills to do the job, but furthermore, it's recommended to have some decent programming experience because the job requires you to construct mathematical, statistical models and algorithms. It's been suggested that people should get familiar with C++ to do this. But I've also noticed that a lot of these people use the programming languages in Matlab, Mathematica, and Maple also. Maybe these languages are similar to C++ so I don't know. The important thing is to have a programming background, and C++ is recommended, so that's why I would want to learn it.
Now, I have some programming experience from some introductory courses in college, but nothing I've used in the real world. I did research for a while and used Matlab a lot, and I was pretty good at it. I've been good at programming, but never went beyond sort of an intermediate level.

f0dder · « **Reply #31 on:** January 04, 2008, 01:02 AM »

I would suggest against learning C++ through C, unless you plan to specifically write C code. Unless you're going to deal with very very limited embedded devices or kernel programming, don't get into malloc/free and the muck of pointers in general. Today's compilers are good and std::vector has very very little overhead.

C teaches you bad habits, gets you in the habit of not supporting unicode, and using the horrendously unsafe str* libc functions. Heck, I'd suggest learning C through C++ instead (sticking with procedural design, but using STL instead of wasting time mucking with libc).

Oh, and multiple inheritance is not "unnecessary complexity"; sure, many people have used it wrongly and designed some horribly nasty class diagrams, but it's very useful for adding "decoration" to classes.

CWuestefeld · « **Reply #32 on:** January 04, 2008, 01:54 AM »

Quote from: f0dder on January 04, 2008, 01:02 AM

Unless you're going to deal with very very limited embedded devices or kernel programming, don't get into malloc/free and the muck of pointers in general. Today's compilers are good and std::vector has very very little overhead.

That last sentence is true, but I'm not sure what that has to do with anything.

You're right that in C++ you won't use malloc/free, but the discipline of managing your own memory is (in my way of thinking, anyway) just the same as dealing with new/delete. And in C++ you most certainly will be mucking in pointers, although many of them will be references.

Quote from: f0dder on January 04, 2008, 01:02 AM

C teaches you bad habits, gets you in the habit of not supporting unicode, and using the horrendously unsafe str* libc functions.

True, which is why I suggested starting with java or C#: get into the correct habits through those simpler languages first, and then apply their principles.

Quote from: f0dder on January 04, 2008, 01:02 AM

Oh, and multiple inheritance is not "unnecessary complexity"; sure, many people have used it wrongly and designed some horribly nasty class diagrams, but it's very useful for adding "decoration" to classes.

OK, I admit to a bit of exaggeration, but it's mostly true. I have on many occasions wanted multiple inheritance again for use as mixins (which I think is what you're getting at). But it's generally not needed: most of the time you can accomplish what you want with interfaces and aggregation.

While we're at it, what other C++ constructs do you think he should stay away from? Another that comes to my mind is implicit type conversions.

BTW, one of the concepts from C++ that I really wish I had in C# is const parameters and mutable.

PPLandry · « **Reply #33 on:** January 04, 2008, 02:13 AM »

Quote from: superboyac on December 29, 2007, 05:28 PM

Well, just to clarify, I just want to familiarize with the language. I'm not trying to actually do any functional programming. I just don't want to be rejected from the program because a lack of programming skills. Most people in the field say it's best to know the C++ language in general.

I would think that learning some C# would be just as good. And you can get MS Visual C# Express for free along with oodles of free code, in particular at www.codeproject.com

f0dder · « **Reply #34 on:** January 04, 2008, 02:19 AM »

Quote from: CWuestefeld on January 04, 2008, 01:54 AM

You're right that in C++ you won't use malloc/free, but the discipline of managing your own memory is (in my way of thinking, anyway) just the same as dealing with new/delete. And in C++ you most certainly will be mucking in pointers, although many of them will be references.

You'll want to stay away from "raw" memory allocation (new/delete, new[]/delete[], malloc/free) as much as possible even in C++ (unless you're writing your own containers and know what you're doing) - basically this means std::vector perhaps 95% of the time you'd be considering new/delete for a byte array. Also, smart pointeres whether it be std::auto_ptr or boost/tr1::shared_ptr goes a long way in keeping code safe, while not having too much overhead.

If you do end up using new/delete, it really should be limited to constructors and destructors. Of course this is general advice and there's always exceptions to the rule

Quote from: CWuestefeld on January 04, 2008, 01:54 AM

True, which is why I suggested starting with java or C#: get into the correct habits through those simpler languages first, and then apply their principles.

Yeah, I don't particularly thing C++ is the best language to start with. Heck, it's not necessary for most stuff out there. But if you want to be a fully-fledged programmer rather than a hack-specific coder, I think you ought to have C++ and even C & Assembly exposure, and I don't think that's going to change for the next many years. However, jobs where fully-fledged programmers are needed aren't that many, and they're not increasing, either.

Quote from: CWuestefeld on January 04, 2008, 01:54 AM

OK, I admit to a bit of exaggeration, but it's mostly true. I have on many occasions wanted multiple inheritance again for use as mixins (which I think is what you're getting at). But it's generally not needed: most of the time you can accomplish what you want with interfaces and aggregation.

I think we pretty much agree here. I'd go as far as saying multiple inheritance should only[/b] be used for mixins, but that's an exaggeration as well.

Quote from: CWuestefeld on January 04, 2008, 01:54 AM
While we're at it, what other C++ constructs do you think he should stay away from? Another that comes to my mind is implicit type conversions.

BTW, one of the concepts from C++ that I really wish I had in C# is const parameters and mutable.
Implicit type conversions can be a real pain in the butt, and if you don't know what you're doing, you're ending up in bug & performance hell. Not sure if there's so many constructs that you should stay away from per se, but don't use language features just for the sake of using them; be conservative in using operator (and even member function) overloading, strive for minimal but useful interfaces, apply insulation but don't overdo it, etc.

C# seems like a nice language, I should really get acquainted with it... but nothings going to replace C++ for good, even with quad-core 3GHz processors

Renegade · « **Reply #35 on:** January 04, 2008, 04:25 AM »

Quote from: mouser on October 12, 2007, 12:30 AM

Buy a book.

...on C#...

Stoic Joker · « **Reply #36 on:** January 04, 2008, 04:28 AM »

C# sounds like a nice language ... Right up until you find out that the Code Execution Level Security makes your nifty new toy slightly less portable than a dump-truck with four flat tires.

I Made that mistake only once, and swore never to even go near C# ever again. I'm perfectly happy using runtime free pure Win32 API C++ code. Sure it takes a bit longer to code, but at least I know it'll run anywhere I go when I'm finished.

CWuestefeld · « **Reply #37 on:** January 04, 2008, 12:33 PM »

Oh, I just remembered...

Read the book "Effective C++" by Scott Meyers. Then read it again. It's easily one of the 10 best computer books I've ever read, completely changing my world view. It won't teach you c++, but if you know the language already it will help you understand the language.

f0dder · « **Reply #38 on:** January 04, 2008, 12:41 PM »

Quote from: Stoic Joker on January 04, 2008, 04:28 AM

I Made that mistake only once, and swore never to even go near C# ever again. I'm perfectly happy using runtime free pure Win32 API C++ code. Sure it takes a bit longer to code, but at least I know it'll run anywhere I go when I'm finished.

Except for anything non-windows that isn't emulated - at least dotNET languages (although not the entire framework) has been ported with the MONO project. And gawd, GUI coding with pure Win32 API is so painful... and it's so darn obvious that the PlatformSDK was written years ago, and for C not C++.

f0dder · « **Reply #39 on:** January 04, 2008, 12:43 PM »

Quote from: CWuestefeld on January 04, 2008, 12:33 PM

Oh, I just remembered...

Read the book "Effective C++" by Scott Meyers. Then read it again. It's easily one of the 10 best computer books I've ever read, completely changing my world view. It won't teach you c++, but if you know the language already it will help you understand the language.

Grab his More Effective C++ and Effective STL too, check out C++ Gotchas by Dewhurst, the heavy *Exceptional* books by Sutter, Sutter/Alexandrescu C++ Coding Standards, Gamma's classic patterns book, and you might want to take a look at Fowler's refactoring book as well, even though a bit repetitious and sometimes self-explanatory., it does have good points.

Stoic Joker · « **Reply #40 on:** January 04, 2008, 11:46 PM »

Quote from: f0dder on January 04, 2008, 12:41 PM

Quote from: Stoic Joker on January 04, 2008, 04:28 AM
I Made that mistake only once, and swore never to even go near C# ever again. I'm perfectly happy using runtime free pure Win32 API C++ code. Sure it takes a bit longer to code, but at least I know it'll run anywhere I go when I'm finished.
Except for anything non-windows that isn't emulated - at least dotNET languages (although not the entire framework) has been ported with the MONO project. And gawd, GUI coding with pure Win32 API is so painful... and it's so darn obvious that the PlatformSDK was written years ago, and for C not C++.

ROFL - True, very true! But the code I do is either only for windows, or run from windows ... as part of my job (I'm MCSA). I spend a lot of time working on-site and work off a thumb drive using small diagnostic utilities. I don't like anything that requires an install, or runtimes that have to be installed because there's no guarantee that the client will have it installed. I hate having to dink around installing something just to get something else to run when it should have just run in the first place ... if it were written properly. Which (i think) qualifies me as a picky bastard...

Anyhow... I generally only write what I need in/for the performance of my job. Which as of late has involved a good bit of SQL. Mix that with a MDI interface, GUI code and a ListBox control and you've got a drinking problem waiting for a place to happen.

Renegade · « **Reply #41 on:** January 05, 2008, 03:06 AM »

I mentioned that somewhat seriously. C# is similar to Java and C++ in many ways, but is much more friendly to use than either of those two.

So by learning C# first, you get up to speed without a lot of the dangers that come with C++ and unmanaged code. You're then free to focus on those tricky things in C++ when you get to them, instead of dividing your attention amongst different issues.

You can also do unmanaged code in C# as well, so you've got a lot of choices. With pure C++, your environment limits you in some ways.

From a learning perspective, it seems to make sense to learn to swim in the shallow end before you jump into the deep end. C is "the deep end".

CodeTRUCKER · « **Reply #42 on:** January 05, 2008, 07:07 AM »

I may get in trouble with some of the heavy hitters here (I have before

), but I will tell you that my NANY '08 app, "Trucker's Log Watch," was start to its present functional beta stage in two days and I didn't break a sweat AND it was my first try with EBASIC!. I used Emergence BASIC (SMACK!~ I knew it! f0dder, cut that out!)

All kidding aside, I chose it because it requires no runtimes, no .NET and it makes tiny fast execs. BASIC can be used to learn good techniques or it can cause problems in learning. Take me, I use Emergence BASIC like I've used every other language I have tried just like what little C++ I've used; for instance; I don't use spaghetti code and I can use pointers in EBASIC if I want to.

f0dder · « **Reply #43 on:** January 05, 2008, 10:31 AM »

Quote from: CodeTRUCKER on January 05, 2008, 07:07 AM

I may get in trouble with some of the heavy hitters here (I have before ), but I will tell you that my NANY '08 app, "Trucker's Log Watch," was start to its present functional beta stage in two days and I didn't break a sweat AND it was my first try with EBASIC!. I used Emergence BASIC (SMACK!~ I knew it! f0dder, cut that out!)

As long as you're not using PowerBASIC, I'm not going to smack you - not even if you like that kind of thing

Quote from: CodeTRUCKER on January 05, 2008, 07:07 AM

All kidding aside, I chose it because it requires no runtimes, no .NET and it makes tiny fast execs. BASIC can be used to learn good techniques or it can cause problems in learning. Take me, I use Emergence BASIC like I've used every other language I have tried just like what little C++ I've used; for instance; I don't use spaghetti code and I can use pointers in EBASIC if I want to.

Hummm, good programming practices with BASIC, hummm. You can write okay code even with Visual Basic, but it's so much easier to end up writing utter cruft, because the language is what it is, and how the "standard libary" is structured. I don't know Emergence so can't speak of that, but the implicit type conversions of VB are evil.

CodeTRUCKER · « **Reply #44 on:** January 06, 2008, 01:23 AM »

VB=

EBASIC=

Actually, EB can do 3D, so sumpin's up! Gotta be fast for that!

f0dder · « **Reply #45 on:** January 06, 2008, 03:13 AM »

Quote from: CodeTRUCKER on January 06, 2008, 01:23 AM

Quote from: f0dder on January 05, 2008, 10:31 AM
I don't know Emergence so can't speak of that, but the implicit type conversions of VB are evil.
VB= EBASIC= Actually, EB can do 3D, so sumpin's up! Gotta be fast for that!

Not necessarily, basically any language can farm out to OpenGL or Direct3D... and especially OpenGL is *very* forgiving, even with bad code you could reach 100's of fps even several years ago, until you started doing more complicated stuff.

If EBASIC does 3D, I hope it's implemented in a library way, rather than as "a part of the language", which unfortunately seems to be the trend with BASIC-like languages.