Properly designing types and data structures is, I think, a very important step when programming. It forces to get a good grasp on the domain of the problem uphill, and ensures that a good level of granularity and modularity will make coding safe and easy downhill. It's also a key point to benefit from the power of compiled and typed languages: typed data structures are one way for the compiler to check that the code does what it was intended to do, unlike untyped interpreted languages where one can code absolute nonsense which will never be noticed until it crashes in the hands of the user.

As I was thinking again about this, I wondered if and how it could be possible (in C) to check quantity unit at compile time. In other word, how to detect at compile time a mistake like qtyUnitA += qtyUnitB. If each quantity is an integer or float or any basic type, the compiler won't see any problem here. At best we may have a message about mixing signed and unsigned types.

If you wonder if that's really a problem, think about development in an international context. For example, in a financial software manipulating various currencies, how to guarantee that you're not adding yen and euro values while both are represented with some kind of integer type. Or, a software dealing with distance both in meter and in foot ? Or liter and gallon ? That kind of catastrophic little details...

It's actually quite simple: wrapping the desired type into a structure is all it takes. To create new type quantity easily, I define a macro as follow:

typedef int qty_t; #define Qty(Unit) \ typedef struct Qty ## Unit { qty_t v; } Qty ## Unit

Then one can define "unit quantity" types as follow:

Qty(Meter); Qty(Foot); Qty(Liter); Qty(Gallon); Qty(Euro); Qty(Yen); ...

Then, instead of having, for example:

int distA = 1; int distB = 2;

One would have:

QtyMeter distA = {1}; QtyFoot distB = {2};

A tad more verbose, no pain no gain. Now you can't mistakenly write distA + distB. Yes, because the compiler don't know what to do with that + on two structures, hence you can't neither do distA += distA. Let's solve that by redefining the basic operators for our "unit quantity" types:

#define add(a,b) ((__typeof__(a)){(a).v + ((__typeof__(a))(b)).v}) #define sub(a,b) ((__typeof__(a)){(a).v - ((__typeof__(a))(b)).v}) #define mul(a,b) ((__typeof__(a)){(a).v * ((__typeof__(a))(b)).v}) #define div(a,b) ((__typeof__(a)){(a).v / ((__typeof__(a))(b)).v})

To support operations like distA = 3 * distA one can also define operator mixing "unit quantity" and scalar quantity:

#define scale(a,b) ((__typeof__(b)){(a) * (b).v})

Mathematical functions could be supported as follow:

#define absq(a) (abs((a).v)) #define powq(a, b) ((__typeof__(a)){pow((a).v, b)})

And there would also certainly be need for logical operator which would look like this:

#define eq(a,b) ((a).v == ((__typeof__(a))(b)).v) #define ne(a,b) ((a).v != ((__typeof__(a))(b)).v) #define lt(a,b) ((a).v < ((__typeof__(a))(b)).v) #define gt(a,b) ((a).v > ((__typeof__(a))(b)).v) #define le(a,b) ((a).v <= ((__typeof__(a))(b)).v) #define ge(a,b) ((a).v >= ((__typeof__(a))(b)).v)

Operations can now be performed on those types:

QtyMeter q1 = {1}; QtyMeter q2 = {2}; QtyMeter q3 = add(q1, q2); QtyMeter q4 = scale(q3, 2); QtyMeter q5 = powq(q4, 3); QtyMeter q6 = {216}; assert(eq(q5, q6));

And most importantly, mistakenly mixing types doesn't compile any more:

QtyMeter q1 = {1}; QtyFoot q2 = {2}; // error: conversion to non-scalar type requested QtyMeter q3 = add(q1, q2); // error: invalid initializer QtyFoot q4 = add(q1, q1);

Using _Generic one could also make some automatic unit conversion for valid pairs if desired (see also this previous post on that subject).

In term of performance, the "unit quantity" type has one single field, hence it's the same size in memory as using the wrapped basic type (assert(sizeof(q1)==sizeof(qty_t)); ok!), and it produces exactly the same assembly code.

typedef int qty_t; #define Qty(Unit) \ typedef struct Qty ## Unit { qty_t v; } Qty ## Unit Qty(Meter); #define add(a,b) ((__typeof__(a)){(a).v + ((__typeof__(a))(b)).v}) int main() { QtyMeter q1 = {1}; QtyMeter q2 = {2}; QtyMeter q3 = add(q1, q2); return q3.v; } // gcc unitType.c -S -o unitType.S /****** .file "unitType.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $1, -4(%rbp) movl $2, -8(%rbp) movl -4(%rbp), %edx movl -8(%rbp), %eax addl %edx, %eax movl %eax, -12(%rbp) movl -12(%rbp), %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (GNU) 15.2.1 20251211 (Red Hat 15.2.1-5)" .section .note.GNU-stack,"",@progbits ******/ typedef int qty_t; int main() { qty_t q1 = 1; qty_t q2 = 2; qty_t q3 = q1 + q2; return q3; } // gcc basicType.c -S -o basicType.S /****** .file "basicType.c" .text .globl main .type main, @function main: .LFB0: .cfi_startproc pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset 6, -16 movq %rsp, %rbp .cfi_def_cfa_register 6 movl $1, -4(%rbp) movl $2, -8(%rbp) movl -4(%rbp), %edx movl -8(%rbp), %eax addl %edx, %eax movl %eax, -12(%rbp) movl -12(%rbp), %eax popq %rbp .cfi_def_cfa 7, 8 ret .cfi_endproc .LFE0: .size main, .-main .ident "GCC: (GNU) 15.2.1 20251211 (Red Hat 15.2.1-5)" .section .note.GNU-stack,"",@progbits ******/

Note that this concept of "unit quantity" isn't limited to standard units. For example, imagine a physic engine where you want to be sure you're not mixing vectors representing position and vectors representing speed. It may look like this (here using a macro for step to illustrate the use of _Generic but a function may be more appropriate):

typedef double vec3_t; #define Vec3(Unit) \ typedef struct Vec3 ## Unit { vec3_t v[3]; } Vec3 ## Unit Vec3(PosMeter); Vec3(SpeedMeter); #define v_add(a,b) ((__typeof__(a)){{\ (a).v[0] + ((__typeof__(a))(b)).v[0]}, \ (a).v[1] + ((__typeof__(a))(b)).v[1]}, \ (a).v[2] + ((__typeof__(a))(b)).v[2]}}) #define step(p,u,dt) _Generic(p, \ Vec3PosMeter: _Generic(u, \ Vec3SpeedMeter: ((__typeof__(p)){{ \ (p).v[0] + (dt) * (u).v[0], \ (p).v[1] + (dt) * (u).v[1], \ (p).v[2] + (dt) * (u).v[2]}}))) int main() { Vec3PosMeter p1 = {{0, 0, 0}}; Vec3SpeedMeter v1 = {{1, 0, 0}}; // error: conversion to non-scalar type requested //Vec3PosMeter p2 = v_add(p1, v1); p1 = step(p1, v1, 0.1); assert(p1.v[0] == 0.1 && p1.v[1] == 0 && p1.v[2] == 0); return 0; }

So far that looks promising. I hope I'll find an occasion to try this on a personal project to see if it holds on a real, large and complex project.