Re: [Dri-devel] C++ Framework Concern

[Nicholas L. <ni...@by...>]

On Wednesday 05 March 2003 10:54 am, Felix Kühling wrote:
> 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++.

Yes, there might be ABI issues, but doesn't the DRI already worry about 
binary compatibility issues?
Also, you can avoid linking with libstdc++ by invoking gcc as gcc rather than 
g++.  This is what MySQL does.  But then, iirc, you have to explicitly 
implement a new method for every class which becomes really tedious and error 
prone.  There are probably other facilities missing then as well.
I don't see how this would really be an issue to concern about.  Each distro 
is going to produce their own packages anyways, which they already have to 
build with the compiler they shipped with.

[snip]

> I agree, mostly. But to me it doesn't feel right to use the STL in a
> driver. But maybe that's just supersticion.

Why does it not feel right?  It's just type-safe code reuse.  The question as 
I see it is who would you rather have handle the code bloat--the compiler or 
the coder.  You either only write the template once and reuse it for 
different types letting the compiler generate the differences, or the 
developer himself must rewrite the same or similar code for each different 
type and maintain all of it.

And in the case of the STL, if the problem has already been solved, coded, 
and debugged, then why not use it?  It is extremely flexible and 
customizeable.  I'm not saying that the STL necessarily has solutions for any 
of the problems that will be encountered in this framework.  If it doesn't 
then that's the way it is.  If it does, then unless there's some 
unsurmountable or really practical reason not to, why reinvent the wheel?


Nick