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

List:       kde-devel
Subject:    Re: STL -> QTL
From:       Stefan Westerfeld <stefan () space ! twc ! de>
Date:       1999-06-21 15:38:12
[Download RAW message or body]

   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]