> infinitely more simple and readable, It's simpler at the expense of being more bug prone. Notice that the "simpler" struct has no housekeeping code to "del

> infinitely more simple and readable, It's simpler at the expense of being more bug prone. Notice that the "simpler" struct has no housekeeping code to "delete[]" the memory. The programmer now has to manually "manage" that cleanup somewhere. >, and the layers of abstraction added are of pretty much no value here. The "value" he's addressing from the "simpler" but more fragile code: 1) remove bug-prone code which requires manually synchronization (copy&paste) of pointer types in both the lines defining the variable and the subsequent lines casting the pointer from a raw buffer: "mesh->positions = (Vector3 )mesh->memory_block;" 2) remove brittle manual arithmetic of pointer offsets embedded inside contiguous arrays such as: "mesh->uvs = (Vector2 )(mesh->memory_block + positions_size + indices_size);" Calculating offsets (and/or enforcing logical boundaries) inside of arrays is very error prone and the OpenSSL Heartbleed bug was an example of that type of defect. 3) manage the release of memory using unique_ptr. Obviously, it is to help the programmer (and other coworkers using Mesh data structs) avoid memory leaks. >features like this that add nothing and just complexify the code for no reason. It doesn't look like "no reason" to me. The attempt was to reduce bugs, and add memory safety.