[haiku-commits] Re: r39435 - in haiku/branches/developer/bonefish/weak-symbols/src: apps/icon-o-matic apps/icon-o-matic/document apps/icon-o-matic/gui apps/icon-o-matic/import_export apps/icon-o-matic/import_export/flat_icon ...
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Mon, 15 Nov 2010 14:46:34 +0100
On 2010-11-15 at 14:20:34 [+0100], Stephan Aßmus <superstippi@xxxxxx> wrote:
> Am 15.11.2010 13:37, schrieb ingo_weinhold@xxxxxx:
> > Author: bonefish
> > Date: 2010-11-15 13:37:52 +0100 (Mon, 15 Nov 2010)
> > New Revision: 39435
> > Changeset: http://dev.haiku-os.org/changeset/39435
> [...]
> > Log:
> > Moved the libicon classes into a different namespace when compiling them
> > for
> > Icon-O-Matic. Since they have different implementations (which is rather
> > hacky
> > BTW) Icon-O-Matic would crash with symbol preemption enabled.
>
> Thanks and sorry for the inconvenience this caused... I agree the
> solution is rather hacky. The stripping of unnecessary functionality is
> driven by performance concerns, since construction of icon objects
> should be as fast as possible in Tracker and other read-only clients.
> One could use derived classes in Icon-O-Matic which add the necessary
> functionality, in some cases the functionality resides in base classes,
> though, those could be mixed in perhaps. Or do you know of a better
> approach (the code probably fresher in your mind then in mine...).
I haven't looked at the code beyond a quick glance at Icon.h; the rest was
rather monotonous manual search and replace. Generally the subclassing
approach would be fine I guess. A template based approach might be a better
alternative -- i.e. the optional code would be moved into policy parameters,
which for libicon would be no-ops and thus optimized away by the compiler.
CU, Ingo
Other related posts:
