[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: usage of reserved C++-keyword in cthreads.h



Ulrich Eckhardt <doomster@knuut.de> writes:

> Summary of problems:
> A) In some inlined functions, pointers where cast to void* before being 
> assigned to a somestruct*. I wonder why the cast to void*? I admit that I 
> didn't check what exact type they where before, but doesn't it work just the 
> same and is clearer to directly cast them to somestruct* ?
>  C++ refuses implicit type-conversions that are not safe and this doesn't 
> compile therefore.

The C++ meaning of 'void' and the C meaning of 'void' are not
compatible with each other.

I'm not sure exactly which casts you are talking about here; I might
be able to comment if you could give a more specific citation.

> B) There was one case (in cthreads.h) where 'catch' was used as identifier, 
> additionally, there where quite some cases where 'class' was used (in 
> ports.h).

Right--legal C identifiers

> C) While not important for using the headers, I found local
> functions in some C-files. In fact I first triple-checked that that
> was really the case, because I thought that local functions where
> forbidden in C as in C++.  Can someone clarify me if that is rather
> new and standard C?

It's a new feature in GCC that is extensively used in Hurd and
Hurd-related libc code.

> D) trivfs uses some hook-function-pointers that the user can set to
> their own functions. I have been trying for an hour or so to get the
> right syntax for one of those but failed. I still don't understand
> the error-messages g++ gave me if necessary, I will provide more
> facts later, I don't have the GNU/Hurd grazing on my LAN currently.

Can you give a specific example?  I can't help you with what C++
syntax is supposed to match, but I can certainly explain the C
declarations.

I certainly would not assume that C++ has not changed the meaning of
some more complicated function declarators too.

> E) There where some casts from int to an enumeration. Again, C++ requires 
> those to be done explicitly.

Not a bug in C.

> To be honest, I underestimated the amount of changes it takes to 
> postincrement the C-headers. Maybe the proposal from Kimmo K. I. Surakka 
> might be a better start. However, as he already said, this doesn't solve 
> implicit conversions of void* or enum. 
>  Pondering over that, I just started to wonder if one couldn't #pragma the 
> compiler to do what one wants, any gcc-expert here ?

Ah, well, a useful feature might be a syntax for C++ that said "the
following code is C code, not C++ code" and did the right thing
pervasively.  But that feature does not exist.

I think you can now see why merely removing "class" from ports.h and
"catch" from cthreads.h is not the only change you'd be requesting.
Making the headers work with C++ might even be a pervasive and ongoing
maintenance hassle.  

Thomas



Reply to: