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

List:       kde-devel
Subject:    Re: KDE and Gcc 3.0
From:       "Christophe Prud'homme" <prudhomm () MIT ! EDU>
Date:       2001-06-18 18:55:02
[Download RAW message or body]

* Nils Holland  [Lundi 18 Juin 2001 02:24 pm ]  :

  > On Monday 18 June 2001 19:56, Mathieu Chouinard wrote:
  > > Hi,
  > > Does anybody have compiled KDE 2.2alpha2 with GCC 3.0?
  > > Mathieu
  >
  > No, but as far as I am informed, GCC 3 is not able to properly compile
  > "real world code" like KDE at the moment. I wonder if the GCC 3 version
  > that will eventually be released will be able to do this. Originally, the
  > GCC folks wanted to get 3.0 out of the door in the first half of this
  > year, but from what I have heard from various people (and from what I
  > have read on their website in their release-criteria), I think they're
  > not quite there yet...
gcc 3.0 and especially g++ 3.0 is much better than 2.95 regarding the standards
however there will be some problems porting existing apps to 3.0
I especially forsee one problem
the c++ style headers vs c style header
in 2.95 you could use both without problems because it was not following the standards
now you have to be careful

if you have to choose one style and both using both
if you want to use the c++ style
#include <iostream> // for example
then you will have to use the namespace std::
otherwise this code won't compile
cout << "Hello World!" << endl;
the correct version  is 
std::cout << "Hello World!" << std::endl;

Ok it is more verbose however namespace are a powerful, while simple concept, which allows you 
to write libraries and codes without thinking about naming conflicts


now if you use the c style header
#include <iostream.h>
you can have both  notations[with std:: and without std::]
but it means that you can mix up styles which is not good in general

I tend to prefer the c++ style for correctness and consistency. there is no excuse for 
lazy code.

moreover G++ 3.0 has a new inliner which operates at a earlier stage which will allow
better optimization for inline functions. I know some c++ techniques that could really benefit
from such a change, however I am not sure that it will improve tremendously a GUI.

regards
C.
-- 
| Christophe Prud'homme, http://augustine.mit.edu/~prudhomm
| ICQ UIN: 24560867 Alias: Jesunix
|
| Travailler dur n'a jamais tué personne, mais pourquoi prendre le risque ?
| -- Edgar Bergen

>> Visit http://master.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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