Thread: Vectors + Classes = Confusing

Yeah I forgot the increment....oops. The copy that calls release is the copy in the vector.

It is perfectly valid in COM to do this:

IUnknown *ptr1;
IUnknown *ptr2;

ptr2=ptr1;

So the interface is copyable. It doesn't actually create another interface but it creates a pointer to an already valid interface. But you are right the problem is not the vector cleanup it is the cleanup performed by the person using the vector which is what I was pointing out. Using user types with vectors normally requires some type of cleanup on the class's part - more than just the standard vector memory cleanup.

I'm not sure that clear has to be called. My books do not specifically say anything about having to call clear for correct cleanup to occur. However if you were using the vector of classes approach and the cleanup was in the destructor code for that class, then calling clear() for that vector would in turn call the destructor for that class which would in turn clean up correctly. Without calling clear there you would have to use the delete [] mechanism.

But since a vector can be of any type I think its a very important topic to discuss. Don't assume that everything is cleaned up automatically. The memory required for the vector is, but the class must still cleanup its own memory if it has allocated any as well as any resources it may have used.

So far my code works quite well for this very thing. The only error I have is in the sound code which for some reason is doing what you are telling me. It is calling release() twice for the same object when it shouldn't be. But none of the other vectors do this - each IDirect3DTexture9 interface represents one surface. I admit that my method could be dangerous if you were to misuse the class, but as long as you follow the rules it works very well and it is very fast.

So how do you avoid the double release? From what I see in my code each IDirect3DTexture9 interface will be released only once. The vectors and the data they contain is private to the class so its impossible to willy nilly re-copy the vectors or the data. The compiler will tell you that its impossible to access the data because its private. Perhaps if I created a static vector - but then all instances of the container must contain the same texture which is not what I want. I want multiple instances of the class with multiple uses for it.

Animation sequences
.
.
Textures
.
.-> User list

So an animation is this:

Sequence
..Frames data
..Vector data
..Timer data
|
|
|
User connects to this class and access frames through the sequence class
When the sequence is done...it destroys itself.

The sequence ALWAYS exists inside of the game even if zero instances of it are playing. It is a resource that is out there as long as the game is running. When you need an explosion you add one and play it. At cleanup the vector of IDirect3DTexture9 interfaces are released. In this way I have several animation resources sitting out in memory just waiting to be used by the engine. For a class to use it you just simply add a user to the list and it tracks the current frame of animation that class is on. It then returns the correct texture to the class so the class can render it. All the container is, is simply a container of textures that can be used by any number of classes. The return function for the vectors would be something like this:

IDirect3DTexture9 *GetFrame(unsigned int _classID)
{
return (Textures[FramePositions[_classID]]);
}

The FramePositions tracks the current frame for that user. For instance if it is FramePosition[0] that is user number 0. So when that class says gimme my next frame and it passes 0 to the class...the class will return the current frame for user 0. I realize that this could be heavily misused - like say if the user class released the IDirect3DTexture9 interface...it would be really really bad and the whole game would come crashing down. But as long as everyone plays by the rules and realizes who is responsible for releasing and who isn't...it works like a charm.

And its going to get really confusing when I have a vector of AnimationSequences and a class to handle those as well. So you can add animation sequences to the list, which have a list of animation frames, animations users, and animation frame times.

So the entire system is encapsulated by the CAnimSeqHandler class which has a vector of CAnimSeq objects which also has a vector of CAnimFrames objects, a vector of unsigned int FramePositions, and a vector of float FrameTimes. This allows me to create literally hundreds of animation sequences - yet not take nearly as much memory. Each animation frame only exists ONCE in the entire game. It is only loaded once, allocated once, and destroyed once. It took a long time to figure out how to make all this work.

And now that we have hijacked this thread.....I'd like to discuss this with you in another post or through PMs. It's extremely important to my game design and to efficient memory management. Holding 10000 instances of the same image in each class is crazy and that is what I'm trying to avoid. If you have 10 frames of animation....load only 10 in memory and then 'link' users to those frames.

Originally Posted by master5001

Almost. A struct can be initialized via the old C style way (i.e. MyStruct foo = {member1, member2, member3}) whereas a class can't.

Really? Hmmm wonder why this works:

Code:

#include <iostream>
using namespace std;

class Foo {
  public:
    int x;
    int y;
};

struct Bar {
  int x;
  int y;
};

ostream& operator<< (ostream& o, const Foo& f)
{
  return o<<f.x<<' '<<f.y;
}

ostream& operator<< (ostream& o, const Bar& b)
{
  return o<<b.x<<' '<<b.y;
}

int main()
{
  Foo fee = {1,2};
  Bar bee = {3,4};

  cout<<fee<<endl;
  cout<<bee<<endl;
}

But this won't

Code:

#include <iostream>
using namespace std;

class Foo {
  public:
    int x;
    int y;
  private:
    int z;

  friend ostream& operator<< (ostream&, const Foo& );
};

struct Bar {
  int x;
  int y;
  private:
    int z;

  friend ostream& operator<< (ostream&, const Bar& );
};

ostream& operator<< (ostream& o, const Foo& f)
{
  return o<<f.x<<' '<<f.y;
}

ostream& operator<< (ostream& o, const Bar& b)
{
  return o<<b.x<<' '<<b.y;
}

int main()
{
  Foo fee = {1,2,3};
  Bar bee = {4,5,6};

  cout<<fee<<endl;
  cout<<bee<<endl;
}

struct.cpp: In function `int main()':
struct.cpp:35: `fee' must be initialized by constructor, not by `{...}'
struct.cpp:36: `bee' must be initialized by constructor, not by `{...}'

Edit:

ANSI/ISO Standard 9.4
A structure is a class defined with the class-key struct; its members and base classes (clause 10) are public by default

The problem with using the above smart pointer with containers (or just in general) is that it is not copyable, which is why the copy constructor and assignment operator are disabled.

So how do you avoid the double release?

Copy constructors and reference counting anyone?

Code:

class AutoReleaseIUnknown // NOT COMPLETE
{
public:
    AutoReleaseIUnknown(IUnknown* ptr) : ptr_(ptr), refCount(new int(1)) { }
    AutoReleaseIUnknown(const AutoReleaseIUnknown& orig) :ptr_(orig.ptr_), refCount(orig.refCount) {++(*refCount);}
    ~AutoReleaseIUnknown() { if(--(*refCount) == 0) {ptr_->Release();delete refCount;} }
    IUnknown* get() const { return ptr_; }
    IUnknown* operator->() const { return ptr_; }
private:
    void operator=(const AutoReleaseIUnknown&);
    IUnknown* ptr_;
    int* refCount;
};

I wasn't sure if vector insertion requires the = operator to be defined, so I left it private to prevent reassignment of a used smart-pointer (incidentally, with clever use of reference counting you can probably make reassignment work too).

Oh, thought you were having double-release problems (judging from the first line of your post ).

[offtopic]
Just wondering though: If you had a pointer to class X, typecasted it to void*, then deleted the void*, would the object be deleted properly?
[/offtopic]

>>Dunno. Sounds kinda ignorant to do that.
I was thinking of what you'd do if you wanted to create a generic reference counting class. For example, in the constructor you could use a ... and push several pointers onto a vector<void*>; create an enum to access the appropriate objects and overload the [] operator... Then when the reference count reaches 0, simply call delete on each element of the vector. Something along those lines. Of course, it would probably be better to just create a base RefCounter class to inherit from, or whatever.

*trails off into incoherent mumbles*

Originally Posted by Bubba

I'm not sure that clear has to be called. My books do not specifically say anything about having to call clear for correct cleanup to occur. However if you were using the vector of classes approach and the cleanup was in the destructor code for that class, then calling clear() for that vector would in turn call the destructor for that class which would in turn clean up correctly. Without calling clear there you would have to use the delete [] mechanism.

Calling clear() on a member vector last in a destructor has absolutly no effect.

I guess you could use smart pointers with reference counting for the textures, but it's a matter of taste.

Originally Posted by Epo

I may toss the Vector::clear() method into the destructor, just for peace of mind.

You do that...

this might seem a little off the wall.. but I was just wondering.. what type of container does the vector class use to simulate a resizable array.. I bet it's a linked list.


beer == good;