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

List:       kde-devel
Subject:    Re: STL -> QTL
From:       Lars Knoll <Lars.Knoll () mpi-hd ! mpg ! de>
Date:       1999-06-21 16:06:25
[Download RAW message or body]

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.

As the mini-stl is a subset of the stl, I think, KDE should still work if
you compile mico using the STL. It's just that one should be able to do
the compilation with the mini-stl, and that KDE apps/libs shouldn't
use features of the STL which the mini-stl doesn't have.

> 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.

I'm not sure about that. While not knowing anything about MICO's
internals, I would guess, that one could just add some configure switches
like --enable-qt-binding and --enable-c++-binding to MICO. If done the
right way, one could probably compile mico with both bindings enabled.

Cheers,
Lars

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