Why {typedef int * PTR; const PTR p = & num;} is not equivalent to "const int * p = & num", but "int * const p = & num"?

Question

This thing was partially addressed in another SO question, but somewhat careless, as it was not the main issue. Since my confusion still persists, I put it in a separate question.

Why are the following two statements equivalent to int* const p=&num , rather than const int* p=&num , when the latter looks more logical and intuitive? What are the strict reasons for this typedef behavior?

 typedef int* PTR; const PTR p=# 

And finally, in this question one member notices that using typedef ed pointers is bad practice. But I saw that it is widely used in many books and on websites, and this seems like a convenient task. This makes the code more understandable. So what is the final word? Should typedef ed pointers be avoided as much as possible?

Edit: And what would be the correct syntax for this typedef statement if we intend the following:

  const int* const p=# 

Edit: I inadvertently forgot to ask for an important thing. What is the correct syntax with this typedef statement for the following?

  const int* p=# //instead of the int* const p=&num that we got 

Answer 1

At all,

 const TYPE var = ini; 

declares a const var variable of type TYPE . So

 const PTR p=# 

declares a const p variable of type PTR initialized to num .

A typedef not a text alias, so you cannot just replace the name typedef ed with its extension to see what it returns.

If you want to get

 const int* const p=# 

with typedef , you must typedef something to include const int , for example.

 typedef const int *CI_ptr; 

and then you can write

 const CI_ptr p = # 

(but not so, it's ugly).

And for

 const int *p = # 

You can write

 CI_ptr p = # 

And finally, in this question one of the members notices that using typedef ed pointers is bad practice. But I saw that it is widely used in many books and websites and seems convenient for this, which makes the code more understandable.

Whether this is more comprehensible or less code dependent. One thing that, in my experience, is always bad about typedef pointer types to names that hide the fact that you're dealing with pointers.

 typedef struct list_node { int value; struct list_node next; } *node; 

for example, this is, unfortunately, a common abuse. When you read the node type, you do not suspect that it is a pointer. At least print it before node_ptr . But then, why is typedef pointer in general, the typedef structure and use of node* shorter and clearer.

So what is the last word on it? Should typedef ed pointers be avoided as much as possible?

There is no final authority, so this is basically your decision. Follow the coding style in the company / project, if any, use your opinion if you yourself are coding.

Answer 2

This is one of the problems of using typedef for object pointer types.

The qualifier ( const , volatile ) never penetrates a typedef .

One reason some coding standards prohibit the use of typedef for object pointer types.