From: Linus T. <tor...@tr...> - 2003-03-05 19:56:25
|
On Wed, 5 Mar 2003, [iso-8859-15] Jos=E9 Fonseca wrote: >=20 > 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. Oh, I agree that you should not avoid virtualization - when the overhead=20 is just a function pointer. It's things like dynamic casts etc that you=20 should avoid like the plague. > 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 th= e > 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. Yes. > > 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. >=20 > 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. I'd almost go with the "std::nothrow" approach even if it's syntactically a bit more awkward (maybe that can be fixed with a macro). It's not entirely unlikely that the compiler may have special case support for its internal "new" implementation. Some gcc person might be able to tell you. Linus |