On Wednesday 05 March 2003 12:10 am, Ian Romanick wrote: > 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++. > > > > 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. > > This is probably the biggest issue. I think if we agree to use a > reasonable subset of C++, we should have a good chance. This is > probably something we should bring up on [EMAIL PROTECTED] sooner rather > than later. > > > 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. > > The hidden detail tends to come from three things: function / operator > overloading, inheritance, and templates. I don't think the first or > third items will particularly come into play. We may use C++ templates, > but not in the usual, generic programming sort of way. DRI already uses > a lot of inheritance in the C code, so I don't think that's a problem.
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++. Templates provide a great deal of power that you may not want to do without. For instance, you could use portions of the STL (always good to use the language's standard library since it's already debugged and optimized)--you could write your own customized allocators for it that handle the different mm mappings. This could allow greater compartmentalization--only a few would have to worry about _writing_ the allocators, the rest of the devs would only have to know which one to use when rather than understand all their icky details. Also, how many containers are you going to hand code before deciding that a generalized, reusable solution would save you all the trouble? Why discount operator and function overloading so quickly? The greater readability due to the expanded namespace alone can be nice. Combine that with namespaces and you have an even easier time at choosing a good, simple, descriptive name for each function. I understand there may be portions of C++ that you feel don't belong in the solution (exceptions, many of the things already mentioned above and previously on the list)--but many of these items may actually be integral to the optimal solution. In short, I don't see why everyone is so keen to accept C++ but only if it is somehow hobbled from the onset? C++ is a tool. Tools work best when the right one is chosen for the job, the tip is sharp, and the handle is not splintered or cut off. If the problem does not map into something C++ solves elegantly, then don't use it--but don't hobble it before, limiting how the tool will be allowed to solve it. Solve the problem with the tool and then look back and see what portions of the tool were and were not used, then if necessary, cut off what was not useful. I admit that I am probably closely aligned with Bjarne Stroustrup's philosophy as referenced earlier. Nick ------------------------------------------------------- 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
