22 replies to this topic

[Enthusiastic for Sense]

I'm no C++ expert I'll give you that.

I know enough to do what I can for now, but I never really understood, even after reading, or saw an overall point as to why, what or how exactly typedefs really do anything useful or are necessary for anything in the first place.

Maybe it's just me unable to understand how a typedef may shape something better, but I seriously see no absolute use in it whatsoever.

[Sol_HSA]

If you want to use function pointers, typedefs are the only way to go. =)

Apart from that, they're pretty much sugar in c++.

[alphadog]

Actually, even that is sugar, but sweeter than the other, more generic typedef sugar...

[fireside]

They're a way to obfuscate your code and make it more unreadable. You don't see it in java or c# because there was a movement toward understandable, readable code. People that use it tend to also use 3 letter, meaningless variables.

[Enthusiastic for Sense]

So based on that logic I have no absolute need to even look into or waste time with typedefs?

[geon]

You never need typedefs. They just give you a shorthand, which is nice when you type signatures get long and complex. Like Sol mentioned, it happens with function pointers, but also with C++ templates sometimes.

std::map<std::vector<std::string>, std::list<std::pair<unsigned long, float> > >

Type that 10 times fast...

[alphadog]

fireside, on 03 January 2012 - 06:03 PM, said:

They're a way to obfuscate your code and make it more unreadable.

Unless your typedef is descriptive.

I do agree it can make code abusers more abusive. It's like giving a switchblade-based thief a gun...

[JarkkoL]

There are other practical uses for typedefs in addition to short-hand notations. Here are couple:

1)

typedef unsigned uint32;

2)

define policy classes:

struct my_policy

{

typedef list<int> container;
];

template<class T> void foo(const T &v_)

{

typename T::container c;

...

}

And you can use function pointers without typedefs:

void foo(int) {}
void(*bar)(int)=&foo;

Cheers, Jarkko

[Enthusiastic for Sense]

Okay, thanks then.

I now know that a typedef is 100% officially useless now(to me).

[Stainless]

They are very useful if you work on different platforms, if you only code for a single platform they have limited use.

int may be 8 , 16, 32, 64, 128, or N bits in length, you cannot assume it's 32 bits.

so having a little header file with

#if defined( __64__)
typedef int bigint;
#elif defined(__32__)
typedef long bigint;
#else
#error no idea how big the cpu is
#endif

and then using bigint in all your code is a real lifesaver.

[.oisyn]

fireside, on 03 January 2012 - 06:03 PM, said:

They're a way to obfuscate your code and make it more unreadable. You don't see it in java or c# because there was a movement toward understandable, readable code. People that use it tend to also use 3 letter, meaningless variables.

Please take your FUD elsewhere. C++ is not C# or Java, and the C++ type system is exponentially more complex than those other languages. Also, you're just plain wrong. A feature similar to typedefs exists in C#:

using FooList = List<foo>;

Typedefs can actually help make your code more readable, especially when dealing with lots of nested templates. They're not meant to make your code shorter, and if you do use them for that purpose you're just misusing them.

As for whether you actually *need* them, if you work with elaborate template frameworks you actually do. They are used to define type traits (see STL iterators and allocators for example - you can define an allocator that defines a pointer to T to be something other than simply a T*). Or, if you create crossplatform code, a type might be different on each platform, so typedefs are useful there as well.


But I guess you're that wiseass that defines your function returning a pointer to another function as:

int (*MyFuncThatReturnsFuncPtr(int, float)) (const char *);

// rather than

typedef int MyFuncSignature(const char*);
MyFuncSignature* MyFuncThatReturnsFuncPtr(int, float);

Yeah, the first one is way more readable! </sarcasm>

[fireside]

Quote

Yeah, the first one is way more readable! </sarcasm>

To each his own, I don't see how one is more readable than the other. C# uses delegates which supposedly have some advantages over function pointers.

• Delegates are similar to C++ function pointers, but are type safe.
  
• Delegates allow methods to be passed as parameters.
  
• Delegates can be used to define callback methods.
  
• Delegates can be chained together; for example, multiple methods can be called on a single event.
  
• Methods don't need to match the delegate signature exactly. For more information, see Covariance and Contravariance
  
• C# version 2.0 introduces the concept of Anonymous Methods, which permit code blocks to be passed as parameters in place of a separately defined method.

I've only seen typedefs misused, so I wouldn't actually know about legitimate uses. I see them used for sloppy shorthand like 3 letter variable names. Wasn't trying to spread FUD. Forgive me oh great and learned one. And no sarcasm there because you could code circles around me in your sleep.

[.oisyn]

I don't see how delegates versus function pointers are even in the slightest bit on-topic here. We were talking about typedefs, not comparing language features.

[fireside]

Hmm, yes. I think I lost track of the topic, there. Part of it was on topic, though. I think I was originally implying that c++ is sort of a messy language with my original post and went off on a tangent.

[TheNut]

JarkkoL said:

typedef unsigned uint32;

That's actually one thing that annoys me. There's a lot of libraries that implement their own typedefs for each data type. You run accross someone's method and read "gl_int", "my_library_name_int", "word", "dword", etc. I wish people wouldn't do that. I do love the shorthand though. uint, ushort, etc. should have been the standard since day one.

[Enthusiastic for Sense]

I'm pretty sure I'd rather torture someone to death than use a typedef.

[Kenneth Gorking]

TheNut, on 06 January 2012 - 05:11 AM, said:

That's actually one thing that annoys me. There's a lot of libraries that implement their own typedefs for each data type. You run accross someone's method and read "gl_int", "my_library_name_int", "word", "dword", etc. I wish people wouldn't do that. I do love the shorthand though. uint, ushort, etc. should have been the standard since day one.

Those libraries are only doing that to avoid clashing with client code. I kind of prefer these, to a compilation error.
Everybody should just use <cstdint>, then we can all live in peace

One thing I personally use typedefs for, is for my resources. Instead of havig to write Resource<Texture> or Resource<Model> or Resource<etc.>, I typedef them to RTexture and RModel respectively. Less typing = faster coding.

They can also be used to easily attach information to values:

// Unknown unit
float getDistance(Position p);

// Same type, but now we know the unit
typedef float meters;
meters getDistance(Position p);

[Stainless]

Believe me when you have to port as much code as I do, you LOVE it when people use typedefs.

In my system int is not a valid data type.

I have KDint64,KDint32, KDint16,KDint8 etc. but no int.

So my alternatives are...

1) Go through every line of code changing the variables
2) Use a global find and replace
3) use typedefs.

No brainer really

[JarkkoL]

TheNut, on 06 January 2012 - 05:11 AM, said:

That's actually one thing that annoys me. There's a lot of libraries that implement their own typedefs for each data type. You run accross someone's method and read "gl_int", "my_library_name_int", "word", "dword", etc. I wish people wouldn't do that. I do love the shorthand though. uint, ushort, etc. should have been the standard since day one.

How would you ensure the size of a fundamental type without typedef in C++ then? IIRC, C++0x has uint32_t but prior to that?

[TheNut]

Given the way things are, you can't. Thus it's a necessary evil, but an evil nonetheless. The C standard should have added specific primitive type sizes since day one, like what .NET did. As Stainless wrote above, there should have been an int16, int32, int64, etc. I don't believe a developer should be responsible for that.