Talk:Typedef

typedef uint32 A;

Can anyone tell me what typedef uint32 A; would do  ?

It would create a new type named 'A' that would essentially just be an alias for uint32. You could then create variables like this: 'A newvariables = 3;' Jaddle 17:06, 14 May 2007 (UTC)

= 3 --193.136.128.14 13:12, 17 May 2007 (UTC)

It would be nice to have an explanation of the syntax of recursive typedefs

For example, in C:

int main() {

typedef struct { int key; struct MyType* next; } MyType;

MyType a; MyType b;

MyType* aptr; MyType* bptr;

aptr = &a; bptr = &b;

aptr->key = 3; aptr->next = bptr;

}

The word "struct" is required before the phrase "mytype* next;" The GNU C compiler (3.4.6) warns that "aptr->next = bptr;" is an assignment of incompatible pointer types. —Preceding unsigned comment added by 155.148.36.138 (talk) 14:31, 6 September 2007 (UTC)

Typedefs are confusing

Note that the example given in the page is an excellent example of everything that can go wrong with typedefs. First, your typedef is usually in a separate file, so all the coder will see is:

apple coxes;

Now, ok, what can I do with coxes that are of type apple? Eat them? No I can increment them:

coxes += 1

So what exactly happens when you increment an apple? Especially in C++ with type overloading? All you've done is obscure the type of the variable. The data type should specify the variables _data_ _type_. Not describe it. That's what the name is for. The following code would be much, much clearer:

int coxe_apple_cnt = 0;

Now we have a variable that is a count of the number of coxe apples (coxe is a type of apple, I presume). It's type is int. Now we have a much clearer notion of what:

coxe_apple_cnt++;

Does.

So what's good about typedefs again? —Preceding unsigned comment added by 12.155.58.181 (talk • contribs)

Wikipedia is not a programming tutorial, but just for the record, you're doing it wrong. If you want a type to hold an apple, make it behave like an apple — that's the problem object-oriented programming and C++'s operator overloading are trying to solve. C's typedefs are trying to solve a different problem: I've got a type that holds, let's say, a count of how many apples I have — namely, unsigned int. (Assuming I can't have negative apples, and I don't much care about integer overflow.) But I also want to use unsigned int to hold some bitmasks in the same program, and I want to make sure that I don't accidentally add one of those bitmasks to my apple count, or pass one of my apple counts as a parameter to a function expecting a bitmask. The solution (that's relevant to this article) is

typedef unsigned int AppleCount_t;
typedef unsigned int BitMask_t;
extern void eat_apples_and_chew_bits(AppleCount_t, BitMask_t);

That's not a cure-all, but it's certainly one step up in self-documenting-ness from

extern void eat_apples_and_chew_bits(unsigned int, unsigned int);

--Quuxplusone (talk) 05:48, 26 August 2008 (UTC)

Thanks for the tip on the wikipedia rules!. Right about that. However, you're wrong about how typedefs are handled. You stated:

"I want to make sure that I don't accidentally add one of those bitmasks to my apple count, or pass one of my apple counts as a parameter to a function expecting a bitmask"

But! this code compiled and ran just fine with g++ 4.2.4.

#include <iostream>

typedef unsigned int apple;
typedef unsigned int orange;

using namespace std;

void apples_to_oranges( apple a, orange o )
{
    if( a > o )
    {
        cout << "Typedefs let you compare apples to oranges!" << endl;
    }
}

int main()
{
    apple a;
    orange o;
    apples_to_oranges( a, o );
    apples_to_oranges( o, a );
}

I assume correcting factual mistakes is OK on wikipedia, right? Sorry if not. I didn't see anything in the article about what you said either, so not sure if any of our comments are relevant. The article itself is excellent. Concise, and gives both sides. No issues with that. .

---

The first example is indeed stupid. I should be replace it by something realistic like

typedef unsigned char Byte;
typedef unsigned int Address;
typedef unsigned long Handle;

if you want the compiler to do the job for you go try java, typedefs are great for those who know how to use. 187.37.58.35 (talk) 16:22, 21 October 2009 (UTC)

Typedef for subroutines?

As from the libslack project:

typedef int hsort_cmp_t(const void *a, const void *b);

So this is a typedef for a subroutine? --Abdull (talk) 21:27, 9 December 2009 (UTC)

Yes, it defines the type hsort_cmp_t as (int *)(const void *, const void *), a pointer to a function returning an int and taking two const void pointers as arguments.

If you then declare such a variable (as a function argument, or as a local variable), you can just declare it like "hsort_cmp_t pf_cmp_char". I assume that in the example, it is a pointer to comparison function which is passed to a sort function. -- Paul Richter (talk) 13:00, 5 April 2010 (UTC)

Also, it is exactly equivalent to

typedef int (*hsort_cmp_t)(const void *a, const void *b);

right? --Quantling (talk) 18:37, 29 April 2010 (UTC)

Use of casting notation?

Instead of

typedef int (*ImagePointer)[3];

is it legal and equivalent to write

typedef int (*)[3] ImagePointer;

If I haven't screwed it up, the latter is the notation that would be used in C-style casting. I think the article should mention whether or not this is legal and equivalent. Thank you. Quantling (talk) 15:32, 14 April 2010 (UTC)

No, the latter is not a legal typedef. You're correct that (int (*)[3]) would be used in C-style cast notation. decltype (talk) 10:14, 29 April 2010 (UTC)

typedef does not create a type

In the "Indicating what a variable represents" section typedefs are used to indicate to the programmer that two values, both implemented as ints, are not the same semantically. However, these typedefs do not also indicate this to the compiler ; C/C++ compilers will allow free "conversion" between variables of these two types as if they were both declared simply as ints. At least this is the case with the compilers I have tried, and I know of no simple way to get a compiler to enforce type checking in this scenario. To the extent that I have this right, should any of it be added to the article? --Quantling (talk) 18:34, 29 April 2010 (UTC)

You're right, the example is misleading in that it seems to indicate that typedefs are something they're not - that they will provide some sort of type checking. A common(?) misconception. decltype (talk) 18:52, 29 April 2010 (UTC)

And yet, one does get type checking by the compiler if the two typedefs involve identical looking class/structs, right? That is, will not the compiler complain about the following?

 typedef struct { int a; } StructOne;
 typedef struct { int a; } StructTwo;
 StructOne X;
 StructTwo Y;
 Y = X;

Though, the compiler will not complain about

 typedef struct { int a; } StructZero;
 typedef StructZero StructOne;
 typedef StructZero StructTwo;
 StructOne X;
 StructTwo Y;
 Y = X;

because StructOne and StructTwo are defined from the same type, not merely identically looking types. Same question as before: to the extent that I have this right, should any of it be added to the article? --Quantling (talk) 19:20, 29 April 2010 (UTC)

This has nothing to do with typedefs though. Each struct always creates a new type (even if it is not named). Compatibility between structs is never determined by "identical looking"-ness. --169.232.246.212 (talk) 08:43, 30 April 2010 (UTC)

 struct foo { int a; };
 struct bar { int a; };
 struct foo X;
 struct bar Y;
 Y = X; // error

Implicit typedef?

I know that there is a difference in plain C, but, in C++, how, if at all, is

 class MyName { ... };

different from

 typedef class { ... } MyName;

and similarly for struct (and maybe enum too)? Regardless of the answer, should it be mentioned in the article? --Quantling (talk) 19:11, 29 April 2010 (UTC)

The latter is a typedef declaration that happnes to declare an unnamed class. The resulting typedef-name, MyName, can't be used in certain circumstances:

typedef class 
{
  MyName(); // error, a class-name is required for a constructor. This is a function with no return type
} MyName;

void f()
{
  int MyName; // declares an object "MyName" of type int
  class MyName myName; // error, typedef-name following the class-key in an elaborated-type-specifier
}

Yes, surely this info is more important to the article than some of the current examples. decltype (talk) 09:03, 30 April 2010 (UTC)

Btw, this also applies to enums and structs (a struct is a class). decltype (talk) 09:04, 30 April 2010 (UTC)

reversion

Regarding

08:46, 30 April 2010 169.232.246.212 (talk | block) (7,474 bytes) (Undid revision 359028539 by Decltype (talk) what part of this is incorrect?) (rollback | undo) 
(cur | prev)  09:58, 29 April 2010 Decltype (talk | contribs | block) (6,874 bytes) (→Using typedef with pointers: rm misinformation) (undo) 

The text was:

Note that a struct declaration in C++ also defines an implicit typedef—that is, the data type can be referred to as var (rather than struct var) immediately, without any explicit use of the typedef keyword. However, even in C++ it can be worthwhile to define typedefs for more complicated types. For example, a program to manipulate RGB images might find it useful to give the name ImagePointer to the type "pointer to array[3] of int":

I removed the information because it incorrectly asserts that a struct declaration in C++ defines an implicit typedef, which has no basis in the language. Instead, C++, allows you to omit the class-key in an object declaration. The ImagePointer example, the way I see it, is just original research unless backed by a source - especially considering that typedeffing pointer types is often discouraged in C++. decltype (talk) 09:44, 30 April 2010 (UTC)

I guess the point of the first part was that in C, the only way to introduce a new single-word type identifier was using typedef. But in C++, struct, class, enum, etc. can also introduce new single-word type identifiers. So from the perspective of C, it is as if each of these did a typedef. But, on a second look, it seems that this is already covered in the "Simplifying a declaration" section. So feel free to remove it again I guess. --169.232.246.183 (talk) 20:11, 2 May 2010 (UTC)

Syntax

What I'm really missing is the general syntax of the typedef keyword. Can anyone copy it from a C book any paste it here?