embed.h doesn't work in C++
Nicholas Clark
In file included from /Users/nick/Ponie/ponie06/parrot/include/parrot/embed.h:19,
from perl.h:31,
from miniperlmain.c:27:
/Users/nick/Ponie/ponie06/parrot/include/parrot/interpreter.h:59: error: conflicting
types for `typedef struct Parrot_Interp*Parrot_Interp'
Pain being due to these two:
struct Parrot_Interp;
typedef struct Parrot_Interp *Parrot_Interp;
This doesn't seem right.
Nicholas Clark
Brent 'Dax' Royal-Gordon
> Pain being due to these two:
>
> struct Parrot_Interp;
>
> typedef struct Parrot_Interp *Parrot_Interp;
>
>
> This doesn't seem right.
It is and it isn't. The naming conventions say that struct
Parrot_Interp should really be struct parrot_interp_t, but that's a
ginormous global change. I've tried to implement it once or twice, but
my most recent attempt cause mysterious compile errors.
You're welcome to try it again, though...while you're at it, you might
as well make all internal Parrot functions take an Interp * instead of a
struct Parrot_Interp *. That ought to save us a couple kilobytes.
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Brent 'Dax' Royal-Gordon
>>It is and it isn't. The naming conventions say that struct
>>Parrot_Interp should really be struct parrot_interp_t, but that's a
>>ginormous global change. I've tried to implement it once or twice, but
>>my most recent attempt cause mysterious compile errors.
>
> make realclean && perl ./Configure.pl && make && make fulltest
> passed without errors or additional warnings. (i686; SuSE Linux 9.0)
Wow. Excellent.
>>You're welcome to try it again, though...while you're at it, you might
>>as well make all internal Parrot functions take an Interp * instead of a
>>struct Parrot_Interp *. That ought to save us a couple kilobytes.
>
> What files are "internal"? I can change this, too.
I believe that any function that takes 'struct Parrot_Interp *'
currently should really be taking 'Interp *'. Any function that takes
the 'Parrot_Interp' typedef should be left alone.
Leopold Toetsch
>
> I've prepared a patch for it.
Why do you change all to the longest declaration of Parrot_Interp?
We have in decreasing length
struct parrot_interp_t *
struct Parrot_Interp *
Parrot_Interp
Interp *
We need the structure declaration which could be 1) or 2) and we want a
short typedef for it. So let's use the latter, which doesn't hide that
its a pointer (albeit I used to use Parrot_Interp).
Of course 2 or 3 have to be tossed. (I'd toss 1 and 3 and use 4 in the tree)
Anyway, whatever is choosen, please apply it, I'd rather not do that on
my limited dialup line.
> jens
leo
Jens Rieks
Leopold Toetsch wrote:
> Jens Rieks wrote:
> > I've prepared a patch for it.
>
> Why do you change all to the longest declaration of Parrot_Interp?
because Brent 'Dax' Royal-Gordon wrote:
: The naming conventions say that struct
: Parrot_Interp should really be struct parrot_interp_t, but that's a
: ginormous global change.
> We have in decreasing length
>
> struct parrot_interp_t *
> struct Parrot_Interp *
> Parrot_Interp
> Interp *
>
> We need the structure declaration which could be 1) or 2) and we want a
> short typedef for it. So let's use the latter, which doesn't hide that
> its a pointer (albeit I used to use Parrot_Interp).
> Of course 2 or 3 have to be tossed. (I'd toss 1 and 3 and use 4 in the
> tree)
Okay. I'll use the current CVS version and then change every
"struct parrot_interp_t *" and "struct Parrot_Interp *" into "Interp *",
right?
> Anyway, whatever is choosen, please apply it, I'd rather not do that on
> my limited dialup line.
Okay, no problem. I have a fast internet connection.
> leo
jens
Jarkko Hietaniemi
>>>as well make all internal Parrot functions take an Interp * instead of a
I hope there's #undef Interp in there somewhere. Or maybe even possibly
#ifdef Interp
#error EEEK SOMEONE ELSE HAS DEFINED Interp.
#endif
In other words, I'm not at all convinced about the wisdom of dropping
Parrot_ prefixes.
You laugh? ConvexOS had sv_flags in its system header files, which
was rather unfun for Perl 5. The shorter and more generic a name is,
the more likely a conflict is.
Dan Sugalski
>Hi,
>
>On Thursday 22 April 2004 17:59, Brent 'Dax' Royal-Gordon wrote:
>> Nicholas Clark wrote:
>> > Pain being due to these two:
>> >
>> > struct Parrot_Interp;
>> >
>> > typedef struct Parrot_Interp *Parrot_Interp;
>> >
>> >
>> > This doesn't seem right.
>>
>> It is and it isn't. The naming conventions say that struct
>> Parrot_Interp should really be struct parrot_interp_t, but that's a
>> ginormous global change. I've tried to implement it once or twice, but
>> my most recent attempt cause mysterious compile errors.
>passed without errors or additional warnings. (i686; SuSE Linux 9.0)
I just gave this a try, but it fails pretty massively. It looks like
it's against an interim version or something like that. Could you
regenerate this against a base cvs checkout?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Brent 'Dax' Royal-Gordon
> At 6:48 PM +0300 4/23/04, Jarkko Hietaniemi wrote:
>
>> >>>You're welcome to try it again, though...while you're at it, you
>> might
>>
>>>>> as well make all internal Parrot functions take an Interp * instead
>>>>> of a
>>
>>
>> I hope there's #undef Interp in there somewhere.
>
>
> I hope it's not in there in the first place. The prefix needs to stay.
The declaration has been (along the lines of)
typedef struct Parrot_Interp {
...
} Interp;
for years. The Interp typedef is intended for internal use only. Why
do we need the prefix on an internal-use only typedef? We don't use
Parrot_String or Parrot_PMC internally.
Outside of Parrot, it's still Parrot_Interp, the same as I wrote it way
back when I checked the embedding interface in.
Dan Sugalski
>Dan Sugalski wrote:
>
>>At 6:48 PM +0300 4/23/04, Jarkko Hietaniemi wrote:
>>
>>> >>>You're welcome to try it again, though...while you're at it, you might
>>>
>>>>>>as well make all internal Parrot functions take an Interp * instead of a
>>>
>>>
>>>I hope there's #undef Interp in there somewhere.
>>
>>
>>I hope it's not in there in the first place. The prefix needs to stay.
>
>The declaration has been (along the lines of)
>
> typedef struct Parrot_Interp {
> ...
> } Interp;
>
>for years. The Interp typedef is intended for internal use only.
>Why do we need the prefix on an internal-use only typedef? We don't
>use Parrot_String or Parrot_PMC internally.
Huh. I didn't think we were using that anywhere--I know I've been
using Parrot_Interp, but I'm often a bit behind.
Brent 'Dax' Royal-Gordon
> Jens Rieks wrote:
>
>>
>> I've prepared a patch for it.
>
>
> Why do you change all to the longest declaration of Parrot_Interp?
>
> We have in decreasing length
>
> struct parrot_interp_t *
> struct Parrot_Interp *
> Parrot_Interp
> Interp *
>
> We need the structure declaration which could be 1) or 2) and we want a
> short typedef for it. So let's use the latter, which doesn't hide that
> its a pointer (albeit I used to use Parrot_Interp).
> Of course 2 or 3 have to be tossed. (I'd toss 1 and 3 and use 4 in the
> tree)
The naming conventions call for parrot_interp_t to be used on the struct
instead of Parrot_Interp. The fact that almost the entire core *should*
be using Interp * is a separate issue--everyone's using the raw struct
for hysterical raisins. The struct was being used before the typedef
existed, and nobody's bothered to go back and change it.
Nonetheless, it's a separate issue that this is a good time to address.
Dan Sugalski
>>>>as well make all internal Parrot functions take an Interp * instead of a
>
>I hope there's #undef Interp in there somewhere.
I hope it's not in there in the first place. The prefix needs to stay.
Jarkko Hietaniemi
> Dan Sugalski wrote:
>
>>I hope it's not in there in the first place. The prefix needs to stay.
>
>
> The declaration has been (along the lines of)
>
> typedef struct Parrot_Interp {
> ...
> } Interp;
>
> for years. The Interp typedef is intended for internal use only. Why
> do we need the prefix on an internal-use only typedef? We don't use
> Parrot_String or Parrot_PMC internally.
This works as long as people (a) know of (b) stick to the policy
("Interp for internal use only") (c) No application embedding Parrot
has defined "Interp" themselves. Experience has shown that none of
these is likely to happen and/or stay that way for long :-)
> Outside of Parrot, it's still Parrot_Interp, the same as I wrote it way
> back when I checked the embedding interface in.
Something like
typedef struct Parrot_Interp_s {
...
} Parrot_Interp;
would be more robust, I think. (A typedef setup like that is pretty
common, the explicit "struct Parrot_Interp_s" is needed only if there
is a need for a struct point to structs of the same kind, as in linked
lists.)
--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Dan Sugalski
>Brent 'Dax' Royal-Gordon wrote:
>
>> Dan Sugalski wrote:
>>
>>>I hope it's not in there in the first place. The prefix needs to stay.
>>
>>
>> The declaration has been (along the lines of)
>>
>> typedef struct Parrot_Interp {
>> ...
>> } Interp;
>>
>> for years. The Interp typedef is intended for internal use only. Why
>> do we need the prefix on an internal-use only typedef? We don't use
>> Parrot_String or Parrot_PMC internally.
>
>This works as long as people (a) know of (b) stick to the policy
>("Interp for internal use only") (c) No application embedding Parrot
>has defined "Interp" themselves. Experience has shown that none of
>these is likely to happen and/or stay that way for long :-)
(c) is the reason for the separate embed.h file that doesn't actually
include any other parrot header files--that cuts down on our exposure
to other headers that parrot uses internally. I'm not naive enough to
think that makes us immune to problems, but at least it reduces our
exposure. :)
Jarkko Hietaniemi
>>("Interp for internal use only") (c) No application embedding Parrot
>>has defined "Interp" themselves. Experience has shown that none of
>>these is likely to happen and/or stay that way for long :-)
>
>
> (c) is the reason for the separate embed.h file that doesn't actually
> include any other parrot header files--that cuts down on our exposure
That sounds good. But I won't be surprised if in some platform even
that isn't enough :-)
Nicholas Clark
> You're welcome to try it again, though...while you're at it, you might
> as well make all internal Parrot functions take an Interp * instead of a
> struct Parrot_Interp *. That ought to save us a couple kilobytes.
Wibble.
I hacked perl's Configure instead. It felt like the less painful option.
Nicholas Clark