ATTENTION: You are viewing a page formatted for mobile devices; to view the full web page, click HERE.

Other Software > Developer's Corner

Best way to start learning C++?

<< < (7/10) > >>

superboyac:
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:
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:
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.-f0dder (January 03, 2008, 07:02 PM)
--- End quote ---

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.

C teaches you bad habits, gets you in the habit of not supporting unicode, and using the horrendously unsafe str* libc functions. -f0dder (January 03, 2008, 07:02 PM)
--- End quote ---

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.

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.-f0dder (January 03, 2008, 07:02 PM)
--- End quote ---

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:
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.
-superboyac (December 29, 2007, 11:28 AM)
--- End quote ---

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:
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.
-CWuestefeld (January 03, 2008, 07:54 PM)
--- End quote ---
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 :)

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.
-CWuestefeld (January 03, 2008, 07:54 PM)
--- End quote ---
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.

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.
-CWuestefeld (January 03, 2008, 07:54 PM)
--- End quote ---
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.

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.
-CWuestefeld (January 03, 2008, 07:54 PM)
--- End quote ---
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 :)

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version