Content-Type: multipart/signed;
Content-Transfer-Encoding: 7bit

Content-Type: text/plain;
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=

> bad practice.

Well, almost. Currently programmers can be almost certain that Qt3 is built=
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=

> 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=
the software was created.
Just because the modern versions of GCC can handle exceptions nicely does n=
automatically make all code safe to use them.

If a distributor switches to a new compiler, their developers will likely t=
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=
package, the chance of libqt3 compiled with exceptions is quite low.

It's all a matter of compatability.


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

Content-Type: application/pgp-signature

Version: GnuPG v1.4.2 (GNU/Linux)



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 <<