next »

[BlueSweatshirt]

I don't think it's even necessary to bother with this issue, since the pointers aren't handling any data that isn't contained elsewhere.

Basically, my component structure is based on polymorphism(a design pattern I'm probably not fully competent with.)
When I'm declaring a pointer to be placed in the ComponentList, no data is allocated with new. It goes like this:

Code:

Component* Comp = &ChildClassInstance;

And I inject that into the ComponentList.

So once the object holding all of the data is deleted, the memory should be freed, no?

[Crimsontide]

Polymorphism isn't a design pattern, think of it rather, as a tool in ur programming toolbox.  You can use polymorphism to implement a design pattern, but it itself isn't a design pattern (at least in any practical sense).  Don't worry, it'll eventually make sense.

The problem with:

Code:

Component* Comp = &ChildClassInstance;

is that ChildClassInstance isn't allocated with new (as you mention) so I imagine u have something somewhere in ur code along the lines of:

Code:

ChildClass ChildClassInstance;

Problem is ChildClassInstance is created on the stack, which means as soon as the function (or enclosing scope) which created the ChildClassInstance exits, the ChildClassInstance is deallocated as well.  If you store the pointer to it (in this case in a container), all u'll end up with is a dangling pointer (ie. an error, probably a page fault when u try to run the program) once the ChildClassInstance is deallocate.  Now it might not be a problem (if you know all ur Component's will always live for the duration of your ComponentList), but in that case don't delete the pointers in the ComponentList destructor.

In C++ u have 2 types of memory allocation.  You either use new/delete, in which case C++ figures u know what's best and lets you do whatever u want.  But in that case you as the programmer has to make sure every new has a corresponding delete, otherwise you get memory leaks (and possibly nastier errors).  The other option is to let C++ handle it and it allocates memory on the stack.  But if C++ handles it, it will delete the memory at the end of the enclosing scope.  In which case any pointers or references to the object become invalid, and trying to access the object (which no longer exists) through an invalid reference or pointer is an error.

Keep that in mind, as neither the twain shall ever meet.  You never want to delete an automatic variable (one declared on the stack) as that can cause BIG problems.  The reason why I bring all this up is that its VERY rare for automatic variables to be stored in a list like the one you proposed, and is most likely due to a misunderstanding of the difference between new/delete and automatic variables.

[BlueSweatshirt]

Well, I already encountered the exact error you mentioned. That error being the data from creating the automatic variable being freed, and me losing my pointer.

I've, thankfully, found a simple solution to this.
Since the data is already being stored in an object, I can just have "ChildClassInstance" be a member variable of the object, and my problem is virtually solved.

With that said, it drastically reduces the flexibility of my GameObject class, and I'll have to create inheriting classes if I want to expand it at all. So far, there's no problem with that. The only potential problem I see with this is that I might have trouble when I need to implement a container to hold all my GameObjects.

[Average Software]

In C++ u have 2 types of memory allocation.

Three, actually.  Automatic (stack data), dynamic (new/delete) and static (globals, static variables in functions).

[rabb87]

Nice Game..



___________________________

swimming pool designs | king county divorce lawyer | discount wine

[Mikademus]

But Mik his ComponentList is RAII compliant the way he's using it (unless I missed something?).  Not to mention u can't use std::auto_ptr in containers. 

NEVER use auto_ptr in containers! I never said he should.

His implementation above is valid, but requires him to manually destroy each element in the destructor. He could have used shared_ptr of some flavour and not worry about writing a destructor at all. RAII and elegant, and if you get into the habit you won't have memory leaks (which he WILL have if he starts mucking about with naked pointers).

Good of you to take your time and patiently explain some basic things to him! 

[BorisTheBrave]

Shared ptrs ftw. But some people do have objections to them. But compared with the problems with pointers, they are trivial. FWIW, C++0x will support a replacement for autoptr that can be safely put in containers, with virtually zero overhead over a regular pointer.

But if you insist, you probably want Boost.Ptr Container, which does what you are doing (manual heap manipulation), only it's already written and tested.

Using stack/members is also an excellent way to avoid issues (really, this is at the heart of RAII), but doing so for a component based framework seems to negate the point, as you have zero run time flexibility.

[dspencer]

I guess this is slightly off topic, but does anyone have advice for debugging with smart pointers? They tend to make error messages even less clear (and I mean, c++ error messages are *so* clear to begin with)...

[Mikademus]

I guess this is slightly off topic, but does anyone have advice for debugging with smart pointers? They tend to make error messages even less clear (and I mean, c++ error messages are *so* clear to begin with)...

Well, regular C++ error messages are quite clear, but those regarding templates can be a nightmare to resolve I once saw this program that cleaned up STL error messages for you so they became readable and understandable, but I can't remember where i found it... It was quite clever and had support for most compilers.

[Average Software]

I guess this is slightly off topic, but does anyone have advice for debugging with smart pointers? They tend to make error messages even less clear (and I mean, c++ error messages are *so* clear to begin with)...

Well, regular C++ error messages are quite clear, but those regarding templates can be a nightmare to resolve I once saw this program that cleaned up STL error messages for you so they became readable and understandable, but I can't remember where i found it... It was quite clever and had support for most compilers.

I know that GCC 4.5 will make this a little easier, as by default it will omit all default arguments to templates from error messages.  This will remove all the stuff about allocators and what not.

[skyy]

Code:

std::for_each(List.begin(), List.end(), std::mem_fun(&Component::Run));

I like this for no obvious reason. Sexy.   

[Fallsburg]

Code:

std::for_each(List.begin(), List.end(), std::mem_fun(&Component::Run));

I like this for no obvious reason. Sexy.   

Code:

std::list<Component*> list;
BOOST_FOREACH(Component *i, list){
    Component->Run();
}

Yet sexier still even, in my humble opinion. Of course, it requires the boost library.