C / C++ / MFC

Re: copying one array into another -simple question

4-Aug-02 14:53

You could also use CStringArray. It cleans up after itself.

/ravi

Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com

Daniel Lohmann5-Aug-02 3:56

Daniel Lohmann

5-Aug-02 3:56

Christian already suggested STL vectors Smile | :)

One thing left: What's the difference between delete[] and delete.

C++ developer, even experienced ones, often tell that in C++ pointers and arrays are the same. However, this is wrong! C/C++ does syntactically not distinguish between pointers and arrays. Semantically pointers and arrays are quite different things! And this is the reason for two versions of operator delete:

CString a[] = new CString[ 10 ];
CString b[] = new CString[ 10 ];

delete a;    // destroys only a[0] and then frees memory block
delete[] b;  // destroys a[0] - a[9] and then frees memory block

Because arrays and pointers share the same syntax, both a and b in the above code could be interpreted as pointer or as array. However, as I wrote above, they are not sematically the same thing:

- The first delete statement (delete a) interprets <coda>a as a pointer. It therfore destroys the object (calls the destructor) to which the pointer refers - this is a[0]. Then the buffer itself is freed. The destructors of a[1] to a[9] are not called. Because CString objects manage their own string buffer and free in the destructor, these buffers are never freed for a[1] to a[9] and cause memory leaks.

- The second delete statement (delete[] b) interprets b as an array. It first calls the destructor for every single array element and then frees the buffer.

Technically the one and only difference is that if you use operatore delete[] the destructor of each array element is called, while operator delete calls only the destructor of the first element. Therfore for object types that do not have an user defined destructor, both are semantically equivalent:

TCHAR szBuffer = new [MAX_PATH];
...
delete szBuffer; // No problem here, TCHAR has no destructor to call

--

Daniel Lohmann

http://www.losoft.de
(Hey, this page is worth looking! You can find some free and handy NT tools there Big Grin | :-D

)

OO design question

David Wulff4-Aug-02 12:55

4-Aug-02 12:55

This is purely from a design viewpoint at the moment to help me understand OOP a little better - I don't want any code, just theory please.

Let's say we have four classes: Parent, Son, Daughter and Grandchild. Now if I was to model a typical local family it would look like this:

    Parent
    ^    ^
   /      \
Son       Daughter
  ^        ^
   \      /
 [Grandchild<sup>n</sup>]

There can be multiple direct offspring of Parent based on this model, and each sibling pair can have more than one grandchild. Sometimes a sibling may choose to directly adopt a Grandchild without courting one of their brothers or sisters, but the siblings will never form a threesome (us country folk do have some standards you know!)

Now let's say Parent has some common attributes and methods, e.g. Age, GetAge and SetAge. How would this look from the Grandchild's perspective? I.e. how would a Grandchild determine it's age?

I'm not sure how to approach this one. Confused | :confused:

This isn't technically related to C++, but I figured it would be the best forum given the choices.

David Wulff
http://www.davidwulff.co.uk

One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.

Ravi Bhavnani4-Aug-02 15:00

4-Aug-02 15:00

Is your diagram an object inheritance chart or (as I suspect) is it meant to show the "is born to" relation? They are 2 very different things.

If it's an inheritance chart and the age methods are publicly defined in Parent, objects that inherit from it will also inherit the methods. So when you do:

grandChild.getAge()

the method getAge() in Parent gets called.

If the method is defined virtual, descendant classes may override it. If it's defined pure virtual, they have to override (i.e. implement) it. In this case, Parent would be an abstract base class.

/ravi

Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com

David Wulff4-Aug-02 15:32

4-Aug-02 15:32

Thanks Ravi.

Ravi Bhavnani wrote:
Is your diagram an object inheritance chart or (as I suspect) is it meant to show the "is born to" relation? They are 2 very different things.

It was *meant* to be an inheritance chart. Then again, I didn't pay much attention to that in class...

Ravi Bhavnani wrote:
If it's an inheritance chart and the age methods are publicly defined in Parent, objects that inherit from it will also inherit the methods. ... [etc]

That much I understand (wow!) but what is confusing me is say the Son and Daughter objects each provide overridden Get/SetAge methods, and the Parent object's method is called from within each to perform some common task. Now if I call Grandchild's GetAge member what gets used? Would it even work? If so, would the Parent's member get called twice?

My example of ages is getting a little confusing, so let me explain the real problem I am looking at:

In a game we have many CGameObject's:

       GameObject
      ^         ^
     /           \
Animatable    Intelligent     ... (there are more)
GameObject     GameObject
     ^            ^
      \          /
    PlayerGameObject

GameObject provides a virtual method called Frame which is called each frame in the game to allow the object to perform any actions if required to. The GameObject.Frame method performs some basic "all objects require this" actions. The AnimatableGameObject.Frame method updates the animation status, etc. The IntelligentGameObject.Frame method evaluates the AI state of the object and calls its own methods as appropriate. The PlayerGameObject.Frame performs some calculations using user input and various other factors. Now I want PlayerGameObject.Frame to perform all of the tasks of all of the overriden (inclusing its own) and the original methods. Exactly how, if at all, would this work? Could I do something like:

PlayerGameObject::Frame()
{
    // do stuff here
    
    AnimatableGameObject::Frame(); // call parent method
    InteligentGameObject::Frame(); // call other parent method
}

How would GameObject::Frame be called if both the AnimatableGameObject and InteligentGameObject overidden methods call it? Argh - my head!

David Wulff
http://www.davidwulff.co.uk

One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.

Shog⁹4-Aug-02 19:45

Shog⁹

4-Aug-02 19:45

David Wulff wrote:
Could I do something like:

Yes.

David Wulff wrote:
How would GameObject::Frame be called if both the AnimatableGameObject and InteligentGameObject overidden methods call it?

It would be called twice. That probably isn't what you want. So don't call it from both.

---

Shog⁹
If I could sleep forever, I could forget about everything...

David Wulff5-Aug-02 1:33

5-Aug-02 1:33

Shog9 wrote:
It would be called twice. That probably isn't what you want. So don't call it from both.

Damn, thought so. The problem is that it must be called from both as their are other objects which in turn inherit from either AnimatableGameObject or InteligentGameObject. A thought has just struck me...

** don't all say "uh oh" at once now Poke tongue | ;-P

**

If I add a parameter to each virtual function of the direct sibling objects (those like Son, Daughter, etc) like thus...

Frame([normal parameters...], bCallRootClass)

...then PlayerGameObject.Frame would look like this:

PlayerGameObject::Frame([normal parameters...], bCallRootClass)
{
    // bCallRootClass is set to a default value of false
    // do stuff here
    
    AnimatableGameObject::Frame([normal parameters...], bCallRootClass); // call parent method
    InteligentGameObject::Frame([normal parameters...], bCallRootClass); // call other parent method
    
    if (!bCallRootClass)
        GameObject::Frame([normal parameters...], bCallRootClass); // call root parent method
}

And then do the same sort of thing in the AnimatableGameObject.Frame and InteligentGameObject.Frame methods.

That *should* work, no? The hierarchy would never go more than three deep, and it is only on the first sibling "stage" that mutliple inheritance would take place.

David Wulff
http://www.davidwulff.co.uk

One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.

Shog⁹5-Aug-02 5:14

Shog⁹

5-Aug-02 5:14

David Wulff wrote:
A thought has just struck me...

Ok, now you're *really* getting overly complex.

I wish i could remember, i just read a nice little technique for handling situations such as this... might even have been on CP. Can't recall Frown | :(

But anyway, the gist of it is this:

In the base class, have two methods. One, DoFrameStuff() is not virtual, and implements the code you want shared between all derived classes. The other, Frame() is virtual, and just calls DoFrameStuff() (if you won't be instantiating (sp?) the base class, then just make it pure virtual).
In each derived class, implement a new version of DoFrameStuff() that does only what the derived class adds, and doesn't call the base class method. Also implement Frame() as calling only DoFrameStuff() and BaseClass::DoFrameStuff().
In the grandchild class, implement Frame() as calling Child1::DoFrameStuff() Child2::DoFrameStuff() and BaseClass::DoFrameStuff() in order.

In this way, you have absolute control over the order in which the methods are called at each point. I admit, your system may be a bit more complex than this (my description assumes fairly simple interdependancies between each of the methods), but working from this basic structure it shouldn't be too difficult.

---

Shog⁹
If I could sleep forever, I could forget about everything...

David Wulff5-Aug-02 6:46

5-Aug-02 6:46

Thanks, your idea looks good.

David Wulff
http://www.davidwulff.co.uk

One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.

Stan Shannon5-Aug-02 8:47

Stan Shannon

5-Aug-02 8:47

David James Wulff wrote:
Thanks, your idea looks good

<cough>godhelpus Smile | :)

I'm not a real reverend, I just play one on CP.

Stan Shannon5-Aug-02 2:04

Stan Shannon

5-Aug-02 2:04

If I might be so bold, David, I think your entire paradigm here is flawed. From what little bit of information you provide, it would seem to me that the concept of a "GameObject" itself is the issue. What the heck sort of *thing* is a gameobject? IMHO, the object you need here is a Frame object. A "frame object" is a concrete concept which you could build a logical class structure around, a "game object" is not. That is the core of your problem.

A frame object would encapsulate frame related data which could be acted upon by such methods as:

UpdateAnimation();
UpdateAI();

etc...

The data contained within the frame object could relate to individual items of game logic which you might refer to as a "Game Object". But, I think if you reversed your thinking and made the game objects belong to the frame, rather than the frame object belonging to the game objects, you would benefit from a cleaner design.

I'm not a real reverend, I just play one on CP.

David Wulff5-Aug-02 2:29

5-Aug-02 2:29

Reverend Stan wrote:
If I might be so bold, David

How dare you be so bold! I shall have you hung drawn and quartered for this! Mad | :mad:

As I said, I am learning here - any input is welcome!

Reverend Stan wrote:
A "frame object" is a concrete concept which you could build a logical class structure around, a "game object" is not.

I understand what you are saying, I think. I just don't see how the Frame object would work withing the system. Confused | :confused:

A game object is an object in the game, be it a player or similar unit, a camera, a light, a helper object, etc. Each object when created will register it's interest in certain events (the example I have been using to-date is frame events). The events themselves are triggered and sent by the "Game" object (read: "CGame" not "CGameObject") which in turn takes care of the rendering, etc, etc.

What I am trying to do is to seperate all of the higher level game objects from the game itself, so as far as the game is conerned it only has a bunch of game objects to create, update and destroy. It never knows about animation, intelligence, states, etc, and it never knows if it is a player object or a camera - it just knows where it is and what it want's to know. It is by design that the "Game" object does not know anything about animation, inteligence, states, etc, either.

All this is supposed to make it easier to add new game objects using external scripts - well that was the idea anyway.

Have I totally missed something here?

David Wulff
http://www.davidwulff.co.uk

One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.

Stan Shannon5-Aug-02 3:43

Stan Shannon

5-Aug-02 3:43

First, remember that I have never designed a game, so I probably have no clue as to what I am saying. I am just thinking of the problem, to the limited extent I understand it, in terms of OO.

David Wulff wrote:
A game object is an object in the game, be it a player or similar unit, a camera, a light, a helper object, etc. Each object when created will register it's interest in certain events (the example I have been using to-date is frame events). The events themselves are triggered and sent by the "Game" object (read: "CGame" not "CGameObject") which in turn takes care of the rendering, etc, etc.

What I am trying to do is to seperate all of the higher level game objects from the game itself, so as far as the game is conerned it only has a bunch of game objects to create, update and destroy. It never knows about animation, intelligence, states, etc, and it never knows if it is a player object or a camera - it just knows where it is and what it want's to know. It is by design that the "Game" object does not know anything about animation, inteligence, states, etc, either.

That all sounds like a good design except that you are trying to get these objects to share state information. The concept of a Frame needs to be abstracted out of the concept of a game object. If the game objects need to update on a frame by frame basis, than collectively, they represent the state of the frame at any given moment, not vice versa. On a frame event all game objects need to be given the chance to update, but they are all trying to update the same frame, because, obviously, there is only one frame per state (a singleton perhaps?).

Think of a frame not as a state that the game objects share, but as an entity that they belong to. They are *its* state. The frame is itself a game object. The frame is a state management game object. All the other game objects belong to it. It can serve as a kind of factory class which generates the game objects it contains in a polymorphic fashion, thus acheiving the extensibility you desire.

To me, the game object itself should only ever be aware of one thing - the frame, and the frame manages the game's state from moment to moment. You could then swap derived frame types in and out of a game to achieve a very extensible design.

I'm not a real reverend, I just play one on CP.

Ravi Bhavnani5-Aug-02 3:37

5-Aug-02 3:37

David Wulff wrote:
Could I do something like

Yes, that will work (but will also cause Parent.Frame() to be invoked twice). You can easily get around this problem by passing the current frame id in the call. Each Frame() method can ignore the call (i.e. do nothing) if it's already been invoked for this frame.

/ravi

Let's put "civil" back into "civilization"
http://www.ravib.com
ravib@ravib.com

Tomasz Sowinski4-Aug-02 23:51

Tomasz Sowinski

4-Aug-02 23:51

The problem you're facing is a classic. Some people call it 'dreaded diamond hierarchy'. I'd recommend reading 'Effective C++' by Scott Meyers; item 43 could shed some light.

Tomasz Sowinski -- http://www.shooltz.com

What is "scratch" and why can everything be made from it?

David Wulff5-Aug-02 1:22

5-Aug-02 1:22

Hi Tomasz, thanks for the recomendation - I'll add it to my huge list of things to buy when I have the cash. Smile | :)

David Wulff
http://www.davidwulff.co.uk

One 18yrs male, red and white, good condition; daily servicing required. £500 collect ono.

using CBitmapButton

Mavrock4-Aug-02 11:58

Mavrock

4-Aug-02 11:58

I am a very new programmer and Visual C++ 6.0 is the first programming I have been learning. I am not very familiar with the terminology. I am trying to put a bitmap on a button using the CBitmapButton function. However I am getting the error "error C2065: 'pParentWnd' : undeclared identifier".

I don't know what 'pParentWnd' means or how to declare it.

Thank you.
Stone

Re: using CBitmapButton

Ravi Bhavnani4-Aug-02 15:00