Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Allocating memory for a table of pointers

Author
Message
Serain
18
Years of Service
User Offline
Joined: 17th Jul 2006
Location:
Posted: 12th Jul 2009 13:02
Hey everyone,
I need a little help with memory allocation etc.

My class Hand has an attribut:
Card* cards[5];

So in my constructor I need to reserve memory for this table but I forgot how to do that.
I know for a single pointer it's:
ptr = new Card;

But I can't remember how to allocate a whole table. I tried Google but couldn't find specificaly on table allocation. Can anyone refresh my memory?
jezza
16
Years of Service
User Offline
Joined: 8th Mar 2008
Location: Bham, UK
Posted: 12th Jul 2009 13:31
Card *cards;//I always put * after space, because later one decalred simulataneously might not be pointers.
cards = new Card[5];

To access stuff
card[2]->burn();//burns the third of the 5 cards

then when you're done
delete [] cards;

Mireben
16
Years of Service
User Offline
Joined: 5th Aug 2008
Location:
Posted: 12th Jul 2009 14:09
To access, use the point operator because the array allocated in this way contains the objects themselves, not pointers: card[2].burn();

And this method works only if the class has a constructor which does not need parameters.
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 12th Jul 2009 19:14 Edited at: 12th Jul 2009 19:17
Here is a little 2D dynamic array template that I use a fair bit, I think i found it originally on www.cplusplus.com



The above array, although a set of pointers to pointers can be used with normal array notation... Also, at it's heart, C++ uses almost this exact same method(pointers to pointers) for its standard multi dimensional arrays. Although the compilers implementation would be much more secure lol, the above is just a simple time saver, as I like to allocate my arrays using variables at runtime to save memory(they are made the size they are needed rather than an arbitrary large value)

The reason that it is a list of pointers to pointers is that you cannot declare multi dimensional arrays in C++ dynamically, with ALL dimensions being dynamic, the first dimension must still be a constant in C++ unless pointers are used.....

EDIT : hmm, some of those headers arent needed, I pasted this snippet from a console app and stuk the GDK stuff in

If it ain't broke.... DONT FIX IT !!!
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 12th Jul 2009 19:34
I question why your Hand needs to be composed of pointers. You have a discrete number of elements and each element is fixed in size. All you'd need to do is declare

card hand[5];

No worries about deallocating memory space before the array goes out of scope.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
Mista Wilson
16
Years of Service
User Offline
Joined: 27th Aug 2008
Location: Brisbane, Australia
Posted: 12th Jul 2009 19:36
He might be planning a card game with different sized hands ? I think some variants of poker use 7 card hands dont they ? or am I thinking of snap or gin or somethin lol

If it ain't broke.... DONT FIX IT !!!
Lilith
16
Years of Service
User Offline
Joined: 12th Feb 2008
Location: Dallas, TX
Posted: 12th Jul 2009 19:41
But he specifically showed five in the original post. I don't see a problem with declaring specifically

card hand[7];

if the game called for it. Now, if the game were something like Gin Rummy where the hand could expand hand might do as a pointer. However, if the hand were expanding then reallocating and copying would be a potential necessity. Truth to tell,

std::vector<card> hand;

would be much better all around.

Lilith, Night Butterfly
I'm not a programmer but I play one in the office
David R
21
Years of Service
User Offline
Joined: 9th Sep 2003
Location: 3.14
Posted: 12th Jul 2009 20:20 Edited at: 12th Jul 2009 20:22
There are a number of reasons to avoid stack arrays or fixed sizes. For starters, stack array debugging is torturous - if you corrupt or overrun at any point, you put the integrity of the entire program at risk (nuking the stack can kill the current function or scope, for example).

Heap debugging, on the other hand is not only easier, but more straight forward to automatically detect problems (CRT's "no mans land" for example).

Oh, and not to mention the fact that stack space is limited in a much less deterministic way than the heap - at least with the heap, you know your upper limit is somehow related to the physical memory available. That's possibly not the case with the stack though.

09-f9-11-02-9d-74-e3-5b-d8-41-56-c5-63-56-88-c0

Login to post a reply

Server time is: 2024-10-01 05:50:09
Your offset time is: 2024-10-01 05:50:09