Improve exception safety with smart pointers

[elfring]

Would you like to wrap any pointers with the class template “std::unique_ptr”?

Update candidates:

• JoltPhysics/Jolt/Renderer/DebugRendererPlayback.cpp

  Lines 49 to 61 in cb2cbee

  	DebugRenderer::Vertex *vertices = new DebugRenderer::Vertex [vertex_count];
  	inStream.ReadBytes(vertices, vertex_count * sizeof(DebugRenderer::Vertex));
  	uint32 index_count;
  	inStream.Read(index_count);
  	uint32 *indices = new uint32 [index_count];
  	inStream.ReadBytes(indices, index_count * sizeof(uint32));
  	mBatches.insert({ id, mRenderer.CreateTriangleBatch(vertices, vertex_count, indices, index_count) });
  	delete [] indices;
  	delete [] vertices;

• JoltPhysics/TestFramework/Image/LoadTGA.cpp

  Lines 79 to 103 in cb2cbee

  	uint8 *palette = new uint8 [pal_bytes];
  	inStream.read((char *)palette, pal_bytes);
  	loaded = loaded && !inStream.fail();
  	// Convert pixel data to a surface
  	surface = new SoftwareSurface(header.mWidth, header.mHeight, format);
  	surface->Lock(ESurfaceLockMode::Write);
  	uint8 *scan_line = new uint8 [scan_width];
  	for (int y = header.mHeight - 1; y >= 0; --y)
  	{
  	// Load one scan line
  	inStream.read((char *)scan_line, scan_width);
  	loaded = loaded && !inStream.fail();
  	// Copy one scan line
  	uint8 *in_pixel = scan_line;
  	uint8 *out_pixel = (uint8 *)surface->GetScanLine(y);
  	for (int x = 0; x < header.mWidth; ++x, ++in_pixel, out_pixel += pixel_size)
  	memcpy(out_pixel, palette + (*in_pixel - header.mColorMapFirstEntryIndex) * pixel_size, pixel_size);
  	}
  	surface->UnLock();
  	// Release temporaries
  	delete [] palette;
  	delete [] scan_line;

[jrouwe]

Jolt explicitly turns off exception handling, so when a new like this fails, the application will just crash.

I don't think there's much point in improving this behavior. When an allocation fails, it's likely that any subsequent allocation will fail too, so the application is dead anyway.

[elfring]

👀 Smart pointers are applied already at several source code places.
💭 Would you like to take the C++ guideline “R.11: Avoid calling new and delete explicitly” better into account?

[Avelina9X]

Avoid using new and deletes explicitly

Firstly, using new is often unavoidable even when using smart pointers; prey tell how you would allocate a unique ptr array without an explicit new call?

And secondly delete is only "unsafe" because you may either forget to call delete, or may call delete multiple times by accident. If you need a "zero overhead" heap array for temp values which you free immediately afterwards there's nothing unsafe about it.

New and delete are only unsafe if ownership and responsibility get passed around and we forget who's job it is to free memory.

If allocs start failing its because you're out of memory. If you're out of memory no amount of exception handling will save you from being out of memory.

[elfring]

🔮 Can mentioned source code places become more succinct?

[jrouwe]

@Avelina9X I think we're talking to a bot. Let's ignore this.

[elfring]

👀 Please take another look at available information sources so that you can get more constructive views.