|
> Does std::vector automatically handle the memory releases? Yes. What is going on here is that "img" is being assigned. The "old vector" will have its destructor called, which will call the destructor of all of its elements by default. ------- I assume you're talking about this code: https://github.com/ssloy/tinyraycaster/blob/master/framebuff... void FrameBuffer::clear(const uint32_t color) {
img = std::vector<uint32_t>(w*h, color);
}
Which seems inefficient to me. But it is correct code, even if it is inefficient. There's no memory leak here, but the code probably would be way more efficient if it were instead a simple memset. memset(&img[0], color, w*h*sizeof(uint32_t));
This memset is likely easier to understand, since it doesn't rely upon destructors / constructors / assignment C++ Magic. And its more efficient to boot. Vectors are guaranteed to be contiguous in memory, which is why it is compatible with memset.EDIT: Hmmm... the img is never initialized. You'd also have to do "img = std::vector<uint32_t>(w*h, color);" somewhere. ---------- The rectangle is also inefficient. for (size_t i=0; i<rect_w; i++) {
for (size_t j=0; j<rect_h; j++) {
If i and j were reversed, the draw rectangle function would be more efficient. As it is, "j" iterates in the wrong direction with regards to cache lines... // This would be faster!
for (size_t j=0; j<rect_h; j++) {
for (size_t i=0; i<rect_w; i++) {
Overall though, efficiency isn't a goal at all. Its designend to be a quickie project to get things done as soon as possible. Thinking about all of these details slows down development, so there's something to be said about "just getting it done" |