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

List:       kde-panel-devel
Subject:    Re: KDE/kdebase/workspace/plasma/applets/systemtray/protocols/fdo
From:       Casper Clemence <maninalift () googlemail ! com>
Date:       2009-05-29 16:14:39
Message-ID: 4c1964560905290914r539025daw69dccaaf0185e18a () mail ! gmail ! com
[Download RAW message or body]

I'm sorry I'm in danger of perpetuating this side-track. My point was
simply about a method that is theoretically overhead free (e.g.
doesn't create any more data). Of course what the compiler actually
does is another question, and creating a couple of pointers is not
exactly going to be a big performance problem but "overhead free" (1)
makes it easier for the compiler to understand what you are doing and
therefore possibly make other optimisations and (2) makes the
programmer feel happier which means the pattern is more likely to be
used... but most of all it's just a challenge ;¬)

I'll stop wasting folk's time now,

C

2009/5/29 Aaron J. Seigo <aseigo@kde.org>:
> On Friday 29 May 2009, Casper Clemence wrote:
>> That occurred to me. The difference is that method is not logically
>> equivilent to expressly placing the freeing functions since it creates
>> additional pointers to the resources. Of course the compiler might be
>> able to figure that out.
>
> if the resource is not reference counted, it hardly matters how many pointers
> you have as long as one object is the designated "cleaner upper"
>
> --
> Aaron J. Seigo
> humru othro a kohnu se
> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>
> KDE core developer sponsored by Qt Software
>
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel@kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
>
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


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