[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: STL -> QTL
From:       weis () stud ! uni-frankfurt ! de
Date:       1999-06-21 23:26:33
[Download RAW message or body]

Hi,

As a related note: The mico maintainer thought about renaming
the mini-stl classe so that mico still uses the light weight stuff
but it does not collide with current STL any more.

Bye
Torben


On Mon, 21 Jun 1999, Stefan Westerfeld wrote:

>    Hi!
> 
> On Mon, Jun 21, 1999 at 11:40:10AM +0200, weis@stud.uni-frankfurt.de wrote:
> > It seems that people are very fast with removing STL.
> > 
> > That means that we should switch as fast as possible to
> > mini-stl. Since mini-stl implements only what mico needs
> > but not what the standard says, we can not use real
> > STL code when linking with mico any more.
> > 
> > So: Does anybody still use real STL in combination
> > with KDE&Mico ? If so we have to solve that first.
> > 
> > Unfortunately libkoml uses STL a lot, but only simple stuff
> > so that it could even work with mini-stl perhaps.
> > 
> > Using mini-stl ill decrease compile time and size of
> > the executables dramatically.
> 
> I am not sure wether this is a good idea. Well - I am using STL in Arts,
> and switching to QTL is no good option, since the Arts server should not
> depend on Qt. I thought CORBA could make it happen that the KDE project
> not only produces code that can only be used in the KDE context itself,
> but also outside.
> 
> The same concern I have against making a mico version that does not
> support the standard CORBA binding any more. While forcing everybody
> to use a crippled version of STL in their code instead of a real
> version only makes "portable code" (in a sense of porting to anything
> that has a standard C++ compiler) harder, since mini-stl containers are
> not powerful anymore, going to a totally nonstandard CORBA binding 
> which will only work with Qt makes it impossible.
> 
> Well, STL was designed to get around the problem of everybody using
> their own list classes, and STL is part of the C++ standard, so using
> mini-stl exclusively would mean that programs that stick to the C++
> standard may not be used together with KDE stuff.
> 
> Regarding STL bloat, there is a document at (they are working on a
> libstdc++ rewrite):
> 
>   http://sourceware.cygnus.com/libstdc++/17_intro/DESIGN
>   
> They say about the bloat problem:
> "[ ... naive STL implementaions become bloated ...] The alternative
> demands care in construction, and some compiler support, but there is
> no need for library subsets. "
> 
> Anyway, I can't give you numbers how bleeding edge egcs compilers perform
> with their STL redesign in conjunction with mico. (Tried to get it compile
> this weekend, but it doesn't).
> 
> Finally, in my opinion being able to use KOM without Qt would be an
> advantage, so perhaps other projects like apache could use it to make
> something like webobjects, etc.
> 
> But that is not the main thing here.
> 
>    Cu... Stefan
> -- 
>   -* Stefan Westerfeld, stefan@space.twc.de (PGP!), Hamburg/Germany
>      KDE Developer, project infos at http://space.twc.de/~stefan/kde *-
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]