Is it OK to delete a list of objects or arrays in a single command, i.e.
It compiles, but I can't find this form in any references and I'm not convinced that it's actually freeing the memory.Code:delete[] arr1, arr2, arr3;
Printable View
Is it OK to delete a list of objects or arrays in a single command, i.e.
It compiles, but I can't find this form in any references and I'm not convinced that it's actually freeing the memory.Code:delete[] arr1, arr2, arr3;
Have you turned warnings on. With MingW I get "right-hand operand of comma has no effect". So it compiles because it's the comma operator you are using, except it doesn't do anything for arr2 and arr3.
Comma operator means: evaluate all operands from left to right, discard all results except right-most and return it.
I suspect that will delete arr3, and do nothing useful with arr2 and arr1. I may have it the other way around, and it deletes arr1 then does nothing useful with arr2 and arr3 - but it certainly doesn't delete all three. You need a line.
--
Mats
Of course, there's very little reason to ever use delete[] in a C++ program at all. Why aren't you using vector?
Thanks. I see that if I compile using the -Wall option, gcc gives me
"warning: right-hand operand of comma has no effect"
for each operand after the first, so clearly a separate line is needed for each.
I'm writing some robot-vision image processing code. I'm often addressing pixels at specific computed locations on the image rather than iterating through in raster order, so iterators didn't seem useful. Pointer arithmetic on an ordinary array feels like a more natural way to move around the image. I realize that vector.at() allows addressing specific locations, but wouldn't vector just be adding extra overhead for no particular reason? I'm trying to keep this dog working in real-time, as close to 30 frames per second as possible, so I'd like to avoid any unnecessary burden. Am I wrong?Quote:
Originally Posted by Daved
On most implementations vector's operator[] behaves the same as operator[] with dynamic arrays. (One exception is recent versions of Visual C++ but you can turn off it's extra range checking.)
vector adds very little overhead, but there is a particular reason to use it. You don't have to worry about delete []. You don't have to worry about making your classes copy-safe and you don't have to worry about exceptions (if you use them) causing memory leaks. You probably have most of these things under control, but in most cases (all that I've seen) there is no negative to using the vector versus a dynamic array with new[] and delete[].
Thanks for your input. I'll try to keep that in mind.
Not that I have any reason to mistrust you, but this is supposed to be research, so I should test something both ways to see how much, if anything, vector adds to the running time. When I get around to doing that I'll post a follow-up.
The iterators of a std::vector are random access iterators, just like pointers, so there would be minimal difference. If you want to use raw pointers, &vec[0] for a std::vector named vec will give you a raw pointer to the first element of the std::vector.Quote:
Originally Posted by R.Stiltskin
Of course, I wouldn't expect you to just take my word for it.
A common rule in programming is not to optimize prematurely. Because vector is standard and is safer and more robust than a plain dynamic array, I would generally suggest using it first and then find out if it is causing you any slowdowns (I'd be surprised if it did compared to a plain dynamic array). If you've already started coding your project and you're not familiar with vector, then going the other direction is perfectly fine.
Chapter 76. Use vector by default. Otherwise, choose an appropriate containerQuote:
Originally Posted by R.Stiltskin
Quote:
Originally Posted by C++ Coding Standards: 101 Rules, Guidelines, and Best Practices
cpjust, don't all of those properties relate to vector as compared to other standard containers, as opposed to raw arrays?
I don't doubt that vector provides some very useful features. My question is what do they cost? It's hard to believe that all those benefits come for free. The cost may actually be "trivial", but what's trivial on a high-end workstation may not be trivial on a small robot with a MIPS R4000 processor and only 64MB of ram that has to handle camera and multiple sensor inputs, motor outputs, and multitask among vision, motion, localization, and planning modules.
We've already had the thing choking on code that simply demanded too much, so while Daved's advice about not optimizing prematurely clearly has merit, I'm still jealous about these limited resources and want to convince myself that any added features pay for themselves.
With 64 MB of RAM, you probably cannot afford memory leaks, and std::vector provides automatic, deterministic, memory management. Yes, there are book keeping costs (the container must keep track of its own size and capacity), but those are pretty much the same as you would have if you implemented a dynamic array container by hand (and possibly more efficient since you might say, default construct objects where std::vector delays construction until it is needed).Quote:
Originally Posted by R.Stiltskin
Of course, if you need a fixed size array, then maybe you should go for std::tr1::array (or implement it yourself).
Write a test program that uses dynamically allocated arrays vs vectors and see what the speed difference is. I'm sure there would be an incredibly small difference, but I doubt it would be enough to cause a noticeable difference.
vectors is like a container for a dynamic array with a lot of provided functions. Found in <vector>. So, if you don't mind having those provided useful functions stored in the RAM (which I believe are the size of kilobytes, so you wouldn't really mind) then you should use a vector. Just use the [] to iterate. Nothing more nothing less.
Of course if you are allocating memory with a certain pattern then maybe an array might be better (like increase the capacity by 4 every time you insert a value). But that is probably unlikely on what you are doing. And you probably would use a container. And in the end you could just replace vector with myVector and be more flexible from the beginning.
(I think there was a topic that I was "defending" new vs vector, or am I wrong?)
Or just take the results from my experiments here:Quote:
Originally Posted by cpjust
http://cboard.cprogramming.com/showthread.php?t=104334
--
Mats
37% is a noticeable difference. I wonder what sort of optimization flags you played with in your code.
Yes, but if you read some of the other posts, I have a pretty old compiler, and the newer compilers are actually much closer (and vector is even faster in some of the examples).Quote:
Originally Posted by master5001
Also, my code is the WORST possible scenario for vector, as it does so very little with the value it fetches from the vector.
--
Mats
I don't remember the entire thread and didn't read through it, but wasn't that a comparison between vector and a statically sized array?
We're discussing vector versus a dynamic array with new[]/delete[] here.
You are right. I will hack my test-code - but I suspect it will make much less diference [I didn't remember what I did, so it was good of you to remember this].Quote:
Originally Posted by Daved
--
Mats
Doesn't stack memory work better with your CPU cache, and that's why arrays are faster that dynamic arrays? or is it just the calls to new/delete that slow down dynamic arrays?
In either case, calling vector::reserve() before you start inserting elements can reduce your new/delete calls to just 1.
In the case of replacing new[]/delete[] with vector, you should be able to set an initial size in your vector constructor (just like you do when calling new[]). So there would be no need to call reserve or do any other tricks to reduce the memory allocations.
But wouldn't that fill the array with default initialized elements? I would think that would slow things down a lot more than just calling reserve().Quote:
Originally Posted by Daved
Whether it slows anything down depends on what the array is holding. I guess I'm just talking about a simple replacement that involves using vector and getting rid of the need for delete. I'd consider reserve instead of the constructor to be a premature optimization in this thread.
The CPU cache is based on hash values of cache-line addresses. It has no idea of the difference between stack and heap. Stack might be faster simply because it is accessed more often -- but of course, that's how it should be.Quote:
Originally Posted by cpjust