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;
Printable View
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;
A vector is not an array. Just use "delete."Quote:
Originally Posted by 6tr6tr
>> 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.
>> 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.
It's not an array, it's merely about returning a vector. Returning a pointer ensures no copying is done with the vector data.
For arrays, I always use vector.
Why do you think returning a vector directly (not through a pointer) would involve any copying? We have this thing called RVO.Quote:
Originally Posted by Elysia
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?
>> 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.
You're always singing the praises of Visual Studio and now you don't believe it will do something as simple as RVO? A compiler that doesn't do this optimization is not worth using unless you have no choice.Quote:
Originally Posted by Elysia
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.Quote:
Originally Posted by Daved
It's completely transparent. If I had to manually delete the pointer, then it would add complexity.Quote:
>> 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
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.
Funny how you apply this argument here. I would suggest the exact same thing but in reverse. Return by value, and profile it to make sure it's not being "stupid."Quote:
Originally Posted by Elysia
It took me a long, long time to realize that pointers suck. Maybe there is hope for you.
Pointers suck when not wrapped in smart pointers :p
That's my experience. Most of the "access violation" I get is with complex, non-C++ish code, such as managing buffers and pointers by hand (which I do avoid).
Mostly it's old code, written many years ago or so. We improve all the time!
This may be applicable to you, though it pertains to the 2005 version of Visual C++:Quote:
No, I do believe it can do it, but I don't know how or when.
Named Return Value Optimization in Visual C++ 2005
They suck even then. Just a tiny bit less. Value semantics rule.Quote:
Originally Posted by Elysia