From kde-core-devel  Thu Mar 10 19:16:56 2005
From: Leo Savernik <l.savernik () aon ! at>
Date: Thu, 10 Mar 2005 19:16:56 +0000
To: kde-core-devel
Subject: Re: (gcc 2.95 support) kdeextragear-1/amarok/src
Message-Id: <200503102016.57042.l.savernik () aon ! at>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111048187213552
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart2865031.HtZibbLXO7"

--nextPart2865031.HtZibbLXO7
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Am Donnerstag, 10. M=E4rz 2005 19:43 schrieb Thiago Macieira:
> Adriaan de Groot wrote:
> >> How much longer do we have to support gcc 2.95 for? I must say I have
> >> a great deal of distaste that we must make our code more ugly for the
> >> sake of an old compiler. I do understand that people want to continue
> >> to use it, but I just wonder how much longer they will do so. Thanks,
>
> At least for all 3.x releases, since we promised to.
>
> For KDE 4, I'd like to see that revised. gcc 2.95 will be 6 years old by
> then. I say we move gcc 2.95 support from "required" to "would be nice".

Which effectively means it support becomes terminally broken.
>
[...]
> >
> >RELENG_4_11  4.11-RELEASE  Extended  January 25, 2005  January 31, 2007
>
[...]
> Also, take a look at the emails sent just after 3.3.0 was released. We had
> a bug/crash in our code that was caused by a miscompilation. The gcc
> developers won't fix it.

As a software writer you can't count on compiler vendors fixing their bugs.=
=20
It's easier and more effective to work around them.
>
> So, why are we supporting a broken compiler that won't be fixed? I'm not
> talking about missing features...

Broad portability means broad support of compilers. Hence, making use of th=
e=20
latest and greatest C++-standard features will reduce portability for KDE.
>
> >Oh, if you're moaning about having to support gcc 2.95, be glad that KDE
> >doesn't officially support any of the other C++ compilers out there,
> > which are even more picky.
>
> I'd like to see some more strictness added to our code, yes. Every time a
> new gcc version is released, we have to do that anyways.

I support that, too. But just as we banned C99 code for KDE development=20
because of portability reasons, we should also similarly restrict the use o=
f=20
very advanced C++-standard functionality, especially when it can be worked=
=20
around easily.

mfg
	Leo

--nextPart2865031.HtZibbLXO7
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQBCMJ0pj5jssenUYTsRAqCSAJ4/A0J8gKp1jkMShSe+fuZJEUdycACdEzk/
88WxtI1G71aRxvYE9ko7UKU=
=RbSy
-----END PGP SIGNATURE-----

--nextPart2865031.HtZibbLXO7--