No more confusions on tricky C declarations(c-faq.com)

132 pointsby ashishb4uvor 16 Jahren41 comments

No more confusions on tricky C declarations

http://c-faq.com/decl/spiral.anderson.html

10 comments

tptacekvor 16 Jahren

I've always had a bit more luck with the "typedef each step of the construction" rule-of-thumb. Also, I tend to hide anything as complex as "pointer-to-array-of-pointers-to-functions" (even though you memorize this idiom pretty quickly after an hour in the kernel) behind library ADT's, so you're never indexing an array, but rather passing an index and a whatever_t* to whatever_get(w, index).

scott_svor 16 Jahren

That's a good approach, but sometimes you can't do it in C++. (At least with C++03.) Consider:

  template <class T>
  T* new_align_1d(size_t d1, unsigned int align)
  {
    void* ptr = _malloc_align(d1 * sizeof(T), align);
    return new (ptr) T[d1];
  }

So, I'm defining a function new_align that takes a size and an alignment. I allocate enough space for a 1-dimensional array of the given size on that alignment, then use the placement operator to construct the actual objects in that place. Then return the pointer. Pretty straightforward. So let's generalize one dimension up:

  template <class T, size_t d2>
  ? new_align_2d(size_t d1, unsigned int align)
  {
    void* ptr = _malloc_align(d1 * d2 * sizeof(T), align);
    return new (ptr) T[d1][d2];
  }

You can probably see what I'm doing here. So what's the return type? And what's the syntax for specifying it? Since it's a template, we can't define a typedef to help us. (C++0x should allow that with parameterized typedefs.) The answer surprised me - I really had to look at the grammar and mechanically figure out what it was going to be.

(Yes, I have to pass d2 as a template parameter - it's part of the type of the array and must be known at compile time.)

apuvor 16 Jahren

The fact that I instantly recognized this problem case (having had it many times myself) makes me sad.

I'm so incredibly happy that 95% of the code I write now is in Python.

rntzvor 16 Jahren

This is a Good Idea, but it doesn't help you understand other people's code if they don't follow it. Hence the need for a mnemonic rule.

jakevoytkovor 16 Jahren

A coworker introduced me to the ADT-style solution for nesting problems, and it works nicely. He introduces a struct that encapsulates any nested inner collection. It's worth noting his designs use fat structs in a shallow hierarchy.

This has an added advantage (and burden) when calling the code. Since you access a field inside of the struct, you write extra names. The claim is that myList[0].fnList[0].fn(3) is more readable than myList[0][0](3). This can get cluttered with lots of nesting, but this kind of nesting usually screams "refactor me!" anyways.

I prefer a mix: make the common inner collections into data types, and typedef the rest. Doing it all the time creates too many little structs for my liking.

joe_the_uservor 16 Jahren

The second approach, that's what I like...

loup-vaillantvor 16 Jahren

An ML like notation would be even more cool:

  char *str[10];
  str : [10] (*char)

  char *(*fp)( int, float *);
  fp : *((int, *float) -> *char)

  void (*signal(int, void (*fp)(int)))(int);
  signal : (int, *(int -> void)) -> *(int -> void)

(Oh. That last declaration did make some sense, after all…)

Really, how did they manage to chose such an inconsistent, unreadable syntax for their declarations? Is there any rational explanation?

fexlvor 16 Jahren

The rationale is that the type declaration demonstrates how you use the variable. For example:

  char *(*fp)(int, float *)

You now have a variable called "fp". Follow that pointer by putting a * in front of it. Call that function by passing it an int and a float pointer inside parentheses. Follow that pointer by putting a * in front of it. That gives you a char.

Same kind of thing here:

  char *strings[10]

You now have a variable called "strings". Index that array by putting an offset less than 10 inside square brackets. Follow that pointer by putting a * in front of it. That gives you a char.

Here's a simpler example:

  char *str

You now have a variable called "str". Follow that pointer by putting a * in front of it. That gives you a char.

Here's the simplest example of all:

  char ch;

You now have a variable called "ch". That gives you a char.

endgamevor 16 Jahren

AIUI, the explanation is that they wanted this idea of "declaration follows use". For simple things, this works kind of nicely:

    char *foo;

Says that *foo will have type `char`. This sounds good in theory, but famously breaks down when things get more complicated (arrays of function pointers, multiple declarations at once, &c.).

mturmonvor 16 Jahren

Yes, see van der Linden's Deep C Secrets:

http://books.google.com/books?id=4vm2xK3yn34C&printsec=f...

jerfvor 16 Jahren

This was on HN a bit ago, and you reminded me of it: http://www.csse.monash.edu.au/~damian/papers/HTML/ModestProp...

Basically a fully-fleshed out version of your idea.

rntzvor 16 Jahren

Fails on nested arrays.

  char *foo[10][20];

The method described would indicate that this is a array 10 of pointers to array 20s of chars.

This is incorrect. It is an array 10 of array 20s of pointers to chars.

tordekvor 16 Jahren

How so?

         +-----------+
         | +-+       |
         | ^ |       |
    char *foo[10][20];
     ^   ^   |       |
     |   +---+       |
     +---------------+

* foo is

* an array of ten arrays of 20

* pointers to

* char

rntzvor 16 Jahren

Following the procedure as written:

         +-------+ 
         | +-+   |
         | ^ |   |
    char *foo[10][20];
      ^  ^   |   |
      |  +---+   |
      -----------+

It mentions, in rule 1, handling tokens of the form [] or [X], but not multiple occurrences of these.

This is indeed rather nitpickish of me, but on the other hand, one thing that you at least need to know in that case is in what order you read the numbers - left-to-right, or right-to-left (is foo[10][20] a 10-array of 20-arrays or a 20-array of 10-arrays?). Not mentioning this leaves one (at least, it left me) with the impression that multiple occurrences were already handled by this rule as written, which is, as demonstrated, false.

jeffmaxvor 16 Jahren

http://cdecl.org/

javertvor 16 Jahren

"So is somebody gonna create a tool that uses this parser so you can declare your C in English?" -My roommate

exitvor 16 Jahren

this is fantastic, but apparently "void (signal(int, void (fp)(int)))(int);" is a syntax error?

loup-vaillantvor 16 Jahren

It is not, but their implementation is incomplete. They parse it correctly when you remove "fp". Apparently, they don't handle declarations which have another identifiers besides the one that is declared.

  int f(int  ) // OK
  int f(int i) // fail

Amnonvor 16 Jahren

I don't see where the spiral comes in. The following rule is simpler:

(1) Begin at the variable name, read from left to right, then go back to the name and read from right to left.

(2) Give precedence to expressions in parentheses.

For example: char (fp)( int, float * )

The innermost expression is (* fp). Nothing to the right of the fp. so read to the left: "* ", it's a pointer. Next, we go right and see an arguments list, so it's a pointer to a function taking these arguments. Go back to where we started and read right to left: Pointer to a function taking (int,float *) that returns a pointer to char.

ashishb4uvor 16 Jahren

left-to-right and right-to-left is spiral infact :)

ruevor 16 Jahren

    char* str[10]; /* Better */

gmartresvor 16 Jahren

I disagree, the following:

  int* foo, bar;

could be interpreted as declaring two pointers, whereas:

  int *foo, bar;

makes it clear that only the first variable is a pointer.

godDLLvor 16 Jahren

I don't think you should be declaring mixed types with one statement. Declare a pointer, then declare the `int` separately -- and the mystery is gone.

masklinnvor 16 Jahren

I believe the point is that, with that syntax, you can't declare multiple same-type pointers on the same line

scott_svor 16 Jahren

I find that problem goes away if you only declare a single variable per line. Generally, I find people who do

  int* foo;

Started with C++ and people who do

  int *foo;

Started with C. I started with C++.

dkerstenvor 16 Jahren

I have made the same observation and as someone who started with C++, I think it makes more sense that

    int* i;

is an int pointer named i.

    int *i;

just looks strange.. an int named pointer i umm?

Besides, declaring only one variable per line seems less cluttered to me, so I never get the

    int* a, b;

confusion.

prodigal_erikvor 16 Jahren

I never put the asterisk next to the type, because I wanted to train myself the way the grammar actually works rather than the way almost everyone wished it worked.

scott_svor 16 Jahren

But the compiler recognizes the type of the variable as int*.

rbonvallvor 16 Jahren

When used in an expression, I read p as "what's pointed by p". In a declaration, this applies as well:

int *i;
means "what's pointed by i is an int".

dkerstenvor 16 Jahren

That makes more sense alright, but I still think it would make a lot more sense if * was bound to the type.

ruevor 16 Jahren

Declaring two different types on the same line is fraught with confusion, so it is to be avoided.

milodvor 16 Jahren

I've always found putting the * next to the type instead of the variable, like this, more intuitive. Does anyone know why the other way is used more often? Is it just historic, or is there a more practical reason?

tordekvor 16 Jahren

As said elsewhere: "Declaration follows use".

int *foo;
means "foo is a pointer to int". But that's explained different from how it's written. More clearly, you can say that "foo" is an int. Then, doing

int *foo; foo = 50;
is obviously wrong because "foo" is not an int; however

int *foo; *foo = 50;
is correct.

Similarly for arrays:

int *foo[50];
means "foo is an array of pointers to int", or "foo[5] is an int".

From there follows that & is the antithesis of , and they negate each other:

int *foo; //foo is a pointer to int. &*foo; //the address of the contents of foo foo; // same as above, but shorter.

ewjordanvor 16 Jahren

Sorry, that didn't make much sense to me - in your first example, you can't say "foo is an int", because it's not, it's a pointer to an int. And in your last example, you can't say "foo[5] is an int", because it's not, it's a pointer to int.

In response to the original question, I think the answer is that

int *foo;
is a common way of writing it because that's the way the compiler resolves it. As mentioned elsewhere,

int* foo, bar;
is equivalent to

int *foo; int bar
so treating the star as part of the type can cause problems.

But I agree fully - it makes a lot more sense to me to consider the pointer star as a flag on the type, not a modifier to the name. Just one of the many warts on C and C++ that make me happy I have to use them so infrequently...

[Edit: formatting, stars were getting swallowed when put inline]

lmkgvor 16 Jahren

> [Edit: formatting, stars were getting swallowed when put inline]

The same thing happened to the post you're responding to, and that's why it's not making sense to you. The author really meant to say star-foo and star-foo[5], but instead italicized a bunch of text in between.

ewjordanvor 16 Jahren

D'oh.

Don't know how I didn't realize that, given that my response got messed up so that my "corrected" version read exactly like the one I was confused about...

Please disregard everything I said, in that case. :)

MtLvor 16 Jahren

Meh! This is just an overly complication of the right-left rule, which makes you think about "complex" 2D geometry instead of a couple of simple spatial pointers in the declaration you are trying to parse..

The easier, more useful version: http://ieng9.ucsd.edu/~cs30x/rt_lt.rule.html

joe_the_uservor 16 Jahren

It is amazing to me the number of people who would take the time to make ASCII graphics in their replies.

I'm blessed that even munging 15+ Linux c/c++ libraries lately I haven't run into anything requiring this - though my Intro to C class, at Merit College twenty five years ago did teach to this rule.

Hats off to you anyway...

AndrejMvor 16 Jahren

No problems here, that is, with D's right-to-left declaration syntax. ;)

mkramlichvor 16 Jahren

yes this is the kind of thread I expect to see @WalterBright chime in on :)

ashishb4uvor 16 Jahren

Sure helps to read code faster!