Printable View
Hello,
I have writen a lot of functions working on containers of objects. Now I've decided it's better not to copy the objects in the containers, but to use conteiners of pointers.
Is there some solution in which I do not have to wewrite all my functions?
Thanks,
Angy
I think you mean vector<C*> instead of vector<*C>.Quote:
vector<*C> and vector<C>
On what basis did you make your decision?Quote:
Now I've decided it's better not to copy the objects in the containers, but to use conteiners of pointers.
I do not think so. Once you use a vector of pointers you have to think about memory management. Things like boost::ptr_vector may be able to help, but there will still be quite some re-writing to do, methinks.Quote:
Is there some solution in which I do not have to wewrite all my functions?
vector<some_object *> my_pointers_to_several_objects ;
Perhaps you could try a vector of reference but I'm not even sure it exists (never done it or seen it). It's worth a try. I don't think this would work because of the container's processing of the elements but try and see if it works =)
Of course I meant vector<C*> it was a typing mistake, sorry.
Vectors of references do not exist. The reason is that a reference is just an alternative name for an object, so that makes no sense.
Any other Ideas?
None of the objects in the containers need to be copied if you pass the vector to the functions as a reference.Quote:
I have writen a lot of functions working on containers of objects. Now I've decided it's better not to copy the objects in the containers, but to use conteiners of pointers.
Are you talking about not wanting to change your code from object.variable to object->variable?
Todd
But objects are copied on insertion into containersQuote:
Originally Posted by anon
you can put it that wayQuote:
Originally Posted by Todd Burch
I do not want to go to every function and change
my_vector_of_obgects[i]
to
*(my_vector_of_pointers_to_obgects[i])
whenever a single object from a container is passed to another function
I suspect if you do as ANON suggested, and change your functions to pass as a reference, that would satisfy your objective.
I did what you don't want to do a couple weeks ago - it was a pain. The DOT notation is easier to read. I may try ANON's suggestion as well.
Todd
From what I see boost::ptr_vector is designed to allow that kind of syntax (i.e., you do not need to change the code to use dereference pointers).Quote:
Originally Posted by Angelina
If Angelina is indeed working with large objects for which copying is expensive, the overhead of having to copy on insertion may be too much. Of course, this assumes that some profiling was done, which is why I asked for the basis for the decision to change to use containers of pointers.Quote:
I suspect if you do as ANON suggested, and change your functions to pass as a reference, that would satisfy your objective.
I think there is a missunderstanding here:Quote:
Originally Posted by Todd Burch
The problem is not that I am not passing the container as reference to functions, but that I do not want to copy on insertion and thus use containers of pointers now.
E.g.
vector<int> vi;
int i;
vi.push_back(i);
// here i is copied into vi
// &vi[0] is not the address of i
I'm not very familiar with the boost library and not keen on mixing that in now.Quote:
Originally Posted by laserlight
I was wondering if there is any more "standard" solution?
Yes, my objects are too big to be OK to copy
OK, I understand. (I'm not a C++ expert, if you haven't figured that out yet).
Why won't this work:
vector<int *> vi;
int i;
vi.push_back(&i);
?
You could write your own pointer container classes.Quote:
I'm not very familiar with the boost library and not keen on mixing that in now.
If there was, Stroustrup would have mentioned it when answering the FAQ on Why are the standard containers so slow?Quote:
I was wondering if there is any more "standard" solution?
It would (assuming the vector does not outlive the scope of i), but code that uses vi[index] would need to be changed to *(vi[index]).Quote:
Why won't this work:
It might work, but as soon as i goes out of scope, you have a dangling pointer.Quote:
Originally Posted by Todd Burch
This is how you never repeat data with boost:
Basically, the idea is to create a shared pointer for each individual resource item, use an ID to find the single shared pointer to the data, and instead of duplicating data we create a boost::weak_ptr and return it and boost pretty much handles all the cleanup for you.Code:#ifndef RESOURCE_MANAGER_H
#define RESOURCE_MANAGER_H
#include <vector>
#include <map>
#include <string>
#include <boost\shared_ptr.hpp>
#include <boost\weak_ptr.hpp>
template< typename T_ >
class Resource_Manager
{
public:
typedef T_ value_type; // std library convention
typedef boost::shared_ptr<T_> Resource_Ptr;
typedef boost::weak_ptr<T_> Resource_Observer;
typedef std::map< std::string, Resource_Ptr > Resource_Map;
Resource_Manager<T_>() {};
~Resource_Manager<T_>() {};
Resource_Observer Request_Resource(const std::string & name)
{
Resource_Map::iterator it = mResources.find(name);
if (it == mResources.end())
{
Resource_Ptr Raw_Resource(new T_);
Raw_Resource->Load(name);
mResources.insert(std::make_pair(name, Raw_Resource));
Resource_Observer Resource(Raw_Resource);
return Resource;
}
else
{
return Resource_Observer(it->second);
}
}
void Request_Resource_Removal(const std::string & name)
{
Resource_Map::iterator it = mResources.find(name);
if (it != mResources.end())
{
mResources.erase(it);
}
}
private:
Resource_Map mResources;
};
#endif
Boost. People who won't use it are masochists.Quote:
Originally Posted by Angelina
Quite correct, I tried doing this without boost and soon found myself with a headache trying to figure out dynamic memory allocation and deallocation on my own.Quote:
Originally Posted by brewbuck
So I took 10 minutes to get the boost libraries and now I use it with most of my programs.
Many libraries in boost are in almost standard. AFAIK the ptr containers library is not in the next standard, but it is still widely used and tested because it is a part of boost.
Switching to a ptr_vector is probably a better solution than creating your own version of it.
Another option is to change the class C to make copying less expensive. for example, if you only need to copy the class when it is inside the vector, then you can move its implementation into a single struct that is held via shared_ptr (another boost item that will be in the next standard). That way you don't have to change the syntax of when you use the vector, you only have to change the implementation of the particular class that is currently slow to copy.
Remember, though, that the solution above assumes the class won't break any other code if you switch to a shared implementation copy versus a cloned implementation copy.
Alternatively, if you don't like *(my_vector_of_pointers_to_obgects[i]), you can also do my_vector_of_pointers_to_obgects->at(i).
Looks better too.
Has different behaviour, though - an additional index check, and a throw if the check fails.
Which is a good thing.
If the index doesn't exist and you use [], you get undefined behavior (bad) or crash.
If the index doesn't exist when you use at, you get an exception. You can handle it and your program can correct the error and continue execution. Or you could just not handle the exception and then the program will crash or display a fancy error message and terminate.
Unless you're already doing your own bounds checking in your own code to make it impossible to pass an invalid index. In that case, using .at() is just a waste of CPU time.Quote:
Originally Posted by Elysia
In 99.99% of the time, it doesn't matter unless you are writing very time-sensitive code.
GCC has the -D_GLIBCXX_DEBUG flag, which in particular causes [] to do bounds checking - see
http://gcc.gnu.org/onlinedocs/libstdc++/debug.html
so one can do a debug build with bounds checking, then recompile without the flag without changing the source later, which I prefer to using at(), the bounds checking of which can't be turned off. I don't know if other compilers have a similar feature.
Exactly as this book suggests: Use a checked STL implementation