[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: A note to exceptions && some notes to codesize
From:       Alex Zepeda <garbanzo () hooked ! net>
Date:       1999-06-11 2:32:25
[Download RAW message or body]

On Mon, 7 Jun 1999, Mario Weilguni wrote:

> * the exception tables are quite big, and there are tons of _throw()
> calls that are never used (Qt uses no exceptions, and the KDE core
> classes don't use them as well). I see no reason having the libraries
> bloated with this exception code if it is unused. Why not enable
> exception for libraries that use them, and disable for all other
> libraries? I don't think that is a problem.

Because if some program (such as kSirc or konqueror, or anything using
mico) needs to catch an exception, it's prudent to have the exception
"bloat" in the library.  However, you'll also gain a decent savings by
disabling exception handling in applications that don't use exceptions.

> * avoid using too much Qt stuff when there are plain C methods for this. This
> produces better code (shorter and faster), and avoids to have all those
> constructors and destructors called. An example from kapp.cpp:
> Instead of:
>   QString aArgv0 = argv[0];
>   int nSlashPos = aArgv0.findRev( '/' );
>   if( nSlashPos != -1 )
> 	aAppName = aArgv0.remove( 0, nSlashPos+1 );
>   else
> 	aAppName = aArgv0;
> 
> use this:
>   char *nSlash = strrchr(argv[0], '/');
>   if(nSlash)
>     aAppName = nSlash+1;
>   else
>     aAppName = argv[0];
> 

> You don't think this is a good idea? Well, it saves 460 bytes of code
> and quite some execution time (at least 300 clock cycles - not too
> much, a microsecond on a modern CPU). And this are only 6 lines of
> code; the result is as easy to understand as the old method.

Yes, but they also don't do the same thing.  Using some straight C
functions can be a good idea in a few cases, but the tendency to mix and
match QStrings and character arrays will also slow you down.  Sticking
purely to QStrings is another way to speed things up as you avoid the
constant conversion.

> * take advantage of the stack. Stacks never get fragmented, and are
> easily freed after the function finishes. Don't use QString if you can
> avoid it (of course if not making the code totally unreadable or if
> you need Unicode support). But for many cases the plain C string
> functions are better.

- alex

I thought felt your touch
In my car, on my clutch
But I guess it's just someone who felt a lot like I remember you.
  - Translator

[prev in list] [next in list] [prev in thread] [next in thread]