README.qtcopy: -no-stl or no -no-stl?
Bo Thorsen
bo at sonofthor.dk
Tue Jan 20 10:21:41 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.
It doesn't. All exception stuff is in a different part of the file and not
loaded before an exception is thrown. The file is bigger, but doesn't
take longer to load.
Bo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20040120/f95fc18e/attachment.sig>
More information about the kde-core-devel
mailing list