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

List:       kde-commits
Subject:    Re: kdebase/kcontrol/fonts
From:       Marcus Camen <mcamen () mcamen ! de>
Date:       2003-04-28 18:37:14
[Download RAW message or body]

> > > >-    ifstream f(QFile::encodeName(m_file));
> > > >+    std::ifstream f(QFile::encodeName(m_file));
> > >
> > > I know you just made it compile, but, uhm, this should really be QTL,
> > > shouldn't it?
> >
> > Yes, of course. If we would nuke all STL code in KDE we would get rid of
> > about 60-70 % of all compile problems on non-gcc compilers. But I don't
> > want to rewrite all that code myself...  ;-)
> > ... and we probably don't want such rewrites in the BRANCH.
>
>  I remember using ifstream ten years ago (ok, that was a slightly different
> one I guess). What kind of problems should there be with it?

Well, some of these problems are simply due to compilers not fully 
implementing the C++ standard. Others occur due to pedantic namespace 
handlings of the compilers. And sometimes you just have compiler bugs.

For me it seems that the KDE code is quite challanging regaring namespace 
support in the compilers. Take for example MipsPro: With version 7.3 you get 
dozends of KDE namespace (KIO::, etc.) problems. With MipsPro 7.4 most of 
them are gone.

In this case (kxftconfig.cpp) only a few std:: were missing with 
kcontrol/kfontinst/kfontinst/* having the same problems. Obviously the 
compiler is quite pedantic regarding namespace issues. 

>  In fact, now that we have here the STL discussion, what problems in
> general do non-gcc compilers have with STL? Well, besides the compiler
> being quite old, but I thought KDE already demands quite capable C++
> compiler that should be able to handle at least common usage of STL?

Oh, the compilers are not old. They are just ... well ... strange.

As I said. Most of the problems are due to broken compilers or broken STL 
libraries. Of course this is not really an argument against STL usage in 
KDE...
But you won't have these problems with QT as you don't have different QTL 
implementations on different platforms. Furthermore you don't need to link to 
this whatever-it-is-called-on-this-specific-platform-and-compiler-STL-lib to 
your code (BTW: may I vote for a libtool upgrade again  ;-)).

Another example (not related to STL) is the NULL vs. 0 vs. 0L vs. (void *)0 
discussion we've had a few months ago. Every compiler has a different opinion 
about this. If you always compare against QString.isnull() or similar you 
don't have these kind of problems.

--
Marcus...
   ...who notices that more and more companies providing software for
    different flavours of UNIX are porting to QTL...
[prev in list] [next in list] [prev in thread] [next in thread]