Printable View
Been a long long time since I've written anything in C++, I'm getting back into it. I need a little help, because I don't understand the errors :P Here's the error and the setup of the groups. I have other files that try and create the same type of objects and they don't give me errors.
http://img81.imageshack.us/img81/9319/picture1mm4.png
Can you post the contents of Body.h
Bien Sur
Hmm, don't know why the indents came out like that :?Code:#ifndef BODY_H
#define BODY_H
#include "Object.h"
#include "Limb.h"
class Body{
public:
Body(); // parameterless default constructor
private:
Object torso;
Object neck;
Object head;
Limb leftarm;
Limb rightarm;
Limb leftleg;
Limb rightleg;
};
#endif
Ok,
You're allocating the objects dynamically (using new)
so the members in Body.h need to be pointers
(new returns a pointer to the object on the heap)
Code:private:
Object* torso;
Object* neck;
Object* head;
Limb* leftarm;
Limb* rightarm;
Limb* leftleg;
Limb* rightleg;
Either that,
or change how you allocate the objects in Body.cpp
Instead of
UseCode:Neck = new Object();
(whether you allocate dynamically or not is down to exactly how you're going to be using the objects later on - if they're large, dynamic's always a good idea, as there's limited space on the stack)Code:Object Neck();
Ooooh. Damn university taught me java, is there ever a more useless language? Is there a good C++ book like 'C in a nutshell'?
Hey, it compiles! :thanks:
Bjarne Stroustrup (the guy who developed C++) has written a few books
Eg.
http://www.amazon.co.uk/C%2B%2B-Prog...0291486&sr=8-2
His stuff tends to be very involved, though
Any good book store should have loads of C++ books,
over a wide range of skill levels
but to be honest, most of the info is online anyway
check out
http://www.cprogramming.com/
and
http://www.cplusplus.com/
no probsQuote:
Originally Posted by ninja9578
If you've gone the dynamic way, remember to free objects after you've finished with them
else you'll have a memory leak
see these for dynamic memory / pointers
http://www.cprogramming.com/tutorial/lesson6.html
http://www.cplusplus.com/doc/tutorial/dynamic.html
Oh right, I have to write a destructor. Damn java's garbage collector made me loose everything that I knew about C++.
Remember to make those destructors virtual as well, if you've got an inheritance hierarchy going on anywhere.
Oh crap, I didn't think that through. I have a parent class with some stuff in it, which needs to be purged on calling the destructor, but what happens if I call the destructor for the child class? Will it run both?
The Creature class has dynamically created objects in it too.Code:class Warrior: public Creature{
public:
Warrior();
~Warrior();
...
The child class' destructor implicitly calls the parent's destructor automatically when invoked, when the "parent" part of the object is deallocated.Quote:
Originally Posted by ninja9578
However, if you want to work with pointers to the parent class and want to call destructors generically, you need to make the destructor virtual in the parent class.
twoA was a pointer to an A object that in reality held a B (a B being a type of A), yet when the object was deleted the B's destructor was called. Also note that the when the object referenced by the B pointer oneB was deleted the destruction sequence performed identically to the twoA pointer object, with the A destructor being called automatically when oneB was deallocated. You do not have to explicitly call the destructors of parent classes in the destructors of children (and probably should not, it really adds nothing to your code nor to readibility).Code:#include <iostream>
using namespace std;
class A
{
public:
A();
virtual ~A() {cout << "A destructor" << endl;} // virtual power!
};
class B: public A
{
public:
B();
~B() {cout << "B destructor" << endl;}
};
int main()
{
A * oneA = new A;
A * twoA = new B;
B * oneB = new B;
delete oneA; // prints: A destructor
delete twoA; // prints: B destructor /n A destructor
delete oneB; // prints: B destructor /n A destructor
}
This should also remind you that a class destructor should only deal with the variables and pointers that the class explicitly contains within itself (in the case that a pointer object needs to be deleted, etc.), meaning it should leave pointers it inherited alone for its parent to deal with. Variables and pointers that are inherited and need to be deleted upon destruction should ONLY be deleted by the parent class destructor. In other words, your child classes should mind their own business and not mess with their parent's belongings.
If by chance the child DOES have to delete inherited pointer objects for some reason (though I recommend against this for design and modularity concerns), make sure to set the pointer to 0 after deleting its object to disarm the pointer in case the parent destructor tries to delete it again, which it should as I already mentioned (deleting an already deallocated pointer is death to your program -- deleting a null pointer set to 0 is safe). Still, it's better to avoid the problem altogether with good design and strict encapsulation.
If you got stuck figuring out this compile error, I highly recommend boost::shared_ptr, lest your application leak like an old lady with bladder problems ;)
Also, read Effective C++ by Scott Meyers. Some of it might be a bit involved, but everything is bite-size enough that you can process it. Plus he writes extremely well (he's also a fantastic public speaker).
I've never really understood people who say thisQuote:
Originally Posted by Replicon
(that C++ is prone to leaking)
all it needs is a bit of forethought
Now, I'm completely self taught, and I'm well aware I don't do everything "by the book", so people will probably disagree with some of these, but just from personal experience
- initialise in the constructor, free in the destructor
- always make sure pointers are initilised (set to NULL if not used right away)
this means no "dangling" pointers, and any automatic free'ing done by destructors won't fail
- always assert not null before dereference - this protects against seg-faults if something has gone wrong with the allocation
- once free'd, re-set pointer to null (while not usually necessary, it's useful if you do need to allocate and free member pointers outside of con/de/structors)
Once I get used to C++ I doubt that my program will leak, I'm used to using C :P I also think that there is a check somewhere in the IDE that will tell me if it's leaking.
That's why it's prone to leaking, it requires foresight and sometimes we make a devastating blunder. We've all had at least one of those embarassing "missing semicolon" errors that completely breaks the code and we spend hours looking for it, only to notice it after we give up in frustration and come back the next day (or week:shock:). Yeah, you all know what I'm talking about. ;)Quote:
Originally Posted by Ynot
Still, I agree with your main point. All you really have to remember is that you need to uphold a 1:1 correspondence between new and delete instructions.
Good advice.Quote:
Now, I'm completely self taught, and I'm well aware I don't do everything "by the book", so people will probably disagree with some of these, but just from personal experience
- initialise in the constructor, free in the destructor
- always make sure pointers are initilised (set to NULL if not used right away)
this means no "dangling" pointers, and any automatic free'ing done by destructors won't fail
- always assert not null before dereference - this protects against seg-faults if something has gone wrong with the allocation
- once free'd, re-set pointer to null (while not usually necessary, it's useful if you do need to allocate and free member pointers outside of con/de/structors)
Really? What IDE do you use?Quote:
Originally Posted by ninja9578
I use a handy freeware UML tool called BOUML for design and code generation, and Code::Blocks for compiling and error-checking.
I use XCode, there is a picture of it in my first post :P It's one of the debug features, it watches your memory allocation.
Good intentions are never enough, and of all the bugs out there, memory leaks are usually among the toughest to track down. It's usually not as simple as making sure the news and deletes lign up. Stuff gets passed around, ownership gets transfered, things get double-deleted, assumptions are not met, and things throw exceptions and wind the stack.Quote:
Originally Posted by Ynot
I'm not saying smart pointers are the be-all end-all of solutions (you can still "leak" with them, usually in the form of cyclical dependencies), and they certainly are no replacement to foresight and design, but they sure make life simpler. Ultimately, a 50K line of code application written with smart pointers will leak less than a 50K line application written with only naked pointers ;-)
I know that the Apple IDE does memory leak checking, doesn't .NET? .NET is just as powerful if not more so.
Why is double deleting a problem? The documentation that I saw said that delete doesn't do anything if the pointer goes to nothing.
What's smart pointers? Is that kind of what java does by not letting you explicitly call something a pointer? Then you have to set up the garbage collector.
That only works on the same pointer, ie:Quote:
Originally Posted by ninja9578
works, butCode:int* a = new int;
delete a;
a = NULL;
delete a;
will die horribly, because the store pointer hasn't been set to NULL.Code:int* store;
int* begin() {
store = new int;
return store;
}
void end() {
delete store;
}
int* a = begin();
...
delete a;
a = NULL;
end();
It's basically a wrapper class for normal pointers, that does reference counting in the constructor and destructor.Quote:
Originally Posted by ninja9578
Remember: pointing to "nothing" (i.e. 0) is not the same as pointing to an empty memory address which has been deallocated.
Well, technically, after you delete something, the memory becomes available to the OS to have its way with it. So double deleting can have some of the following effects (and then some):Quote:
Originally Posted by ninja9578
1) Nothing
2) Attempt to delete memory that doesn't belong to you and fail miserably (often crash)
3) If the memory was re-allocated to the same application, it'll try to delete it, and then it'll leave your application in some inconsistent state. This is the nastiest one to debug, since the symptoms occur in seemingly-irrelevant places in the code.
In short, double deleting officially yields undefined behaviour.
http://www.boost.org/doc/libs/1_35_0...shared_ptr.htmQuote:
What's smart pointers? Is that kind of what java does by not letting you explicitly call something a pointer? Then you have to set up the garbage collector.
That's the official starting point. Like fish said, it's a template for generating a smart pointer.