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.

if you don't want a compiler to do the job for you, you should try machine code, like Mel :). And since typedefs are just hints to the programmer, if you know what you're doing, you don't need them.

187.37.58.35 (talk) 16:22, 21 October 2009 (UTC)

typedefs are aliases, they don't make new types. They don't prevent the programmer mixing aliases. Some people put an int in struct to use it as a new type. That way the types can't be accidentally mixed. This is more popular in C++ where the operators can be overloaded which simplifies the look of the code when this is done. 194.207.86.26 (talk) 15:07, 28 April 2019 (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)

Not quite, see below.

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)

No, it isn't. The example from libslack defines hsort_cmp_t as a function type, whereas your example defines hsort_cmp_t as a pointer-to-function type.

Given the example from libslack, a declaration like hsort_cmp_t f_cmp_char; would declare a function named f_cmp_char, not a variable holding a pointer to the function; in other words, it would be exactly equivalent to int f_cmp_char(const void *, const void *);. To declare a pointer to a function of type hsort_cmp_t, you'd have to write hsort_cmp_t *pf_cmp_char;. (This can be easily confusing because function types are converted to pointer-to-function types in almost all expression contexts in C. In particular, given the preceding declarations, the expressions pf_cmp_char = f_cmp_char and pf_cmp_char = &f_cmp_char are exactly equivalent. Probably for that reason, typedefs defining function types do not seem to be widely used, despite the notational convenience they bring.) 91.230.17.46 (talk) 14:54, 5 September 2019 (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 and paste it here?

After searching a while, I found the following syntax definition: typedef type-definition identifier;

This syntax definition is wrong. It just happens to lead to a correct result in a subset of cases, but that is not how typedef is defined. This blog entry explains it: https://mpark.github.io/programming/2016/05/12/typedef-literacy/ JonKalb (talk) 16:48, 18 June 2016 (UTC)

Correct me, if I'm wrong, but I think, I can also write something like this in C: typedef struct _NewType { int Value; } NewType, *PtrNewType;

I'm really not familiar with C, but it looks as if there are two identifiers in this statement. —Preceding unsigned comment added by 62.245.129.158 (talk) 11:55, 5 November 2010 (UTC)

First paragraph is incorrect wrt standards

Strictly, POSIX specifies that typedef names ending in _t are reserved for use by standards only. User code should never typedef anything ending in _t (since doing so may cause overlap with later revisions of POSIX etc.), and the standards certainly do not recommend doing so, despite this being a common practice today in system-level software.

The paragraph should be modified to reflect this. At the very least it shouldn't propagate a false recommendation! — Preceding unsigned comment added by 88.192.76.31 (talk) 15:37, 4 November 2016 (UTC)

Syntax Highlighting

@Kbrose: Please, stop removing highlighting. I strongly object any removal of colored code. Colors make it much easier to read. As I see you act against at least two people who made source code examples colored. DarthKitty and Daviddwd: please join to establish consensus.AXONOV (talk) ⚑ 17:39, 25 August 2020 (UTC)

@Tea2min: CC AXONOV (talk) ⚑ 17:42, 25 August 2020 (UTC)

I also have a strong preference for syntax highlighting. When Kbrose removed syntax highlighting from another article a few days ago, however, they described it as "distracting and non-encyclopedic". Furthermore, MOS:CODE doesn't seem to distinguish between <syntaxhighlight lang="X"> tags, <pre> tags, and leading indentation—all three are acceptable.

@Kbrose: Perhaps you could clarify why you think "plain" formatting is more encyclopedic? I can understand the "distracting" claim (though I personally disagree), but surely you can rectify that with a bit of user-specific CSS? DarthKitty (talk) 14:12, 26 August 2020 (UTC)

@DarthKitty: .."plain" formatting is more encyclopedic?.. Hi. In my opinion it's nowehere encyclopedic. It's rather matter of personal preferences and subject to discussion here. It's not regulated by WP:MOS so I personally favor colored code instead of uncolored one. Let's see if Kbrose have reasonable objections here. AXONOV (talk) ⚑ 16:45, 26 August 2020 (UTC)

+1. Syntax highlighting is very good. -- Daviddwd (talk) 17:04, 26 August 2020 (UTC)

Yes, I suppose that syntax highlighting should be encouraged by MOS:CODE. -- Cedar101 (talk) 00:56, 1 September 2020 (UTC)

Fguu

Bennnnnn 78.182.222.153 (talk) 20:35, 10 September 2022 (UTC)