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

List:       kde-devel
Subject:    Re: STL -> QTL
From:       Stephan Kulow <coolo () itm ! mu-luebeck ! de>
Date:       1999-06-21 17:04:56
[Download RAW message or body]

Lars Knoll wrote:
> 
> 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.

Hmm, wouldn't it be just an option to the idl compiler?

Greetings, Stephan

-- 
Und sie nannten ihn, wie er selbst unterschrieb -
Den Trojanischen Pferdedieb

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