I know with an array I need to call "delete [] myarray". What about with a vector? A pointer to a vector?
For example:
Code://How should I delete this when done? vector<vector<string> >* vecPointer;
I know with an array I need to call "delete [] myarray". What about with a vector? A pointer to a vector?
For example:
Code://How should I delete this when done? vector<vector<string> >* vecPointer;
>> What about with a vector?
You don't have to call delete on a plain vector.
>> A pointer to a vector?
Call delete on a pointer to a vector only if you used new to allocate the vector.
You may need to use delete [] on your vector pointer if it points to an array of vectors allocated with new []. Although I'm not sure why someone would do that.
>> To avoid copying for one thing. I always tend to do it, wrapping them in smart pointers.
Why not a vector of vectors instead of a dynamic array of vectors? That was the point. And if you're wrapping them in smart pointers, then you're not calling new [] and delete [], the smart pointer is.
Why do you think returning a vector directly (not through a pointer) would involve any copying? We have this thing called RVO.
Returning a pointer would imply that the vector has been dynamically allocated with new. Doing that just to avoid some purely speculative overhead is letting the tail wag the dog.
>> And how will I know the compiler will do RVO?
By profiling your app and not noticing any performance issues in that location.
Besides, rather than return a pointer, just make an output parameter. Dynamically allocating the vector so it can be returned makes little sense.
No, I do believe it can do it, but I don't know how or when.
And an output parameter is not something I like. A smart pointer works just as well. Otherwise the function call needs to be on two lines (one for defining the data and one for calling the function and pass the appropriate argument).
And normally I would avoid complexity. But returning a pointer via a smart pointer is not complexity. It works just as if you'd return by value or take a reference as argument. Because the smart pointer handles everything.
You're picking and choosing which performance concerns to worry about and as a result you're selecting the option that is the least clear. You worry that RVO won't be applied so you don't return a vector by value, but you don't mind all the overhead of dynamically allocating that vector and wrapping it in a smart pointer instead of just using an output parameter.
>> And normally I would avoid complexity.
Your solution adds complexity because it is one more (unnecessary) layer that serves no purpose.
It's hardly anything compared to if RVO wouldn't be applied.
It's completely transparent. If I had to manually delete the pointer, then it would add complexity.>> And normally I would avoid complexity.
Your solution adds complexity because it is one more (unnecessary) layer that serves no purpose.
As Dak'kon use to say: Balance, in all things.
It ensures there will be no copy by value, but perhaps no optimization either, so it's in the middle.
If it's too slow when looking at a profiler, then I will consider changing it.
And remember: Don't optimize performance unless you know it's necessary. If you pass around vectors of 10000 or more elements, perhaps it's a good idea to make sure they are not copied (by profiling, or by using smart pointers or whatever), but copying a few thousand (simple) objects is actually not going to take many microseconds.
--
Mats
Compilers can produce warnings - make the compiler programmers happy: Use them!
Please don't PM me for help - and no, I don't do help over instant messengers.
I know it well, but also as I do mention, it doesn't add complexity and it removes the slight chance of the overhead of copy by value, so it's the middle standpoint.
If it doesn't add complexity (it's just as easy to read, understand and use as if it was not used), then I don't really consider it an optimization.
So anyway, that's my reasoning. Which may or may not be wrong. But it's up to each one to choose a preferable solution, I guess.