From kde-core-devel Mon Apr 28 15:00:10 2003 From: George Staikos Date: Mon, 28 Apr 2003 15:00:10 +0000 To: kde-core-devel Subject: Re: Reason for -no-stl in qt-copy configure recommendation? X-MARC-Message: https://marc.info/?l=kde-core-devel&m=105154218023294 On Monday 28 April 2003 04:55, Rolf Magnus wrote: > > > Can we change the recommendation -no-stl to -stl for HEAD/3.2 then, > > > please? > > > > I don't think this is a good idea. I foresee much more STL use as > > opposed to Qt use, for one. We'll be fragmenting our use of containers. > > If it's available to developers, I'm sure they'll use it instead. > > And that would be bad? Using multiple container sets is bad software engineering. I work on projects that use STL exclusively, and I work with projects that use Qt. If i used Qt in a project that used STL, they would not accept it. In a Qt commercial project I worked on, if I had used STL, they would not have accepted it. It would be bad engineering. This is no different than mixing in GTK and Motif widgets in KDE applications. They're both as standard as Qt is. If you allow people to use STL, you have no right to deny them to reimplement, say std::vector, their own way and use that. Then you could have a different class with a different interface in every app/library! > If you don't want to use it, then don't, but why do > you want to force others? When you write code in KDE CVS, you put the burden of maintenance on everyone else's shoulders. If you write STL code, you are requiring every other KDE developer to use STL too, in effect, unless that code has to get dumped the moment you stop maintaining it sufficiently to keep it bug free and shippable. Are there special cases? yes... Some things absolutely have to use other widgets/toolkits simply to be able to interface with third parties. nspluginviewer has to make one simple Motif call in order to load plugins. Do we use Motif elsewhere? No! -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/