Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Do you bother typedef'ing most of your number types like this? Or do you just use "int" in most places? It might be more important in my current project with is client / server based and the types have to match when transmitted through the wire as binary data - but I just wondered how far people go with this generally:

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 typedef'ing often does lead to code that looks a bit like this though:

DoSomething(EscalationLevel escalationLevel)
{
    ...
}

Which then makes me think which bit is actually describing the parameter - the parameters type or the parameters name?!

Thanks.

share|improve this question

migrated from stackoverflow.com Jun 20 '11 at 11:12

This question came from our site for professional and enthusiast programmers.

2  
IMHO, seems like a pretty pointless exercise, but I'm sure some others would disagree... –  Nim Jun 20 '11 at 10:03
1  
Those types look like variable names. –  Captain Giraffe Jun 20 '11 at 10:05
4  
Note that this creates the impression that it's type-safe, but it not at all - the typedefs just create aliases, but nothing stops you from passing for example a Minute to a function that has an argument declared as type Second. –  Jesper Jun 20 '11 at 10:06
1  
@Mark: look at it another way. If you make a mistake deciding the integer type, or new requirements emerge in future, and so you want to change it, would you like to change a single typedef or would you like to search the code for every function that manipulates a year, and change its signature? 640k is enough for anyone, and all that. The corresponding downside to the typedef is that people accidentally or deliberately write code that relies on the fact that Year is exactly 16 bits, then it changes and their code breaks. –  Steve Jessop Jun 20 '11 at 10:53
1  
@Steve Jessop: I can't decide if you think it's a good or bad idea :-) The first part seems to be in favour, the latter against. I guess it has pros and cons then. –  Mark Jun 20 '11 at 11:11

6 Answers 6

up vote 10 down vote accepted

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.

share|improve this answer
    
This seems to be the general consensus then. So would you generally just stick to "int"? I have to be very efficient in this app when it comes to transfering data, so would it be a case of just convert to int16_t (or whatever the largest representation type needed for a particular element) during serialization? –  Mark Jun 20 '11 at 10:54
    
@Mark: Yes, that is how you should do it. Use typedefs to express the size of the used data-types, but do not differentiate the same type used in different contexts. –  Björn Pollex Jun 20 '11 at 10:56
    
Thanks - and just to clarify, you wouldn't bother using int8_t instead of int generally in the code.. I suppose my main worry was something like "Identity" which is actually a identity generated by a database. At the moment it is 32bit but I'm not sure yet if that may eventually become 64bit. Also, how about int32_t vs int? int is usually the same as int32_t, but it might not always be I guess on a different platform? I'm thinking I should just stick to "int" generally, and "int64_t" where neccessary.. thanks :-) –  Mark Jun 20 '11 at 11:03
    
@Mark: The important thing about typedefs like int32_t is that you have to make sure they are correct when compiling on different platforms. If you expect the range of Identity to change at some point, I think I would prefer to make the changes directly in all affected code. But I am not sure, because I would need to know more about your specific design. You might want to make that a separate question. –  Björn Pollex Jun 20 '11 at 11:09
    
Okay thanks :-) –  Mark Jun 20 '11 at 11:42

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
You could even write some horrible macro to do all of this class creation for you. (Come on, Skizz. You know you want to.) –  Chris Lutz Jun 20 '11 at 10:22
1  
For some of these, a type-safe units library might be helpful (tuoml.sourceforge.net/html/scalar/scalar.html), rather than writing a custom class for each. –  Steve Jessop Jun 20 '11 at 10:56
    
@Chris - Definitely not a macro, but possibly a template class. As Steve points out, those classes are already written. –  kevin cline Jun 20 '11 at 13:31
1  
@Chris: The macro is called BOOST_STRONG_TYPEDEF actually ;) –  Matthieu M. Jun 20 '11 at 18:15

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.