README.qtcopy: -no-stl or no -no-stl?
Lars Knoll
lars at trolltech.com
Tue Jan 20 10:14:04 GMT 2004
On Tuesday 20 January 2004 10:44, Simon Hausmann wrote:
> On Tuesday 20 January 2004 10:30, Bo Thorsen wrote:
> > On Monday 19 January 2004 14:20, Navindra Umanee wrote:
> > > Hi,
> > >
> > > The first ./configure example in README.qt-copy is:
> > >
> > > ./configure -system-zlib -qt-gif -system-libpng -system-libjpeg \
> > > -plugin-imgfmt-mng -thread -no-stl -fast
> > >
> > > but the recommended ./configure line for GCC is:
> > >
> > > ./configure -system-zlib -qt-gif -system-libpng -system-libjpeg \
> > > -plugin-imgfmt-mng -thread -no-exceptions -debug -fast
> > >
> > > Why does the first one include -no-stl but not the second one? There
> > > isn't an explanation in the file as to which one is most desireable,
> > > speed and efficiency wise.
> >
> > And another thing: Why the "-no-exceptions"? Ever since gcc 3.0.0 was
> > out, having exceptions support compiled in is free of runtime costs, up
> > until the point where you actually throw an exception. If people want to
> > write code that uses exceptions, why not allow them to do so? I know
> > there's an old grudge against exceptions in kde code, but there's no
> > reason to cripple peoples Qt, when they might download Qt apps that need
> > exceptions. And yes, there are examples of such apps.
>
> I believe the original reason for the -no-exceptions recommendation was not
> runtime cost but the increased size of the generated code and increased
> memory consumption. Not sure though if that still applies with recent
> version of gcc.
One can live with the larger binary size on modern desktop systems. A bigger
problems with gcc (at least up to version 3.0) was that the exception code
was mainly stored in a read/write segment in the library increasing the size
of memory used by every application by quite a large amount. As far as I know
this is not the case anymore with gcc-3.2 and up, so there the most
reasonable choice would probably be to have exceptions enabled.
Lars
More information about the kde-core-devel
mailing list