On Wed, 5 Mar 2003 11:54:56 -0700 Nicholas Leippe <[EMAIL PROTECTED]> wrote:
> 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? If you're referring to the libxaa and xserver problems with the binary snapshots, that's a completely different story as Xserver, libxaa and DRI belong together. So it's no problem to include a new xserver and libxaa in the snapshot or offer it for download separately. You can't do that with STL. > 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. Yes, but you still have the problem with binary snapshots. Another way would be to link the driver statically. If you use only a small subset of the standard library the footprint should not be to dramatic. The template instances will be in the drivers anyway, no matter whether you link statically or dynamically. > > [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. The developer may as well implement his own container types as templates. My point is that STL seems quite bloated and often a bit clumsy to use. The code I wrote using STL was never exactly well readable (maybe my own fault). It is a great abstraction, and if you need more advanced container types and don't *want* to worry about allocation issues, than it's a great tool. But for the purpose of a driver I'd prefer implementing a linked list as a linked list myself. > > 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? 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
