Thread: C++ help

Can you post the contents of Body.h

Bien Sur

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

Hmm, don't know why the indents came out like that

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

Code:

Neck = new Object();

Use

Code:

Object Neck();

(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)

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!

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/

Originally Posted by ninja9578

Hey, it compiles!

no probs

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?

Code:

class Warrior: public Creature{
	public:
		Warrior();
		~Warrior();
...

The Creature class has dynamically created objects in it too.

Originally Posted by ninja9578

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?

Code:

class Warrior: public Creature{
	public:
		Warrior();
		~Warrior();
...

The Creature class has dynamically created objects in it too.

The child class' destructor implicitly calls the parent's destructor automatically when invoked, when the "parent" part of the object is deallocated.

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.

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
}

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

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

Originally Posted by Replicon

I highly recommend boost::shared_ptr, lest your application leak like an old lady with bladder problems

I've never really understood people who say this
(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 I also think that there is a check somewhere in the IDE that will tell me if it's leaking.

Originally Posted by Ynot

I've never really understood people who say this
(that C++ is prone to leaking)
all it needs is a bit of forethought

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). Yeah, you all know what I'm talking about.

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.

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)

Good advice.

Originally Posted by ninja9578

Once I get used to C++ I doubt that my program will leak, I'm used to using C I also think that there is a check somewhere in the IDE that will tell me if it's leaking.

Really? What IDE do you use?

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 It's one of the debug features, it watches your memory allocation.

Originally Posted by Ynot

I've never really understood people who say this
(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)

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.

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.

Originally Posted by ninja9578

Why is double deleting a problem? The documentation that I saw said that delete doesn't do anything if the pointer goes to nothing.

That only works on the same pointer, ie:

Code:

int* a = new int;
delete a;
a = NULL;
delete a;

works, but

Code:

int* store;
int* begin() {
    store = new int;
    return store;
}
void end() {
    delete store;
}

int* a = begin();

...

delete a;
a = NULL;
end();

will die horribly, because the store pointer hasn't been set to NULL.

Originally Posted by ninja9578

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.

It's basically a wrapper class for normal pointers, that does reference counting in the constructor and destructor.

Remember: pointing to "nothing" (i.e. 0) is not the same as pointing to an empty memory address which has been deallocated.

Originally Posted by ninja9578

Why is double deleting a problem? The documentation that I saw said that delete doesn't do anything if the pointer goes to nothing.

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):

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.

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.

http://www.boost.org/doc/libs/1_35_0...shared_ptr.htm

That's the official starting point. Like fish said, it's a template for generating a smart pointer.