On Wed, Mar 05, 2003 at 09:31:09AM -0800, Linus Torvalds wrote: > > On Wed, 5 Mar 2003, Nicholas Leippe wrote: > > > > I agree with Jose--let the features used be chosen on technical > > merit, not just somebody's whim. Imo, it is far too premature to > > just discard this or that feature of C++. > > If people decide to go with C++ (which I don't disagree with per se), > please keep in mind that most people will use gcc for XFree86, and > worry more about specific gcc issues and performance than about > abstract issues.
I know that some C++ features have impact on performance. Exceptions as you mention below, is mostly an consensual one. Other aren't that consensual. And arguments in the line of "Embedded C++ or Java doesn't support it" don't move me much. Both the Embedded C++ and Java were designed with philosophies which have nothing to do with the OpenGL driver reality (the EC++ rationale clearly states they wanted a specification as small as possible). More importantly, as you said above, gcc will be used, and _not_ an EC++ or java compiler. > Also, keep in mind that at both an upper _and_ a lower level you will > end up having to integrate with C anyway. > > In particular, avoid overly virtual code (horrible performance if you > have dynamic casts etc) and exceptions (bad code generation, and a > fundamental inability to work with high-performance C code). Actually virtual code will be used extensively, especially in the Mesa wrapper classes, but there is no other way around it - the current Mesa C driver callback table has more than 112 functions. On the other hand, there won't be need of dynamic casts: the driver derived classes are expected to work only with other derived classes from the same driver, i.e., a Radeon::VertexFormat member function can be sure that a Mesa::Context* is actually a Radeon::Context*. This means that drivers should never derive classes from another driver, but always from the the Generic driver. If any piece of code in a driver is useful for others drivers, then it should be put on the Generic driver to be derived by all interested drivers. > But templates are potentially a great idea, since that is something > that is easily very ugly in C (realize that the DRM(xxx)() thing with > type defines etc for the kernel is nothign but a C template > implementation. It's certainly not very readable, but it's better > than the alternatives, and C++ is not an option in most kernels). > > Also note that if you don't allow exceptions (which I would _strongly_ > encourage), you can't really use "new" - unless you think it's ok to > SIGSEGV under low-mem circumstances. Which it might be, of course, in > some situations. Thanks for pointing that out. I've made a search on Goggle and found this article, http://www.palmoswerks.com/stories/storyReader$15 , which proposes a very clean solution - reimplement the default 'new' and 'delete' operators to not throw any exceptions. José Fonseca __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
