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
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
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
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
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
Recent Posts
).
)
