On Wed, 5 Mar 2003 10:24:12 -0700 Nicholas Leippe <[EMAIL PROTECTED]> wrote:
> 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? If you use the standard library you have to start worrying about ABI compatibility issues. How much trouble is it to write C++ code that can be linked without the standard library. I mean avoiding things like std::cout is no problem. But does C++ use the library behind your back? AFAIK g++ alway implicitly links with libstdc++. > > 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. I agree, mostly. But to me it doesn't feel right to use the STL in a driver. But maybe that's just supersticion. > > > Nick Regards, Felix ------------ __\|/__ ___ ___ ------------------------- Felix ___\_e -_/___/ __\___/ __\_____ You can do anything, Kühling (_____\Ä/____/ /_____/ /________) just not everything [EMAIL PROTECTED] \___/ \___/ U at the same time. ------------------------------------------------------- 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
