Hi C++ experts,
I know this is a very bad programming practice, but I still have to do it. I need to have a vector of MyClass (NOT its pointers for some reason) which behaves like std::string (in fact, much more complicated).
If I have thousands of objects like std::string which is stored inside a resizable array, every time when the array resizes, not only the string objects gets copied over, every element in the old array will get destroyed and deallocated, and every element in the new array will be allocated and constructed, apart from copying over. This is too slow. So I want to do the following way, the array is always allocated and reallocated as a char buffer, everytime when an element is deleted, its destructor will be called and its internal buffers are freed, however, the object's storage space in the array (as a char buffer) is not freed, same for construction and assignment.
In that case, deleting an element from the array will need to invoke the object's destructor ~MyClass() to free its resources BUT WITHOUT freeing itself's storage space sizeof(MyClass) which is allocated as part of a char buffer. Anyway to do that?
Wang Xuancong
how to call con/destructor without all/deallocator?
Re: how to call con/destructor without all/deallocator?
I am not quite sure what you want to achieve, and anyway I daresay you are going about it the wrong way.
Check if pre-allocating an array of sufficient size might solve your problem. I.e., if you know that in 99% of all cases you will not need more than 200 MyClass objects in the vector, allocate the vector with enough space to hold 200 objects:
This way, you will pay the price of de-/reallocation only in those cases where your original estimate doesn't hold (or you are going to sort / shuffle your vector), and might resolve your performance problems (at the cost of less-than-perfect memory usage, but that might be a tradeoff you're willing to pay since this is the easiest sollution of them all).
Most of the time, vector pre-allocation solves the issues people have with the vector template and its reallocation scheme. (Like, "C++ strings are slow" and using C char arrays and running into buffer overflows, when pre-allocating a C++ string with sufficient buffer space would have given them both speed and security... grrrr...)
Another approach would be to have lightweight wrapper classes, which hold references to the "real" MyClass instances (e.g. "MyClassRef"), and handling those wrappers in the vector instead of the real MyClass instances. Details of implementation are up you your specific environment.
But: The #1 question is why you "cannot have" a vector of MyClass pointers (or smart pointers), the way it is intended to be. Most likely that's the point where you should spend your energy, instead of trying to come up with a workaround for (somebody else's?) screwed up design.
Check if pre-allocating an array of sufficient size might solve your problem. I.e., if you know that in 99% of all cases you will not need more than 200 MyClass objects in the vector, allocate the vector with enough space to hold 200 objects:
Code: Select all
vector< MyClass > myVec;
myVec.reserve( 200 );
Most of the time, vector pre-allocation solves the issues people have with the vector template and its reallocation scheme. (Like, "C++ strings are slow" and using C char arrays and running into buffer overflows, when pre-allocating a C++ string with sufficient buffer space would have given them both speed and security... grrrr...)
Another approach would be to have lightweight wrapper classes, which hold references to the "real" MyClass instances (e.g. "MyClassRef"), and handling those wrappers in the vector instead of the real MyClass instances. Details of implementation are up you your specific environment.
But: The #1 question is why you "cannot have" a vector of MyClass pointers (or smart pointers), the way it is intended to be. Most likely that's the point where you should spend your energy, instead of trying to come up with a workaround for (somebody else's?) screwed up design.
Last edited by Solar on Thu Oct 13, 2011 7:19 am, edited 1 time in total.
Every good solution is obvious once you've found it.