> 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 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?
