eddy@clipper.robadome.com (eddy Gorsuch) writes:

>I was trying to declare a type that held 32 characters, so I naturally:
>  typedef char CA[32];
>
>Later on, I had a pointer that I wanted to instantiate memory for:
>  CA* ca = new CA;
>
>And my compiler complained that a value of type "char *" could not
>initialize an entity of type "CA *". I looked in the DWP, and lo and behold,
>new isn't supposed to accept typedef-names (so the compiler seems to be
>right).

I think you have misread the DWP; new is certainly supposed to accept
typedef-names.  The error you got was a type error, not a syntax error.

The reason the type error occurs is that `new' of an array is treated
differently from `new' of an object. `new' of an array returns a pointer
to the first element of the array, not a pointer to the array itself.
So the type of `new CA' is `char *', not `CA *'.

(Yes, it is rather inconsistent; the inconsistency is the direct result of
C's failure to sufficiently distinguish pointers to objects from pointers
to arrays.)

--
Fergus Henderson            | Tell you what: go write a 100x100 matrix multiply
fjh@cs.mu.oz.au             | of integers in both languages and then let's talk
http://www.cs.mu.oz.au/~fjh | about speed, ok? - Tom Christiansen.

In article <3n9moo$37d@eclipse.eng.sc.rolm.com> eddy@clipper.robadome.com (eddy Gorsuch) writes:
>I was trying to declare a type that held 32 characters, so I naturally:
>  typedef char CA[32];
>Later on, I had a pointer that I wanted to instantiate memory for:
>  CA* ca = new CA;
>
>And my compiler complained that a value of type "char *" could not
>initialize an entity of type "CA *". I looked in the DWP, and lo and behold,
>new isn't supposed to accept typedef-names (so the compiler seems to be
>right). Is this an oversight, or is there a reason I don't know about that
>stops me from trying to allocate a block of data this way?

Typedefs are just fine in "new".  However, when you "new" an array, "new"
returns a pointer to the first element of an array, rather than a pointer
to the whole array.  That's the same address, but with a different type:
"char *" rather than "CA *" in your example.

This behavior does make sense.  C++, like C, has arrays that are second-class
types, and most operations on arrays are done through pointers to elements
of those arrays.  So if you do "new char[20]", it's more convenient to get
back a "char *" than a "char (*)[20]".

If you're trying to define CA to be a "block of memory" as you say, you'll
find it much easier if CA is not an array.  One technique is to wrap the
array inside a struct:

struct CA {
  char data[32];
};
CA *ca = new CA;  // No problem now

Of course, if you really _want_ a pointer to an array, you can always cast
the pointer returned from "new" to the right type.

Steve Adamczyk

I was trying to declare a type that held 32 characters, so I naturally:
  typedef char CA[32];

Later on, I had a pointer that I wanted to instantiate memory for:
  CA* ca = new CA;

And my compiler complained that a value of type "char *" could not
initialize an entity of type "CA *". I looked in the DWP, and lo and behold,
new isn't supposed to accept typedef-names (so the compiler seems to be
right). Is this an oversight, or is there a reason I don't know about that
stops me from trying to allocate a block of data this way?

Thanks,
eddy
--
ed.dy \'ed-e-\ n [ME (Sc dial.) ydy, prob. fr. ON itha; akin to OHG ith-
   again], L et and 1a: a current of water or air running contrary to the main
   current; esp)X : a small whirlpool 1b: a substance moving similarly  2: a
   contrary or circular current  - eddy vb