Orientation rotation flip

[peterrum]

Merge orientation/flip/rotation to a single char with the meaning of the bits:

• bit 0: orientation
• bit 1: flip
• bit 2: rotation

In the case of other mesh entity types these number might have a different meaning.

Note: This is solely an internal change. The TriaAccssors still return the same information.

[tamiko]

This looks reasonable.
We have quite a number of tests for face orientation/rotation/flip. Let's run the full testsuite and see what happens.

[tamiko]

/rebuild

[kronbichler]

Nice simplification. One thing I don't have clear for myself is why there is this asymmetry in the access to the orientation of a face versus the flip and rotation; the former gets queried through the TriaObjects{Quad,Hex}3D whereas the latter two are only in the accessor.

[bangerth]

Out of curiosity: you're doing this because you want to generalize it for triangles/tets?

It doesn't matter much in the grand scheme of things, but a vector<bool> really just stores one bit per element. So having three such vectors requires less memory than storing one vector<char>.

[bangerth]

On the plus side, the vector<bool> specialization is deprecated and we should avoid using it anyway :-)

[peterrum]

Out of curiosity: you're doing this because you want to generalize it for triangles/tets?

Exactly. This is a preparation for that.

It doesn't matter much in the grand scheme of things, but a vector really just stores one bit per element. So having three such vectors requires less memory than storing one vector.

I was not aware that vector<bool> has its own specialization. Now, it makes sense why I had issues with vector<bool> in the past!

Normally bool and char are equivalent in terms of size (just that bool only wastes 7 bits).

[bangerth]

Yes, std::vector<bool> is a special case: https://en.cppreference.com/w/cpp/container/vector_bool

But it's not true that bool and char are equivalent in size. That actually depends on the platform, but on many platforms it is stored as a 32-bit data type for alignment reasons. (Not on x86_64, however.)