Richard Guenther wrote: > Oh - and we didn't yet decide to switch to C++ as implementation > language. Did we?
I'm not sure exactly what you're asking. We now have permission to switch. The reason we wanted permission to switch was that there was a consensus that we wanted to switch; as far as I know, we didn't want the permission just so that we could at some later point consider switching! I think we've decided to switch, but we haven't decided to what subset of C++ we're switching. I think that we want what might be called the "syntactic sugar" subset. For example, single inheritance to replace our C-style inheritance, constructors/destructors to replace explicit calls to required initialization/finalization functions, and member functions to implement ADTs, namespaces to save us some typing. None of these things impacts memory use, or run-time performance. Generally speaking, these are things that remove lines of code, help to prevent mistakes made by casting or forgetting to obey requirements of APIs, and make it easier to replace particular components without impacting large parts of the rest of the source code. The more "exotic" bits of C++ (RTTI, exceptions, virtual inheritance, templates, etc.) all involve the compiler doing a lot more implicit generation of data structures and code, including, in some cases, implicitly making data structures bigger. I think these techniques are valuable when used appropriately, but I wouldn't propose using them in GCC soon. It is easy to mis-use them and for them to have unintended consequences. I think virtual functions are on the edge; quite useful, but do result in the compiler adding a pointer to data objects and in uninlinable indirect calls at run-time. Therefore, I would avoid them in the initial subset of C++ used in GCC. (If we decide at some point, for example, that we want to be able to use multiple back-ends in a single compiler, then virtual functions are a good way of implementing that -- but we need to understand that there will be an indirection for every call to a back-end function. If that's too high a price to pay, then we won't want to do that. The point here is that "use virtual functions" should not be the goal; the goal should be "multiple back-ends" and then "use virtual functions" is just an implementation technique, with costs approximately equivalent to doing the same thing "by hand" in C.) I am certainly a "C++ guy", and I feel that all these features have their place, but I think we should err on the side of using less of C++, rather than more. We have C code that works, and we have a group of developers comfortable in C. We lose if we break our code, and even more if alienate those developers. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
