Zack Weinberg <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis <[EMAIL PROTECTED]> writes: | | [...] | > The cast you're talking about is buried deep in XNEWVEC, XRESIZEVEC | > and such. It is not anything you'll find in the code directly. So, | > in fact we do not lose readability as you claim. | | To be honest, I think XNEW* are less readable than bare xmalloc, and I | regret that I ever invented them.
Then, we would have just agree to disagree. At least, with the explicit call to malloc + explicit specification of sizeof, I've found a number of wrong codes -- while replacing the existing xmalloc/xcallo with XNEWVEC and friends (see previous patches and messages) in libiberty, not counting the happy confusion about xcalloc() in the current GCC codes. Those are bugs we do not have with the XNEWVEC and friends. Not only, we do get readable code, we also get right codes. | > The patches of aligning us to the common subsets of C90 and C++ is | > following the consensus we developed as our coding standards. | | I don't see that there is any such consensus. I certainly consider http://www.gnu.org/software/gcc/codingconventions.html Avoid the use of identifiers or idioms that would prevent code compiling with a C++ compiler. Identifiers such as new or class, that are reserved words in C++, should not be used as variables or field names. Explicit casts should be used to convert between void* and other pointer types. Previous discussions reached this: http://gcc.gnu.org/ml/gcc/2004-07/msg00601.html | coding to the intersection of C90 and C++ acceptable only as a | stepping stone to coding in C++. If converting GCC to C++ is your ultimate goal, then I don't think you should block these patches. They do not introduce C++, but also they do provide a path to local experiments before we ever have any huge fight about that. I do not think converting GCC to C++ is on the table or will happen any time soon -- see previous long discussions. However, I do not believe it would help the GCC project to block any patch that bring us in alignment to our own committment. We can have our cake and it. I.e. we can have the source code in a form compilable with a C++ compiler and test conjectures/experiments. | If we aren't going to do that, and | in short order, we have sacrificed the additional expressiveness of | C-that-is-not-C++ for no gain. I don't think so. These patches make it possible to compile the source code with a C++ compiler. We gain better checking by doing that. In particular, it makes it possible for people to test any conjecture about the benefits of moving to C++, without actually requiring it at the moment. Those benefits largely offset the inconvenient of using XNEWVEC (with all its benefits). I was able to find those problems because I could get the source code through a C++ compiler. Making that possible to everyone, including those who do no like to use C++ in GCC is a win for everybody. | I was unclear in my previous message: it seems that you have found a | number of things, by your experiment, that are not just code outside | the intersection, but outright bugs. Exactly. I was able to find those because I spent the time to convert the souorce to be compilable to C++. I do not believe it makes to require everybody to wste such time locally, whereas it could be done one for all. | The bugs should of course be | fixed. Things that I consider outright bugs include: functions being | called with prototypes in scope that don't match their definitions; | use of numeric constants in interfaces when enumeration constants are | defined for those interfaces; 'typedef struct foo *foo'. | | Things I consider correct coding, but outside the intersection of C90 | and C++, include: not casting the return value of allocator functions; | not casting to void* when passing an arbitrary pointer to a function | that takes a void* parameter; unrestricted use of C++ keywords; | declaring structure fields with the same name as a structure tag in | scope. These do not being us any benefits as far as checking is concerned. The point of being able to do so and therefore prevent ourselves from having freely avaliable tools to catch errors completely escape my understanding. | > | I want to see more use of this idiom, not less; for | > | example, 'enum machine_mode' ought to be a black box to almost the | > | entire compiler. | > | > Me too, but the way to make it a black box is not to cast it so | > unsigned int back forth willy nilly -- that does not make it a black | > box, on the contrary. For example, we should be using EXPAND_NORMAL | > instead of plain "0". | > | > | I'd be delighted to hear of a more C++-friendly way to | > | code this. | > | > See above. | | This isn't an answer to the question I asked. I asked for a more C++ | friendly way to code *black box* use of enums, where (in C) one is | deliberately relying on the unchecked conversion to and from integral | types. The point was that an enum by itself is a black box. There is no foward declaration of enums. There is no need here for an abstraction for an abstraction. The named constants stand by themselves are abstraction layer over the values they represent. -- Gaby
