On Sat, 2006-06-17 at 09:18, Tristan Van Berkom wrote:
> Alan M. Evans wrote:
> >>the lookup penalties are negligible.
> >>type node/class lookups and is_a checks are O(1);
> >>interface class lookups and conforms_to checks are O(ld(N)), where
> >>N is the number of interfaces a type node conforms
Tim Janik wrote:
[...]
> no there won't be a performance hit.
[...]
>268435456| 29.0
> 2147483648| 32.0
>
> that is, for all practical purposes, interface lookups are negligible
> even
> for many thausands of interfaces implemented per node.
>
T
Hi all,
I'm a GObject based libraries (for UI purpose and not) user and I often need a
generic container to derive my own types. In my opinion, I think this generic
container must be included inside the GObject library ... it could be used by
a lot of derived libraries providing a common approa
On Sat, 17 Jun 2006, Tristan Van Berkom wrote:
> Alan M. Evans wrote:
> [...]
>
>>> the lookup penalties are negligible.
>>> type node/class lookups and is_a checks are O(1);
>>> interface class lookups and conforms_to checks are O(ld(N)), where
>>> N is the number of interfaces a type node confor
Alan M. Evans wrote:
[...]
>>the lookup penalties are negligible.
>>type node/class lookups and is_a checks are O(1);
>>interface class lookups and conforms_to checks are O(ld(N)), where
>>N is the number of interfaces a type node conforms to.
>>
>>
>
>Your assertion that the penalties are neg
On Fri, 2006-06-16 at 04:28, Tim Janik wrote:
> On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote:
>
> > Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu:
>
> >> All of that just to say... I cannot count the times I've thought to
> >> myself that
> >> GtkContainer should really just
Fontana Nicola wrote:
[...]
>I wrote gcontainer with this in mind (the GContainerable interface is
>"compatible" with GtkContainer and GChildable with GtkWidget). Anyway, my
>solution presents some serious problems: I'm misusing the interface to hide
>as much technical details as possible to th
> On Thu, 15 Jun 2006, Fontana Nicola wrote:
> > Hi all,
> >
> > I'm a GObject based libraries (for UI purpose and not) user and I often
> > need a generic container to derive my own types. In my opinion, I think
> > this generic container must be included inside the GObject library ... it
> > coul
Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu:
> Tim Janik wrote:
>
> >On Thu, 15 Jun 2006, Fontana Nicola wrote:
> >
> >
> >
> >>Hi all,
> >>
> >>I'm a GObject based libraries (for UI purpose and not) user and I often need
> >>a generic container to derive my own types. In my opin
On Fri, 16 Jun 2006, Gustavo J. A. M. Carneiro wrote:
Qui, 2006-06-15 às 13:00 -0400, Tristan Van Berkom escreveu:
All of that just to say... I cannot count the times I've thought to
myself that
GtkContainer should really just be GContainerIface, and implemented by
whatever interested objects
Tim Janik wrote:
>On Thu, 15 Jun 2006, Fontana Nicola wrote:
>
>
>
>>Hi all,
>>
>>I'm a GObject based libraries (for UI purpose and not) user and I often need
>>a generic container to derive my own types. In my opinion, I think this
>>generic container must be included inside the GObject library
On Thu, 15 Jun 2006, Fontana Nicola wrote:
> Hi all,
>
> I'm a GObject based libraries (for UI purpose and not) user and I often need
> a generic container to derive my own types. In my opinion, I think this
> generic container must be included inside the GObject library ... it could
> be used by
Hi all,
I'm a GObject based libraries (for UI purpose and not) user and I often need
a generic container to derive my own types. In my opinion, I think this
generic container must be included inside the GObject library ... it could
be used by a lot of derived libraries providing a common approa
13 matches
Mail list logo
