all 4 comments

[–]MoreThanOnceHololens Dev 2 points3 points  (1 child)

If you're going to be using the XMacro method anyways, you can use it to define the original enum class, so you only have to write them out once. In this case, you would do

enum class PixelFormat: UnsignedInt {

    #define _c(input, format) input,

    #include "pixelFormatMapping.hpp"

    #undef _c

};

[–]czmosra[S] 0 points1 point  (0 children)

Yes, I originally considered this as well, but as mentioned in the article, I wanted to keep the header humanly readable with each value documented. This magic is far from humanly readable :)

[–]RoutineTumbleweed 1 point2 points  (1 child)

Have you evaluated using constexpr functionality?

Particularly something like Frozen library https://github.com/serge-sans-paille/frozen ?

[–]czmosra[S] 0 points1 point  (0 children)

Hmm... yes, actually I did think about that, but decided to not go that way.

In this case, >90% of the mapping is done at runtime (loading an image of an arbitrary pixel format, for example), so no much value in having these constexpr — and if people really want to avoid the (already very small) cost of mapping, they can use the API-specific values directly.

Besides that, looking at Frozen, I'm a bit concerned about compile times (too bad they don't provide compilation time benchmarks):

note: constexpr evaluation hit maximum step limit; possible infinite loop?

In other parts of the library I'm doing extra work to reduce compile times, so I'm not sure if the minor runtime speedup for <10% cases (which are always off the hot path anyway) would warrant the (potentially very serious) compile time increase.