In general, a correctly implemented Marching Cubes algorithm generating a mesh with a single LOD will only produce cracks if it doesn't have a consistent way of choosing polarity for the so-called "ambiguous cases". This can be solved by using a fixed polarity based on corner states or some face-level choice function as used in the MC33 algorithm. See Section 3.1.2 of my dissertation at the above link for some discussion of these. Using fixed polarity is easy, and it never generates any holes in the resulting mesh.
A good MC implementation will generate a smooth mesh to begin with if the data at each voxel location has a range of values instead of just a binary in or out state. The ugly stair-stepping only shows up if you're forced to put each vertex right in middle of each isosurface-crossing edge because you don't have enough information to do anything more intelligent.
That won't suppress the some_class destructor being called when array is deallocated or otherwise shuffles elements.
I'm not sure that's an issue in this case, as the OP only specified suppressing the destructor of the temp object. One problem with the locally allocated char array is that it may not have the correct alignment for some_class. A similar example from the C++98 standard had to be changed in the C++03 standard to use dynamic allocation of the char array so that alignment requirements were met.
Then you can declare the char storage with alignas(some_class) in C++11, or __declspec(align(__alignof(some_class))) in Visual C++.
Are you scaling after the rotation, so as to cause a skew? This would cause the tangent and bitangent to no longer be perpendicular, so calculating the bitangent as the cross product between the normal and tangent won't quite work. Instead, if you calculate the bitangent in terms of tan1 just like you calculated the tangent in terms of tan0, you'll get the right vector. But then you can no longer assume that the inverse of the TBN matrix is just its transpose when you do your shading.