delete[]

[R.Stiltskin]

Is it OK to delete a list of objects or arrays in a single command, i.e.

delete[] arr1, arr2, arr3;

It compiles, but I can't find this form in any references and I'm not convinced that it's actually freeing the memory.

[anon]

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.

[matsp]

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

[Daved]

Of course, there's very little reason to ever use delete[] in a C++ program at all. Why aren't you using vector?

[R.Stiltskin]

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.

Of course, there's very little reason to ever use delete[] in a C++ program at all. Why aren't you using vector?

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?

[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[].

[R.Stiltskin]

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.

[laserlight]

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.

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.

[Daved]

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.

[cpjust]

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.

Chapter 76. Use vector by default. Otherwise, choose an appropriate container

If you doubt this advice, ask yourself if you really have a compelling reason not to use the only standard container that guarantees all of the following properties. vector alone is:

Guaranteed to have the lowest space overhead of any container (zero bytes per object).

Guaranteed to have the fastest access speed to contained elements of any container.

Guaranteed to have inherent locality of reference, meaning that objects near each other in the container are guaranteed to be near each other in memory, which is not guaranteed by any other standard container.

Guaranteed to be layout-compatible with C, unlike any other standard container. (See Items 77 and Chapter 78)

Guaranteed to have the most flexible iterators (random access iterators) of any container.

Almost certain to have the fastest iterators (pointers, or classes with comparable performance that often compile away to the same speed as pointers when not in debug mode), faster than those of all other containers.

[R.Stiltskin]

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.

[laserlight]

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.

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).

Of course, if you need a fixed size array, then maybe you should go for std::tr1::array (or implement it yourself).

[cpjust]

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.

[C_ntua]

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?)

[matsp]

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.

Or just take the results from my experiments here:
http://cboard.cprogramming.com/showthread.php?t=104334

--
Mats