arrays objects

Started by
9 comments, last by GameDev.net 19 years, 2 months ago
I want to know how can you have an array of objects declared if you dont know how many items will be in the array? eg MyClass Myobject[?]; or MyClass *Myobject[?] In VB you could simply have a Redim command where you preserve the existing array and just add another index. Do you need to go through contatiners? thanks
Advertisement
I assume you're using C/C++. You'll have to manually reallocate the array if you want to add items to it and there isn't enough space left, or use some other type of data structure like linked lists that allow for item insertion without this reallocation.

You can use a container class if you don't want to handle this manually.

Quote:Original post by mutex
I assume you're using C/C++. You'll have to manually reallocate the array if you want to add items to it and there isn't enough space left, or use some other type of data structure like linked lists that allow for item insertion without this reallocation.

You can use a container class if you don't want to handle this manually.

I think we can assume that he is specifically using C++, if you are correct, since C does not have objects. [grin] I second the notion of using container classes; specifically, to replace an array, one would usually use a vector.
MyClass * items;

int x = 100;
items = new MyClass[x];

delete [] items;


100 instances of MyClass will be created and then deleted. There's absolutely no reason to use containers for this. You need to know how pointers work anyway.

yes i am using vc++6

i dont know the size of the array until run-time, soI didnt want to simply make a fized array size.

if containers are the standard i will use them, isnt there an issue with vc++6 and containers?

anything but a linked list......yuk


thanks
If the size won't change then you can simply allocate the array like anonymous suggested. Otherwise you should go with containers from the STL:

#include <vector>std::vector<MyClass*> myvector;  // array of MyClass pointers, initially emptymyvector.push_back(new MyClass); // adds new MyClass object at tailMyClass* p = myvector[0];
The push_back call will resize the underlying array if necessary. True, you can do it yourself with anonymous's code + code to copy original elements to the new array, but using STL containers will likely save you bug-hunting time. I've used STL fine with VC++ 6, and yes, STL is standard.

Quote:Original post by mutex
If the size won't change then you can simply allocate the array like anonymous suggested. Otherwise you should go with containers from the STL:

#include <vector>std::vector<MyClass*> myvector;  // array of MyClass pointers, initially emptymyvector.push_back(new MyClass); // adds new MyClass object at tailMyClass* p = myvector[0];
The push_back call will resize the underlying array if necessary. True, you can do it yourself with anonymous's code + code to copy original elements to the new array, but using STL containers will likely save you bug-hunting time.


[headshake] you should almost never store objects by pointer in STL containers unless you have to and i will describe the exception to this rule shortly, STL containers are designed & optimized to store by value not reference.

The exception to this rule is:


  • You need to store polymorphic types that behave polymorphically

  • The type in question has no meaning of copy and/or assignement operations there-for the type's copy constructor and/or assignement operators are private (ALA IOstreams), STL containers require the types to be contained to be at the very least a model of an Assignable type.

  • The user-defined type has non-trivial copy and/or assignement operations and you should have proven that this is costing you performance-wise via profiling never make assumptions.

  • Your user-defined type models self-relationships meaning it store instances of it's self, storing by-value in STL containers will most likely lead to non-portable behaviour

  • Your creating some new non-trivial structure for example you have one container that stores by value and one or more other containers by reference that refer to the instances contained in the first one.



There are probably a couple of others i've missed by these are definitely the main ones. You should also note that if you do store by raw pointer the responsibility of memory management becomes yours so you may end-up leaking resources, you should consider storing smart pointers instead (and no you can't store std::auto_ptr in STL containers).

Another thing i forgot to mention that STL containers are parameterized by allocator type, there-for you can use/write custom allocators if the default is not appropriate, like one that provides a pooling scheme.

Quote:Original post by mutex
I've used STL fine with VC++ 6, and yes, STL is standard.


Alot of VC++ 6.0's implementation of STL is borked & probably non-standard compliant, heck the whole compiler is non-standard compliant considering this is pre-standard technology meaning before C++ was standardized in 1998 so this is more than 8 years old technology!. You can improve your out-come by installing service packs 5 & 6 and using STLport instead but you still serverly limiting yourself by continuously using this defunct product.

[Edited by - snk_kid on February 9, 2005 4:49:05 AM]
Woah, you've just exposed how little I know about STL. I usually handle memory allocation manually, hence my usage of pointers. Didn't know STL was designed for value-type storage.

Quote:Original post by mutex
Woah, you've just exposed how little I know about STL. I usually handle memory allocation manually, hence my usage of pointers. Didn't know STL was designed for value-type storage.


I'm sorry if it seemed like i was lashing out at you but i felt that i should say something because jagguy + others might be completely new to STL therefor they should now how to effectively use them, consider the above to be a mini Effective STL tutorial [smile].
Nah it's fine :) Best to recognize the limits of one's knowledge and accept it.

This topic is closed to new replies.

Advertisement