Jens, On Tue, Mar 04, 2003 at 10:09:41AM -0700, Jens Owen wrote: > Jose, > > I've been on the road for the last few days, so I haven't had a chance > to express my concern for porting the DRI to C++. Please take these > concerns with a grain of salt as I am definitely in the old fuddy duddy > class (as Keith calls it) in that I'm not fluent in C++.
:) OK, below I try to address your concerns. Note that for some the things you mention, until the framework is actually written, I can't give more than a mere guess. > Concern #1: Acceptance into XFree86, etc. Creating dependencies on > C++ compilers could be a big issue for some of the major projects that > utilize our code. I'm not really concerned about general acceptance right now (in XFree or elsewhere). I have a almost nothing to show, so if I asked now for a decision to be made in that sense, I know that answers would be made based on the individual experience with the C++ language rather than the actual merits of what I'm trying to accomplish. Once the work is done (i.e., with at least one full driver written upon it, and fragments of the current drivers to show how things compare) I'll let the work speak for itself. C++ compilers nowadays are widely available, and g++ can satisfy such dependency in all platforms we support. The only projects I know that are using the 3D drivers source code is XFree86 (already discussed above) and embedded Mesa. Regarding embedded Mesa, it's difficult to predict how big will be the impact of using a C++ compiler on the driver footprint. Note that the Mesa (which, if I'm not mistaken, is usually bigger than the actual driver) won't be reimplemented in C++, and the compiled C++ code size can change substantially with certain C++ compiler options (such as the optimization, and function inlining). I didn't mentioned IHVs because the existence of the C++ framework won't reduce their ability to write their own proprietary C drivers. In fact, no existing driver will be reimplemented unless their maintainers feel there is a notorious advantage. It will be though a good opportunity to bring old/deprecated/unfinished drivers (such as the 3DFX, SIS, S3virge) to recent standards. > Concern #2: As a driver writer, I prefer looking at C and thinking > in terms of the machine transactions that are likely to take place based > on that code. C++ code tends to hide that level of detail for me and I > don't feel like I've got a strong grip on the various machine > transactions when using it. This is true, but not necessarily a bad thing. C++ can take care of several things for the developer. Things such as an inheritance, which are currently manually done with a data structure with private data pointer + a method table, are done automatically by the C++ compiler, and the implementation used by most C compilers has little differences of what is currently done. There are things in C++, like when temporary objects are used, which can unsuspectingly translate into several calls to constructors and destructors. This is inefficient so it will be avoided, if not eliminated completely. All objects will be dynamically allocated, so their exact lifespan is determined by the 'new' and 'delete' operators. This is no different of what is done now, by 'malloc'ing and 'free'ing the structures. So although there surely are cases which were not contemplated here and that may give us a few surprises, my guess is that they should be very rare, and that the compiled C++ code should usually be fairly predictable. > Concern #3: Readability by the active contributors. I'm not the > only old fuddy duddy in this group of developers. How much > "readability" time do you figure the young C++ whipper snappers will > save by investing in this transition to C++? First, I must say I hope that the C++ framework won't just improve "readability". It should also reduce the required lines of code to write a driver (by absorbing the code common to the drivers into the framework), and therefore improve the "maintainability". This is something which should interest all developers (active or future). For a new developer, the adaptation to C++ is not comparable to all the things he needs to grasp, like OpenGL, XFree86, and the kernel. I'm sure they'll love it if it reduces the initial learning step curve to write a driver. The people who will be less keen on investing in a transition to C++, are indeed the "old fuddy duddy" which are more experienced in low-level C programming. Once the object hierarchy is established, the level of C++ knowledge required is reasonably low. To actually make architectural changes on the framework will still require a good understanding of the language, but tasks such as write/port/maintain a driver should be possible simply by "imitation" and "fill-in-the-blanks" kind of procedures. Note that I'm not claiming that from now on anybody can write a driver - just saying that it won't be necessary more C++ expertise than what an experienced C programmer already has, or can obtain in a heartbeat. Note that for all my answers to your concerns was implicit the assumption that this C++ driver framework will meet all these expectations. I have no guarantee of that, but I truly believe all this is within reach and that it will be good for everybody or, at least, a better alternative for some. I'm determined to do my best at this, and that's my main focus now. I leave the acceptance and the evaluation issues to the only people who can actually do it - all you DRI developers. > Thanks for your consideration of these issues and thanks for all your > excellent contributions to the DRI project. You're welcome. It's my pleasure to give back a little of the so much I've received. 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
