Quote:Original post by CodeMunkie
std::vector< std::vector< int> > theRoom;
theRoom[x][y] = blah;

Nesting vectors loses the contiguous-memory guarantee (between "rows"), compounds the potential for wasting space (a vector that doubles in size with each resizing might average 6N + 12 bytes of used space for N integers; a vector of vectors would then cost 9N^2 + 18N + 12 bytes to store N^2 integers) and loses the guarantee of rectangularity (each "row" can be resized independantly, so you have to add logic to keep the lengths in sync, and you are throwing away flexibility after explicitly asking for it). Just use boost::multi_array.

Ok, so the boost library really seems the way to go. I must admit I haven't got any experience with it, but everybody keeps saying it's really good so I'm willing to give it a try. I'm going to use the multi_array for the multidimensional data. Now another question: in my app, there is a "level" class that consists out of several rooms with lot's of data. The rooms contain quite a bit of data, so I really can't create them on the stack or I would get an overflow very soon. So I must create these objects on the heap. My idea was to use a vector of pointers to the rooms. Since I'm going to use the boost library anyway, I will also use smart pointers for each of these rooms. Is this a good approach?

Now that I think of it, this would totally free me from having to do any manual new and delete's. Being mostly a C guy, this admittedly feels a little weird. Is there any situation where you still have to use new and delete explicitely or do I always have to use smart pointers?

Jeroen

Quote:Original post by godmodder
Ok, so the boost library really seems the way to go. I must admit I haven't got any experience with it, but everybody keeps saying it's really good so I'm willing to give it a try. I'm going to use the multi_array for the multidimensional data. Now another question: in my app, there is a "level" class that consists out of several rooms with lot's of data. The rooms contain quite a bit of data, so I really can't create them on the stack or I would get an overflow very soon. So I must create these objects on the heap. My idea was to use a vector of pointers to the rooms. Since I'm going to use the boost library anyway, I will also use smart pointers for each of these rooms. Is this a good approach?

The vector already puts its contents onto the heap. (It has to make a dynamic allocation in order for resizing to work.) Just make a vector of Rooms, for normal cases.

The two main exceptions are: (a) Rooms are polymorphic somehow, and (b) Rooms can be shared between Levels. In both of these cases, you need some indirection (i.e. smart pointers) because in (a), the derived classes can't "fit" into a vector of base class instances, and in (b), if you gave each level a copy, and you changed one, its copy would not be updated, so you'd have a nightmare of trying to keep things in sync, while also wasting huge amounts of memory.

Quote:Now that I think of it, this would totally free me from having to do any manual new and delete's. Being mostly a C guy, this admittedly feels a little weird. Is there any situation where you still have to use new and delete explicitely or do I always have to use smart pointers?

You never really have to do anything in particular. ;) But modern, proper C++ usually involves writing 'new' very rarely, and 'delete' even more rarely. (The reason there is an imbalance is because you sometimes need to do the dynamic instantiation yourself for an object whose "ownership" will be "transferred" to a smart pointer; it does the delete, but it can't do the new, because it doesn't know what parameters to pass to the constructor.)

As for feeling weird... most modern programming practices will feel weird to people who are most accustomed to C. But, you know, Occam's razor suggests that it's not "everyone else" who's weird, it's you. ;) When you stop seeing explicit memory management as a tool (exactly what kind of flexibility are you gaining, in practice, anyway?), and start seeing it as the burden that it is, you will be enlightened.