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];
  }

  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];
  }

(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.)

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

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.

  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)

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

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

Same kind of thing here:

  char *strings[10]

Here's a simpler example:

  char *str

Here's the simplest example of all:

  char ch;

    char *foo;

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

Basically a fully-fleshed out version of your idea.

  char *foo[10][20];

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

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

* an array of ten arrays of 20

* pointers to

* char

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

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.

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

(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.

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

  int* foo, bar;

  int *foo, bar;

  int* foo;

  int *foo;

    int* i;

    int *i;

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

    int* a, b;

    int *foo;

    int *foo;
    foo = 50;

    int *foo;
    *foo = 50;

    int *foo[50];

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.

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

  int *foo;

  int* foo, bar;

  int *foo; int bar

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]

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.

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. :)

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