On Thu, Feb 27, 2003 at 03:47:14PM -0800, Ian Romanick wrote: > José Fonseca wrote: > > > >On Thu, Feb 27, 2003 at 09:24:22AM -0500, Michael D. Crawford wrote: > > > >>You also don't really get to use constructors, you only have the > >>default constructor and then you call a regular function to do the > >>real initialization, so it can return an error code instead of > >>throwing an exception as a nontrivial constructor might have to > >>sometimes. > > This is a usual way to do things when using exceptions is not an > option. Device drivers tend to fall into this category. :)
I see. This technique might be useful in a few places then. > >>Here's EC++' homepage: http://www.caravan.net/ec2plus/ > >> > >>Here's what Bjarne Stroustrup has to say about EC++, I heartily > >>agree with him: > >> > >>http://www.research.att.com/~bs/bs_faq.html#EC++ > > > >I didn't knew about EC++. I've read its rationale, and basically they > >dismiss alot of C++ just because it's "usually not needed for an > >embeded application", instead of analyzing the potential > >benefits/counterfits. Overall I don't think embedded C++ is suited > >for a DRI 3D driver. > > > >Templates is something really useful for DRI drivers, as we want > >specialized version of several functions. For embedded applications, > >we can either just rely on the card capabilities, or replace the > >templates by a single generic version of that template which will be > >slower, but with a smaller memory footprint. > > I was actually going to read your document and bring up EC++, but I > haven't had a chance to read the doc yet and someone beat me to it. [Before you get disappointed let me warn you that my document is just a bunch of generated Doxygen HTML from incomplete classes with my comments on it - it's in no way comparable to the elaborate proposal documents that you and Felix showed in this lists...] > The rationalle behind EC++, and the reason it would be good for DRI, > is two fold. One reason is that a lot of "advanced" features are not > universally supported correctly. One example is templates. The > template implementation in GCC 2.9x is crap. The second reason is to > keep code size reasonable. Templates may be very useful, but I don't > think people will be any too happy to have a 5+ MB OpenGL driver! Note that templates _are_ already being used in the current drivers - it's a way to achieve a optimized versions of certain functions to a specific OpenGL state (texturing, no texturing, (no) multitexturing, etc...). They are achivied by defining a set of variables (the tamplate parameters), and include a header file (the template) over and over. As you can guess this is not very flexible and quite error prone. How much sucky the template implementation is, is very difficult that it generates worst code. > >Namespaces is really helpful: instead of adding > >{radeon_,Radeon,RADEON_}* prefix to the names, we can just use a > >Radeon namespace. > > Actually, everything that would be device specific stuff should be > encapsulated within device specific classes. The exception would > perhaps be #defines. I don't understand that you mean with this. > >Multiple inheritance and virtual inheritance is, IMHO, essential to > >design reusable objects for the drivers. Without this and no > >templates, there wouldn't be much difference between were we stand > >now. > > The reason pure-virtual methods were removed is because the compiler > has to emit code to check for NULL method pointers. I tend to agree > with this rationalle. It's also easilly worked around in a way that > doesn't require build-in compiler NULL-pointer checking. Could you provide some pointer to examples of this? I'm also gonna see if there is more info in EC++ site. > In think with more recentl compiler technology this may be less of an > issue that it once was. > > I think using exceptions would be totally out of the question. > There's quite a bit of OS-level support required for exceptions. > Regardless, it seems like a bad idea for a device driver. Ok. > One of the "classic" performance complaints about C++ is all the > indirection (i.e., virtual function calls). The existing DRI > framework already does all that. > > All of that said, I think using classes is a good idea. I haven't > looked at your documentation yet, but a good starting point would be a > class for hardware context (i.e., 'struct radeon_context', 'struct > r200_context', etc.). When you take a look to the HTML documentation will see that my approach is very different. - the context abstraction wasn't address because it . I payed more attention to the I confess that in OOP I tend more to the abstraction/inheritance paradigm, but I'm going to study a little more about EC++ way. Still, to choose a C++ subset, it's not only enough to be _able_ to the things - it has to be just as easy too. If one has to fight the system then there is no point to change IMO. > I do wonder if it is "allowed" for a core X component to use C++. I'm > not even sure exactly who we'd ask. Perhaps this question is better > for [EMAIL PROTECTED] I think is very soon to ask. But when the time comes, I hope that the decision to incorporate this framework in X is more than just a language choice. I hope make this useful enough to make that decision easy. At any rate the DRI architecture was designed in such way that even proprietary drivers are viable, so this framework can be kept seperate as long as it takes. 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:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
