How far to go with typedef'ing primitive types like int

Question

I have seen C++ code such as the following with many typedefs.

What are the benefits of using many typedefs like this as opposed to using C++ primitives? Is there another approach that might also achieve those benefits?

In the end, the data is all stored in memory or transmitted over the wire as bits and bytes, does it really matter?

types.h:

typedef int16_t Version;
typedef int32_t PacketLength;
typedef int32_t Identity;
typedef int32_t CabinetNumber;
typedef int64_t Time64;
typedef int64_t RFID;
typedef int64_t NetworkAddress;
typedef int64_t PathfinderAddress;
typedef int16_t PathfinderPan;
typedef int16_t PathfinderChannel;
typedef int64_t HandsetSerialNumber;
typedef int16_t PinNumber;
typedef int16_t LoggingInterval;
typedef int16_t DelayMinutes;
typedef int16_t ReminderDelayMinutes;
typedef int16_t EscalationDelayMinutes;
typedef float CalibrationOffset;
typedef float AnalogValue;
typedef int8_t PathfinderEtrx;
typedef int8_t DampingFactor;
typedef int8_t RankNumber;
typedef int8_t SlavePort;
typedef int8_t EventLevel;
typedef int8_t Percent;
typedef int8_t SensorNumber;
typedef int8_t RoleCode;
typedef int8_t Hour;
typedef int8_t Minute;
typedef int8_t Second;
typedef int8_t Day;
typedef int8_t Month;
typedef int16_t Year;
typedef int8_t EscalationLevel;

It seems logical to try and make sure the same type is always used for a particular thing to avoid overflows, but I do often see code where "int" has just been used pretty much everywhere instead. The typedefing often does lead to code that looks a bit like this though:

DoSomething(EscalationLevel escalationLevel) {
    ...
}

Which then makes me wonder which token is actually describing the parameter: the parameter type or the parameter name?

Answer 1

The name of a parameter should describe what it means - in your case the escalation level. The type is how the value is represented - adding typedefs as in your example obfuscates this part of the function-signature, so I would not recommend it.

Typedefs are useful for templates, or if you want to change the type used for certain parameters, for instance when migrating from a 32bit to a 64bit platform.

Answer 2

At first I thought "Why not" but then it occurred to me that if you're going to go to such lengths to separate the types like that, then make better use of the language. Instead of using aliases, actually define types:

class AnalogueValue
{
public:
    // constructors, setters, getters, etc..
private:
    float m_value;
};

There is no performance difference between:

typedef float AnalogueValue;
AnalogValue a = 3.0f;
CallSomeFunction (a);

and:

AnalogValue a (3.0f); // class version
CallSomeFunction (a);

and you also have the advantages of adding parameter validation and type safety. For example, consider code that deals with money using primitive types:

float amount = 10.00;
CallSomeFunction(amount);

Aside from the rounding issues, it also allows any type that can be converted to a float:

int amount = 10;
CallSomeFunction(amount);

In this case it is not a big deal, but implicit conversions can be a source of bugs that is difficult to pin down. Using a typedef does not help here, since they are merely a type alias.

Using a new type entirely means there are no implicit conversions unless you code a casting operator, which is a bad idea specifically because it allows implicit conversions. You can also encapsulate additional data:

class Money {
  Decimal amount;
  Currency currency;
};

Money m(Decimal("10.00"), Currency.USD);
CallSomeFunction(m);

Nothing else will fit into that function unless we write code to make it happen. Accidental conversions are impossible. We can also write more complex types as needed without much hassle.

Answer 3

Using typedefs for primitive types like that looks more like C style code.

In C++ you will get interesting errors as soon as you try to overload functions for, say, EventLevel and Hour. That makes the extra type names pretty useless.

Answer 4

We (at our company) do it a lot in C++. It helps understanding and maintaining code. Which is good when moving people between teams or doing refactoring. Example:

typedef float Price;
typedef int64_t JavaTimestmap;

void f(JavaTimestamp begin, JavaTimestamp end, Price income);

We believe it's a good practice to create typedef to the dimension name from the representation type. This new name represents a general role in a software. The name of a parameter is a local role. Like in User sender, User receiver. At some places it can be redundant, like void register(User user), but I don't consider it being a problem.

Later one may have the idea that float is not the best for representing prices because of the special rounding rules of booking, so one downloads or implements a BCDFloat (binary coded decimal) type and changes the typedef. There is no search and replace work from float to BCDFloat which would be hardened by the fact that there are possibly many more floats in your code.

It is not a silver bullet and has its own caveats, but we think it is much better using it than not.

Answer 5

typedef basically allows you to give an alias for an type.
It gives you the flexibility of avoiding typing the long type names again and again and making your type more easily readable wherein the alias name indicates the intent or purpose of the type.

It's more of an matter of choice if you wish to have more readable names through typedef in your project.
Usually, I avoid using typedef on primitive types, unless they are unusually long to be typed. I keep my parameter names more indicative.

Answer 6

Using typedefs like this is okay as long as whoever winds up using them doesn't need to know anything about their underlying representation. For example, if you want to pass a PacketLength object to either printf or scanf, you'll need to know its actual type so you can pick the right conversion specifier. In cases like that, the typedef just adds a level of obfuscation without buying anything in return; you might as well have just defined the object as int32_t.

If you need to enforce semantics specific to each type (such as allowable ranges or values), then you're better off creating an abstract data type and functions to operate on that type, rather than just creating a typedef.

Answer 7

I would never do something like this. Making sure they all have the same size is one thing- but you only need to refer to them as integral types, then.