Lol, yeah, array overload/specialization of unique_ptr is mostly useless, but for a buffer like image data it works well enough since vector seems to be overkill. What I mean is vector is geared for flat arrays with dynamic size properties. A 2D buffer of Color doesn't necessarily fit either case; vector nor unique_ptr, but if you wanted to build a type I would imagine a bare bones raw pointer wrapper such as unique_ptr would be a better suited base to start with than vector. The only downside to using unique_ptr over vector in this situation would be the fact that unique_ptr deletes the copy constructor and copy assignment operator.
This is actually okay though as you'd want to verify that the two 2D arrays were of equal dimensions and color depth and such. So using a unique_ptr forces you to implement your own copy solution whether it be a constructor or assignment or a clone function to avoid accidental pass by value situations.
That being said, I suppose there are ways to have the desired 2D array effect:
Code: Select all
std::vector<std::vector<Color>> pixels( height, std::vector<Color>(width) ); and
auto pPixels = std::make_unique<std::unique_ptr<Color[]>[]>( height );
for( auto y = pPixels.get(), end = pPixels.get() + height; y != end; ++y )
{
*y = std::make_unique<Color[]>( width );
}
for( size_t y = 0; y < height; ++y )
{
for( size_t x = 0; x < width; ++x )
{
pixels[y][x] = Colors::Blue;
pPixels[y][x] = Colors::Black;
}
}
Neither is pretty, but the latter is definitely less readable.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com