> Headerfiles may be protected with
>
>#ifdef __cplusplus
>extern "C" {
>#endif
Good idea, indeed. It will help us to solve the C/C++ naming convention
issue and thus to avoid the "_name@@decoration" unresolved external error.
I wonder at whether we should do
$su Dan
#
and protect the headers in
[EMAIL PROTECTED]:
# I further don't know if its is a good idea to hide the pointer
# character of a type in the typedef, like in
#
# typedef struct Parrot_Interp *Parrot_Interp;
Parrot_Interp (the typedef) is intended to be used only in
embedding/extending code. There, I've dictated (with my no
"Vladimir Lipskiy" <[EMAIL PROTECTED]> writes:
> d:\build\parrot\include\parrot\interpreter.h(40) : error C2040:
> 'Parrot_Interp' : 'struct Parrot_Interp *' differs in levels of indirection
> from 'struct Parrot_Interp'
>
> My compiler doesn't like the following:
>
> typedef struct Parrot_Inter
Vladimir Lipskiy <[EMAIL PROTECTED]> wrote:
> My compiler doesn't like the following:
> typedef struct Parrot_Interp *Parrot_Interp;
Weh sould do something like:
s/struct Parrot_Interp\s*\*/Parrot_Interp/g
at feature-freeze time before the upcoming release, when no big patches
should b
