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. :)
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. 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!
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.
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. In think with more recentl compiler technology this may be less of an issue that it once was.
RTTI shouldn't be necessary, as the driver should safely cast a base class pointer into a inherited class, e.g., the Radeon driver can be sure that a pointer to a Generic::VertexFormat, is indeed a pointer to a Radeon::VertexFormat, because that's the only kind of vertex formats it deals.
Exception could be useful to gracefully exit when things go wrong, but it's the last of our worries, as important is to avoid that things go wrong in the first place.
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.
One nice thing about OS X' IOKit is the way the kernel exposes APIs for user space access to the hardware. I have used this to write a firewire driver without the use of any kernel code, and also to write an application that queries for a bunch of information about the attached disk drives.
I hate to say it, but OS X does this by using Microsoft COM. What you do is supply a globally unique identifier and then it hands you back an interface that has a bunch of methods defined in it to do what you want. It's possible to have different versions of the interface for a given kind of device, for example new features are added to the firewire interface as OS X is updated.
OS X is nice to program. However, someone mentioned speed. I am not at all impressed by the speed of Mac OS X. Note that OS X is compiled with gcc.
I believe that with extensive use of inline functions, the C++ overhead on a DRI driver will disappear and be even faster in a few cases, because it will allow a level of costumization to each particular hardware which nowadays simply isn't possible without changing a lot of code.
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.).
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]
------------------------------------------------------- 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
