C++—Hooboy
Post: #1
So I'm about to plunge right back into C-Plus-Plus. Yep, into hell. Or something like that.
I haven't used c++ (except to hack away at other projects and a bit of LLVM excursion) in years, after I realized that I didn't really know how it worked—things like using the 'new' operator instead of malloc confused the hell out of me. (I still don't get why new[] is necessary.) Classes baffled me—I was never quite sure why one needed to declare *anything* virtual—why didn't inheritance *just work*?
Anyway, I've decided to come back to c++ again. For all of its problems, I still like object-oriented programming—the natural hierarchy of things appeals to me, as does the natural way of reusing code with minimal effort. How can I learn c++? Yes, I understand the syntax and stuff; I guess I'd do fine with simple advice (I have Paul J Lucas's The C++ Programmer's Handbook sitting next to me for simple reference). I'm kind of scared by all of the stuff that C++ brings to the table, and I'd like to understand why this is and how I can understand it, and by doing that master it.
Thanks! -Duane
I haven't used c++ (except to hack away at other projects and a bit of LLVM excursion) in years, after I realized that I didn't really know how it worked—things like using the 'new' operator instead of malloc confused the hell out of me. (I still don't get why new[] is necessary.) Classes baffled me—I was never quite sure why one needed to declare *anything* virtual—why didn't inheritance *just work*?
Anyway, I've decided to come back to c++ again. For all of its problems, I still like object-oriented programming—the natural hierarchy of things appeals to me, as does the natural way of reusing code with minimal effort. How can I learn c++? Yes, I understand the syntax and stuff; I guess I'd do fine with simple advice (I have Paul J Lucas's The C++ Programmer's Handbook sitting next to me for simple reference). I'm kind of scared by all of the stuff that C++ brings to the table, and I'd like to understand why this is and how I can understand it, and by doing that master it.
Thanks! -Duane
It's not magic, it's Ruby.
Post: #2
If you like OO, C++ isn't for you 
Try Objective C instead. It's simpler, and OO.
For the specific examples you cite, new and new[] call constructors that malloc and friends can't, and calls to nonvirtual functions are more efficient than virtual functions, and classes with no virtual functions are layout-equivalent to plain C structs (though struct and class are almost synonymous in C++).
Sorry, no helpful suggestions on how to actually learn that stuff.
Try Objective C instead. It's simpler, and OO.For the specific examples you cite, new and new[] call constructors that malloc and friends can't, and calls to nonvirtual functions are more efficient than virtual functions, and classes with no virtual functions are layout-equivalent to plain C structs (though struct and class are almost synonymous in C++).
Sorry, no helpful suggestions on how to actually learn that stuff.
Post: #3
I would think you'd be more confused as to why delete[] is necessary. (the answer being that new[] must call each object's constructor, as OSC mentioned, and also that it needs to store some extra info which is used in delete[] to call all the object's destructors when deleted)
C++ is indeed a strange beast, and though OSC denies it, is very useful when you want to have some sort of OO design to your code while having it run fast and efficiently. It does require a good deal of knowledge and discipline, however, as it is very easy to screw yourself over. If you're not careful, or don't know what you're doing, you can run a good risk of either messing up your memory or doing something that destroys your performance. (copying large objects when passing them as parameters definitely comes to mind)
The way I learned C++ was by reading a decent amount of the manual (The C++ Programming Language by Stroustroup) and by writing some programs with it. I also had a bit of experience with C, Objective C, and Java at the time as well. Of course, your milage, and patience, may vary. If you try to learn C++, I will suggest that you focus on the core set of features that are the most useful, such as classes, templates, references vs. pointers, new/delete, and maybe operator overloading and a few others, and understand how they work. For the more cryptic features, maybe know about their existence in case you ever see them or need them, but don't burden yourself with them. You'll just be detracting from the important pars of the language, and run the risk of implementing something with a fancy cryptic feature because it's cool, which can ultimately cause many problems in the end.
(the answer being that new[] must call each object's constructor, as OSC mentioned, and also that it needs to store some extra info which is used in delete[] to call all the object's destructors when deleted)C++ is indeed a strange beast, and though OSC denies it, is very useful when you want to have some sort of OO design to your code while having it run fast and efficiently. It does require a good deal of knowledge and discipline, however, as it is very easy to screw yourself over. If you're not careful, or don't know what you're doing, you can run a good risk of either messing up your memory or doing something that destroys your performance. (copying large objects when passing them as parameters definitely comes to mind)
The way I learned C++ was by reading a decent amount of the manual (The C++ Programming Language by Stroustroup) and by writing some programs with it. I also had a bit of experience with C, Objective C, and Java at the time as well. Of course, your milage, and patience, may vary. If you try to learn C++, I will suggest that you focus on the core set of features that are the most useful, such as classes, templates, references vs. pointers, new/delete, and maybe operator overloading and a few others, and understand how they work. For the more cryptic features, maybe know about their existence in case you ever see them or need them, but don't burden yourself with them. You'll just be detracting from the important pars of the language, and run the risk of implementing something with a fancy cryptic feature because it's cool, which can ultimately cause many problems in the end.
Post: #4
And remember, you're not a C++ guru until you understand how diamond protected nonvirtual multiple inheritance of partially-specialized template classes works
Post: #5
I don't really plan to use most of C++'s features (templates? Not much use, as far as I can see, in a game or rendering engine.) Operator overloading is nice, but the real boon is integration with third party libraries. Also, much of C++'s "improvements" (e.g. references—I'd much rather use pointers and dereference if I want to) are just fluff. I'm most worried about complications with C++'s classes and memory management—I've been burned by missed deletes many times before I had the sense to switch to objective-c. I would, however, like to know what I did wrong, or even better: learn how to use C++ correctly.
It's not magic, it's Ruby.
Post: #6OneSadCookie Wrote:And remember, you're not a C++ guru until you understand how diamond protected nonvirtual multiple inheritance of partially-specialized template classes works
Which is why there's about 3 or 4 at most C++ gurus in the world. And accordingly, (virtuall) everybody who says they're a C++ guru is lying.
Post: #7Duane Wrote:I'm most worried about complications with C++'s classes and memory management—I've been burned by missed deletes many times before I had the sense to switch to objective-c. I would, however, like to know what I did wrong, or even better: learn how to use C++ correctly.
Check out Boost's smart pointers. They've made my life so much easier it's almost a religious experience. It's almost like having garbage collection.
Post: #8OneSadCookie Wrote:And remember, you're not a C++ guru until you understand how diamond protected nonvirtual multiple inheritance of partially-specialized template classes works
So… do you understand that?
Post: #10OneSadCookie Wrote:Nope. I'm not even sure it made sense
If it doesn't make sense, I wonder if even those who have extensive knowledge of C++ would dare call that bluff? That'd be a pretty twisted way to make a point about C++ being twisted.
Post: #11OneSadCookie Wrote:And remember, you're not a C++ guru until you understand how diamond protected nonvirtual multiple inheritance of partially-specialized template classes works
Oh, it's the thing with the spork, the duck, and the twin brunettes, no?
It's not magic, it's Ruby.
Post: #12
While templates aren't strictly necessary, they can be very useful in many situations. Fast and simple to use data structures is the prime example, as well as supporting many (or multiple) types with one function or class declaration can reduce the amount of code you have to write. It also lets you do some neat tricks that are messy to implement, but provide a nice interface to handle something tricky. For most uses, though, think of any place you need to use a void * because you don't know what type is being used. In those cases you can often use templates to make things more type safe, as well as introduce compiler optimizations such as inlining and getting rid of dereferences where it would otherwise not be possible when using a void *.
Post: #13OneSadCookie Wrote:And remember, you're not a C++ guru until you understand how diamond protected nonvirtual multiple inheritance of partially-specialized template classes works
OSC this is an English speaking Forum, please try and keep it that way.
Post: #14
http://www.parashift.com/c++-faq-lite/mu...l#faq-25.8
Add some protected member variables in the class, and there ya go: diamond protected nonvirtual multiple inheritance.
And for partially-specialized template classes (haven't read the article, I was just curious so I googled it)... http://www.cprogramming.com/tutorial/tem...ation.html
Add some protected member variables in the class, and there ya go: diamond protected nonvirtual multiple inheritance.
And for partially-specialized template classes (haven't read the article, I was just curious so I googled it)... http://www.cprogramming.com/tutorial/tem...ation.html
Post: #15
"protected inheritance" does *not* refer to a class with protected member variables. FWIW, here's diamond protected nonvirtual multiple inheritance:
Code:
class A {};
class B : protected A {};
class C : protected A {};
class D : protected B, protected C {};
