--===============1795335660==
Content-Type: multipart/signed;
boundary="nextPart3581403.hiMIH3bhfT";
protocol="application/pgp-signature";
micalg=pgp-sha1
Content-Transfer-Encoding: 7bit

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

On Wednesday 07 December 2005 22:15, Volker Lukas wrote:
> Kevin Krammer wrote:
> > [...]
> >
> > If the application developer wants to deploy on Linux systems _and_ use
> > the systems Qt3 installation, he can safely assume it was built without
> > exceptions [...]

>
> This is in some way a chicken and egg problem: Programmers fear that Qt is
> built with -fno-exceptions, which puts them of from using exceptions. In
> consequence, the people building Qt packages are less compelled to give up
> this practice. This alone does not say much about whether it is a good or=

a
> bad practice.


Well, almost. Currently programmers can be almost certain that Qt3 is built=
=20
without exceptions support and my guess is this is not going to change as=20
pretty all software developed for it depends on that.

> > [...] because of the problems earlier GCC versions had with them and
> > so most (all+) software assumes -fno-exceptions

>
> I use an older release series myself (3.3.x) and exception support creates
> much less problems than support for some other C++ features.
>
> This release series is binary compatible to GCC 3.2, if I recall correctl=

y.
> GCC 3.2 has been released in August 2002. This means users of GCC releases
> from that time on can easily upgrade their release to an "unproblematic"
> version. The intermediary releases 3.0.0 - 3.1.1 were not adopted widely.
> So the preceding release series was GCC 2.95, with the first release in
> July 1999 (last March 2001). This means that the "problematic" compiler is
> basically 6 years old. I do not think that it is reasonable to hold
> progress back, just to cater for such an old compiler.


The problem is not the currently used compiler version, but the one used wh=
en=20
the software was created.
Just because the modern versions of GCC can handle exceptions nicely does n=
ot=20
automatically make all code safe to use them.

If a distributor switches to a new compiler, their developers will likely t=
est=20
which newly available options they can activate _without_ breaking the=20
software they intend to ship.

If enabling exceptions in libqt3 breaks ~100% of the Qt3 applications they=
=20
package, the chance of libqt3 compiled with exceptions is quite low.

It's all a matter of compatability.

Cheers,
Kevin

=2D-=20
Kevin Krammer
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtforum.org

--nextPart3581403.hiMIH3bhfT
Content-Type: application/pgp-signature

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

iD8DBQBDmCnVnKMhG6pzZJIRAqReAJsGIILRTctqQ6xGHRMh1a dcQ5v24gCeNqrw
XqB2NV3VGc/GJqaniMCRFWo=
=PZzC
-----END PGP SIGNATURE-----

--nextPart3581403.hiMIH3bhfT--

--===============1795335660==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


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


--===============1795335660==--