MSVC++ complaints
Vladimir Lipskiy
'Parrot_Interp' : 'struct Parrot_Interp *' differs in levels of indirection
from 'struct Parrot_Interp'
My compiler doesn't like the following:
typedef struct Parrot_Interp *Parrot_Interp;
in interpreter.h. It's a blame practice just as like
#define struct_val ptrs.struct_val
and I have no idea how to fix that problem 'cause the source and
the headers are overflooded with the both struct Parrot_Interp *
and its synonim Parrot_Interp
Further:
d:\build\parrot\include\parrot\datatypes.h(120) : error C2899: typename
cannot be used outside a template declaration
Here is what in datatypes.h causes that error:
INTVAL Parrot_get_datatype_enum(Interp * interpreter, STRING *typename);
typename is a keyword in C++. This declaration
INTVAL Parrot_get_datatype_enum(struct Parrot_Interp *, STRING *);
would be okay.
Leopold Toetsch
> 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 be floating around.
For consistency the "Interp *" should also be changed.
> typename is a keyword in C++. This declaration
> INTVAL Parrot_get_datatype_enum(struct Parrot_Interp *, STRING *);
Done.
Thanks for your bug reports.
leo
Juergen Boemmels
> 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_Interp *Parrot_Interp;
This is valid ANSI C. structs and types live in seperate
namespaces. Problem is if the compiler thinks for whatever reason it
is compiling C++. Then sturct, class and typedef are all in one
namespace. Headerfiles may be protected with
#ifdef __cplusplus
extern "C" {
#endif
or the equivalent __BEGIN_DECLS.
io.h uses the convention to prepend every struct with a _ like
typedef struct _ParrotIO ParrotIO;
(This convention wasn't introduced by me)
If we decide to use this as general convention we should document this
in PDD07.
The current PDD07 says that structs should start with a lower case
letter and typedefs should start with an upper case letter. This seems
not to be followed consequently as a little grepping through the tree
shows:
2037 lines use struct Upperletter (762 lines in header files)
454 lines use struct lowerletter (29 lines in header files)
98 lines use struct _underscore (16 lines in header files)
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;
or if we just introduce an alias for the struct like in
typedef struct pobj_t { ... } pobj_t;
Anyway it should be consistent through the code. (And documented in
PDD07). These are some really big patches colliding with much other
outstanding patches.
[...]
> INTVAL Parrot_get_datatype_enum(Interp * interpreter, STRING *typename);
>
> typename is a keyword in C++. This declaration
>
> INTVAL Parrot_get_datatype_enum(struct Parrot_Interp *, STRING *);
from PDD07:
: Variable names should be included for all function parameters in the
: function declarations. These names should match the parameters in the
: function definition.
bye
boe
--
Juergen Boemmels boem...@physik.uni-kl.de
Fachbereich Physik Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F 23 F6 C7 2F 85 93 DD 47
Brent Dax
# 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 non-existent
power :^) ) that pointer types are hidden, because the underlying
structs are left undefined anyway.
I do agree that typedef Parrot_Interp should not be used in Parrot's
internals. Perhaps we should just use Interp * instead.
--Brent Dax <br...@brentdax.com>
Perl and Parrot hacker
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."
Vladimir Lipskiy
>
>#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 the include directory without
waiting for Dan's "go for it" or we should be patient and
wait until it comes. Or even to start after Parrot 0.1.0
has been released?
But still extern "C" can't protect the "typedef struct a *a" declaration,
the error doesn't go away neither with MSVC nor with gcc
### test.cpp ###
extern "C" {
struct a;
typedef struct a *a;
}
int main()
{
}
### eof ###
while compiling test.cpp with MSVC++ 6.0:
d:\build\test\test\test.cpp(3) : error C2040: 'a' : 'struct a *' differs
in levels of indirection from 'struct a'
with gcc:
test.cc:3: conflicting types for `typedef struct a *a'
test.cc:2: previous declaration as `struct a'
AFAIK, it ought not protect such a declaration. That linkage
specification doesn't manage name spaces but calling conventions:
--- Stolen from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm
/tions_30.asp
Linkage Specifications
The term linkage specification refers to the protocol for linking functions
(or procedures) written in different languages. The following calling
conventions are affected:
Case sensitivity of names.
Decoration of names. In C, the compiler prefixes names with an underscore.
This is often called decoration. In C++, name decoration is used to retain
type information through the linkage phase.
Order in which arguments are expected on the stack.
Responsibility for adjusting the stack on function return. Either the called
function or the calling function is responsible.
Passing of hidden arguments (whether any hidden arguments are passed).
---
>io.h uses the convention to prepend every struct with a _ like
>typedef struct _ParrotIO ParrotIO;
>(This convention wasn't introduced by me)
>If we decide to use this as general convention we should document this
>in PDD07.
Yeah, along with documenting the obligatory protecting header declarations
with
#ifdef __cplusplus
extern "C" {
#endif
It would be quite good if we had documented some instructions on
the "if defined/undefined vs 0/1" issue in PDD7 also.
>The current PDD07 says that structs should start with a lower case
>letter and typedefs should start with an upper case letter. This seems
>not to be followed consequently as a little grepping through the tree
>shows:
>2037 lines use struct Upperletter (762 lines in header files)
>454 lines use struct lowerletter (29 lines in header files)
>98 lines use struct _underscore (16 lines in header files)
I'm for the style which you use in io.h, that is I'm for the latter
on that list.
>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;
It woudn't be a good idea even if we had wanted to hide that
character since we can't protect those declarations
>or if we just introduce an alias for the struct like in
>
>typedef struct pobj_t { ... } pobj_t;
MSVC has nothing against aliases, though struct declarations in C++
introduces a full-fledged type as opposite to C struct declarations
which only bring in tags. I'm still for the underscore prefixing of
struct names.
>Anyway it should be consistent through the code. (And documented in
>PDD07).
Agree.
>: Variable names should be included for all function parameters in the
>: function declarations. These names should match the parameters in the
>: function definition.
It's okay if one can guarantee, s?he won't ever use keywords of both
C and C++ as names of parametres. Can we?