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. > 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 coding to the intersection of C90 and C++ acceptable only as a stepping stone to coding in C++. 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 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. 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. > | 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. > I'm talking of the various gt_* objects created by the gengtype. > Please, do have a look at the actual contents of the file and > re-read what I wrote. I haven't time; please post a reduced example and explain why my suggestion won't work. zw