I think that I have hinted around at this before, but I realize what my true question is.
Since I have been adding things to my ROM base, I've decided to instantiate objects using
new() instead of alloc_perm() for some obvious reasons. However, since ROM recycles it's
data, what repercussions might one expect from doing this?

I imagine that the data will be parallel to the ROM data. If i were to use alloc_perm() what
would the restrictions be on things like std::string or other STL objects? Currently I've
added a pretty cool Quest model, and so far haven't had any issues with the implementation,
I just want to be smart with my memory.

You cannot use C++ objects if you do not initialize them with their constructor.


Being smart with memory is a fairly advanced topic, and all too often, people who try to be smart end up outsmarting themselves, and making a complex system that makes no difference, but is hard to understand and maintain. Unless you have a rather compelling reason to care (hint: you probably don't, especially on today's computers) you should probably not bother with the whole recycling business.

Fair enough. :smirk:

Just use new/delete. I've remove probably 99% of the recycling junk from AckFUSS and replaced it with new/delete as needed without issue. There are still one or two fringe cases I haven't felt like tackling yet that involve many levels of void cast pointers :)

That's good to know, I've thought about doing that ever since I cleaned up my project for g++.
Although, for my needs it's probably something I don't have to do, I might get around to
it later on. If so, I'll be sure and ask you more details about those specific issues you had in
doing so.

Here's something I would like to know. Say I initalize a user defined class like Quest, within
Quest, there is a C style linked list with a head pointer called Objective, when I "delete" a
Quest object, will I have to explicitly delete each Objective in the list via the Quest destructor?

I'm pretty sure delete also runs the destructor on any component parts as well.

Calling delete will indeed call the destructor. But what the destructor does with complex data structures is up to the implementation of your destructor. If an object contains a linked list of pointers and you want those pointers to be freed when the object is, you need to take care of that yourself.

Excellent, that's what I figured.

delete won't (by default) call the d'tor for -any- pointers right?

I take your question to be, if struct A contains a pointer B, and I call delete on my instance of struct A, what will happen to A->B?

If you don't define a dtor for struct A, The object pointed to by A->B will go floating off into the ether. You could, of course, explicitly delete the object pointed to in A's dtor, but otherwise it isn't touched. Member objects, on the other hand, will have their dtor's invoked.