• Advertisement
Sign in to follow this  

pointers

This topic is 4274 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

is there anypoint in having dynamic allocation of variables eg *ptr and new keyword for only a few varibales if small size? is dynamic allocation really only useful to create data structures at runtime? eg array,container of pointers

Share this post


Link to post
Share on other sites
Advertisement
It's always depends :P (Easy answer)...

A pointer doesnt contains the data, its only containning a reference (memory address) to the data.

Like you state, pointers are mainly used for dynamic allocation of arrays. But sometimes, it might be interesting, in a specific case, to hold a "reference" to the data instead of the data itself. It doesnt matters if you're storing a int, an array or a specific data structure.

A bad exemple: In olds day, in the days of DOS gaming. We were use to access the video memory directly. How did we did it, simply be defining a pointer to the video memory like this: BYTE* ptrVideoMemory = (BYTE*)0xa0000000; (if i remember right).

So, to answer your question, the size isnt the question, the usage IS!

There are plenty of better exemples, but i'm too tired to figure out one for you, sorry.

Hope this helps,
Jonathan

Share this post


Link to post
Share on other sites
You can use it really for anything. But is there any point?

Sometimes, no. I mean if you're calling function B from function A and you need to pass a pointer to an integer, but the integer is only going to be used in function A, then no, there's no point.

Dynamic allocation is most useful by creating abstract data structures. But, you really have to look at it and see if it makes sense. I mean, if you're only using the variable for a function or two, then there's not really any point.

On the other hand, if you have an object that is expensive (memory-wise or computationally) to create and you'll be using it more than once, then yes, you should use dynamic memory.

But, after you code more things, you'll get a feeling for it. You'll find that for one particular thing using dynamic memory would be overkill and feels unwieldy, but for other things it will make perfect sense.

Share this post


Link to post
Share on other sites
Moved to For Beginners.

Share this post


Link to post
Share on other sites
OK so with c++ when using pointers for dynamic allocation at runtime, like a database type program. I am talking about a user adding records of an unkown amount at runtime, so pointers would be the most useful.

Would you creat an pointer array of objects say, or maybe a container of object pointers, as the best solution (anything but a linked list).

Share this post


Link to post
Share on other sites
There are also simply things you can't do without dynamic allocation.
For example class inheritance in cpp.


class A {
};

class B : public A {
};

A a1, *a2;
B b1, *b2;

//you can't do this
a1 = b1;

//but this you can
a2 = b2;


Share this post


Link to post
Share on other sites
Quote:
Original post by jagguy
OK so with c++ when using pointers for dynamic allocation at runtime, like a database type program. I am talking about a user adding records of an unkown amount at runtime, so pointers would be the most useful.

Would you creat an pointer array of objects say, or maybe a container of object pointers, as the best solution (anything but a linked list).


Humm, im not sure i understand right.

First, when you are using the new operator the size to be allocated MUST be know. If the size isn't know, the best approch is to use some kind of containers (linkedlist, array, hashmap, STL stuff...).

Second, since as state in 1st, the size must be know at the time of allocation, if you want to add more values to the array, you will need to reallocate memory. (Costly operation)

Check out the exemple i write for you in the "other" thread :P

Jonathan

Share this post


Link to post
Share on other sites
Quote:
Original post by LowRad
Quote:
Original post by jagguy
OK so with c++ when using pointers for dynamic allocation at runtime, like a database type program. I am talking about a user adding records of an unkown amount at runtime, so pointers would be the most useful.

Would you creat an pointer array of objects say, or maybe a container of object pointers, as the best solution (anything but a linked list).


Humm, im not sure i understand right.

First, when you are using the new operator the size to be allocated MUST be know. If the size isn't know, the best approch is to use some kind of containers (linkedlist, array, hashmap, STL stuff...).

Second, since as state in 1st, the size must be know at the time of allocation, if you want to add more values to the array, you will need to reallocate memory. (Costly operation)

Check out the exemple i write for you in the "other" thread :P

Jonathan


Let me try to explain what i mean. Say I have a number of objects I want to store at runtime, and I don't know how many objects i will need like in a database. I use an array of objects using dynamic allocation so each object is a pointer , and to access each record I simply use a loop.
Now, the problem is i don't know the size of the array to create , but I declare an array a really big size just in case.
1)How do i add more values to an array if I outgrow the initial size?
2)Are using containers a better option, but is a container full of dynamically created objects (pointers) the thing to do.

Share this post


Link to post
Share on other sites
Ok it's clear now...

Quote:

1)How do i add more values to an array if I outgrow the initial size?


Like i said, it is possible to "reallocate" space to outgrow the original array, but this is a very expensive operation (a new allocation then a copy). The solution is to use any kind of list. There's STL, Boost or your own list.

I need to verify this, i know in C you use malloc, realloc and free. Dont remember for Cpp.

Quote:

2)Are using containers a better option?, but if i remember it doesn't use pointers well and that would make it memory inefficient for a database scenario (correct me if i am wrong).


Humm, containers/list/stl/... is the solution to your problem. I don't see inefficient memory usage in this. Allocating 1000 object when you just need 800 is a waste of memory.

Quote:

I use an array of objects using dynamic allocation so each object is a pointer


Are you doing something like:
1) MyObject* myObjects = new MyObject[10000];
or
2) MyObject **ppMyObjectArray = new MyObject*[100];

1. is allocating an array of object, then storing the address of the first element into myObjects. BUT, each element ISNT a pointer to an MyObject.. each element IS a MyObject!

2. is allocating an array of pointers to MyObject objects.

Regards,
Jonathan

Share this post


Link to post
Share on other sites
let me say it this way, if you create a database (each record is stored in an object), then how do program this for an unknown size of objects.

Do you use -

An array of dynamically allocated objects and just create a very large size array so you can never really hit the limit.

or

A container with dynamically allocated objects, which may prove confusing .

or aother solution i don't know about.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Just on a sidenote, list wrappers (STL and whatever) also use dynamic allocation... it's not like they have found a magical way around this.


I think you should go with option 2 from what you say.


//here is an example of how to make your list bigger.
MyObject **newList = new MyObject*[newSize];
memcpy((void *)newList,(void *)list,size*sizeof(void *));
delete[] list;
size = newSize;
list = newList;



Of course there are more exotic types of lists, a vector based list for example will not grow in size all the time, it will only grow when it exceeds its capacity.


Share this post


Link to post
Share on other sites
Quote:
Original post by jagguy
let me say it this way, if you create a database (each record is stored in an object), then how do program this for an unknown size of objects.


If that would be the case, there will be a value indicating how many objects there are being returned.

//The function would then for example return an instance of a List.
List *getObjectsFromDB(CString query)

//So calling it would go like this:
List *l = getObjectsFromDB("SELECT * FROM person");

//To know how many objects it returned youd do something like this..
int size = l->size();

Share this post


Link to post
Share on other sites
Quote:
Original post by LowRad
Quote:

1)How do i add more values to an array if I outgrow the initial size?


Like i said, it is possible to "reallocate" space to outgrow the original array, but this is a very expensive operation (a new allocation then a copy). The solution is to use any kind of list. There's STL, Boost or your own list.
Be careful about saying things like that. "Expensive" has multiple meanings: in this case, it may be expensive in terms of time, but it's very likely less expensive in terms of space (memory). Each item in your list has to hold a pointer to the next item; on a 32-bit system, a pointer is 4 bytes, so that's 4 bytes more per entry. In the array approach, you don't need that extra 4 bytes per entry; at most you'll need a single 4-byte variable somewhere to track how many entries you've currently got.

So, if you're looking at a situation where you don't have many objects but the number changes quite frequently, then a list may well be the right approach. But if you're dealing with thousands of objects, and the number doesn't change too frequently (like once every 50 frames) then the array will probably be better.

Of course, one can always go for a hybrid approach; have a linked-list of arrays. This is an approach known as "paging," where each array in the list is called a "page." You start with just one page - say it's big enough for 50 entries - and whenever you need a new object, pick an empty slot in the array and use it (so you'll usually have some unused slots on the page - a little wasteful, but not a big deal). When the page is full, you allocate another page and stick it on the end of the list; and when a page is empty, you can deallocate it (or keep it around if you think it's going to fill up again soon). In this way, you only have 4 extra bytes per page to maintain your list, but you only allocate new memory every 50 or so objects. Best of both worlds.

Look into the Loki library's "Small Object Allocator" for an example of a paging system in action. (Incidentally, this is also how Windows manages its memory).

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement