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; */
#
# 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 think you misunderstand what I'm arguing for. I'm arguing for this:
struct parrot_foo_t;
typedef struct parrot_foo_t * Parrot_Foo; /* pointer to */
#ifdef PARROT_IN_CORE
typedef struct parrot_foo_t FOO; /* not pointer to--like STRING in the
core */
/* insert definition of parrot_foo_t here */
#endif
That's it. No Parrot_Foo_ptr type. The pointer-to distinction only
applies to types like strings where you generally pass around a pointer
to the struct, rather than the struct itself.
--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
