Bryan C. Warnock:
# On Tuesday 26 February 2002 22:17, you wrote:
# > How is this the case? STRING ** and Parrot_String * are equivalent.
# > You can use & on both a STRING * and a Parrot_String to get
# a STRING**
# > (a.k.a. a Parrot_String *). I don't see where the problem is.
#
# Ah, except that you had a different typedef for both the
# type, and a pointer
# to that type.
#
# typedef FOO Parrot_Foo;
# typedef FOO * Parrot_Foo_ptr; /* or typedef Parrot_Foo *
# Parrot_Foo_ptr; */
No, I'm not. I am *not* proposing an _ptr typedef.
My original example was:
struct foo_t;
typedef struct foo_t * FooPtr;
typedef struct foo_t FOO;
It wasn't necessarily part of Parrot in this example, so I said FooPtr
instead of Parrot_Foo. Sorry if this confused you. Here's what I
meant:
struct parrot_foo_t;
typedef struct parrot_foo_t * Parrot_Foo;
typedef struct parrot_foo_t FOO;
For a concrete example of this sort of thing, I use the string system:
struct parrot_string_t;
typedef struct parrot_string_t * Parrot_String;
typedef struct parrot_string_t STRING;
# void func () {
# FOO gork;
# bar(&gork);
# }
#
# void bar ( /* What goes here? */ ) {
# }
#
# I'd argue for 'Parrot_Foo *'. Programmers know that when you
# pass in an
# address, expect a pointer on the other end. But with your
# typedef for the
# pointer thing, you're saying it should be 'Parrot_Foo_ptr' -
# do you expect
# the users to a) look that up?, and b) actually do that?
I agree. My only question is, should that be Parrot_Foo * or Parrot_Foo
**? I think Parrot_Foo *, since embedders and extenders should never
see a 'struct parrot_foo_t', because it's just a forward declaration to
them--the internals of those structures are internal to Parrot.
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking, regex hacker, embedding coder, and boy genius
#define private public
--Spotted in a C++ program just before a #include
