I reused this for a stepper motor design that I'm developing. But I used the constructor this time, to do the conversion.

/*  Stepper motor command wrapper
    lightweight 
*/
class command {
public:
    inline command(uint32_t steps, bool reverse) : cmd_(steps << 1 | (reverse ? 0 : 1)) {}
    inline operator uint32_t() const { return cmd_; }
private:
    uint32_t cmd_;
};

My stepper motor driver uses 32 bit instructions. 
Bit 0 is the direction (left/right)
Bit 31 - 1 are the number of steps.

During construction, the two parameters are immediately converted to a single uint32_t, ready for the stepper driver.

How much space does this object take?

data size (each object): same as an uint32_t
code size (one time) - and also the cost of a single conversion: same as a call to steps << 1 | (reverse ? 0 : 1);

example:

command cmd(steps, reverse);

At runtime (firmware), this uses exactly the same resources as when you'd use a uint32_t variable, and fill it by calling:

uint32_t cmd =  steps << 1 | (reverse ? 0 : 1)

The original post uses late conversion. Data is converted when the operator is called. In that design, The operator uint32_t() has the conversion logic.
It makes sense. because the developer may want to manipulate individual register parts, before writing.. And we're not expecting arrays of registers.

In the example that I use in this comment, we don't expect manipulation on the data once it's created. You collect steps and  directions, then send it to the stepper motor.
In that case, it makes sense to convert to the smallest data size immediately, in the constructor, taking the conversion hit at declaration.
When the operator uint32_t() is called, it just passes the data.

The approach allowed me to restrict the code in my firmware to just this:

At the same time, I used way less clock ticks and other resources (init time, memory) than TI's example. Without adding any costs to their (good, I think, but aged) code.

In my C++ posts, I try to distinguish between generic development content, and µController scale topics.

When I put "embedded" in the subject, I think that the technique is usable in a controller with resources comparable to the smallest ARM family. Most of them also with the tiny ATMEL range - although modern toolchain support is more limiting than the controller's resources in this case.

Thanks for all that Jan, I'm mega busy the next few days but I should get  a chance to play with it at the end of the week.

I don't use C++ but my usual tools can compile it so I'll do some comparisons when I get  a chance.

MK

if you like to experiment with this, here is the  C version (TI's code):

#include <stdint.h>
struct CTRL_Register {
    uint16_t DTIME;     // bits 11-10
    uint16_t ISGAIN;    // bits 9-8
    uint16_t EXSTALL;   // bit 7
    uint16_t MODE;      // bits 6-3
    uint16_t RSTEP;     // bit 2
    uint16_t RDIR;      // bit 1
    uint16_t ENBL;      // bit 0
};

CTRL_Register reg;

int main() {
    uint16_t data;
    data = (0x0000 << 12) | (reg.DTIME << 10) | (reg.ISGAIN << 8) |(reg.EXSTALL << 7) | (reg.MODE << 3) | (reg.RSTEP << 2) | (reg.RDIR << 1) | (reg.ENBL);
    return (int)data;
}

#include <cstdint>
struct CTRL_Register {
    uint16_t DTIME;     // bits 11-10
    uint16_t ISGAIN;    // bits 9-8
    uint16_t EXSTALL;   // bit 7
    uint16_t MODE;      // bits 6-3
    uint16_t RSTEP;     // bit 2
    uint16_t RDIR;      // bit 1
    uint16_t ENBL;      // bit 0
    inline operator uint16_t() const {
       return (0x0000 << 12) | (DTIME << 10) | (ISGAIN << 8) |(EXSTALL << 7) | (MODE << 3) | (RSTEP << 2) | (RDIR << 1) | (ENBL);
    }
};

CTRL_Register reg;

int main() {
    uint16_t data;
    data = reg;
    return (int)data;
}