Mark Mitchell <[EMAIL PROTECTED]> writes: ... > Like you, I do think these problems are surmountable; but, also like > you, I think it would take some time to get all the problems solved. > I don't really think, though, that this is immediately relevant; > Gaby's trying to fix things that seem to me like they will actually > make for better C code, and, right now at least, going to C++ isn't on > the table. I think you agree that most of the changes Gaby wants to > make are for the better (with the possible exception of casting the > return value of malloc, which will be hidden in a macro that's > probably less error-prone that writing out the malloc calls directly) > -- but you're concerned about the fact that doing this work now might > make it too easy for us to switch to C++ without thinking about all > the issues?
Yes, that's what I'm trying to get at. Secondarily, I don't want to lose some of the expressive power of C-that-is-not-C++ if we're not getting the expressive power of C++ in exchange -- for instance, I really don't want to have to avoid the set of C++ keywords when coding in C, or remember the semantic difference between C and C++ struct tags. I'd change my tune if Gaby could demonstrate a place where the C++ compiler caught a user-visible bug that the C compiler missed. That would be worth the extra discipline. All the bugs described so far, however, have been things that, while formally incorrect, haven't affected the visible behavior of the compiler. (And I'd be less grumpy about coding to the intersection of C and C++ if someone coded up warnings for the C compiler to catch things outside the intersection.) zw
