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:

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

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:

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:

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 &mdash; 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 &mdash; namely, . (Assuming I can't have negative apples, and I don't much care about integer overflow.) But I also want to use   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
 * That's not a cure-all, but it's certainly one step up in self-documenting-ness from
 * --Quuxplusone (talk) 05:48, 26 August 2008 (UTC)
 * --Quuxplusone (talk) 05:48, 26 August 2008 (UTC)
 * --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.
 * 1) include &lt;iostream&gt;

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  as a function type, whereas your example defines   as a pointer-to-function type.
 * Given the example from libslack, a declaration like  would declare a function named , not a variable holding a pointer to the function; in other words, it would be exactly equivalent to  . To declare a pointer to a function of type  , you'd have to write  . (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   and   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 is it legal and equivalent to write 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  would be used in C-style cast notation.   (talk) 10:14, 29 April 2010 (UTC)

does not create a type
In the "Indicating what a variable represents" section s are used to indicate to the programmer that two values, both implemented as  s, are not the same semantically. However, these s 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  s.  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.  (talk) 18:52, 29 April 2010 (UTC)

And yet, one does get type checking by the compiler if the two s involve identical looking  / s, 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 ?
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  (and maybe   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:


 * Yes, surely this info is more important to the article than some of the current examples.  (talk) 09:03, 30 April 2010 (UTC)
 * Btw, this also applies to enums and structs (a struct is a class).  (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  declaration in C++ also defines an implicit  —that is, the data type can be referred to as   (rather than  ) immediately, without any explicit use of the   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  to the type "pointer to array[3] of  ":''

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++. (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
Please,. 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. please join to establish consensus. AXO NOV (talk) ⚑ 17:39, 25 August 2020 (UTC)
 * CC AXO NOV  (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  tags,   tags, and leading indentation—all three are acceptable.
 * 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)
 * .."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 have reasonable objections here.  AXO NOV  (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)