On Mon, Dec 22, 2008 at 05:30:32PM +0100, Christian Dywan wrote:
> > As you say, because type casts are dinamic, there's the overhead
> > of calling g_type_check_instance_* which in languages like C++ is
> > not needed because it's done at compilation time. I suspect that
> > this overhead is negl
On Mon, Dec 22, 2008 at 07:54:59PM +0100, Sven Neumann wrote:
> > However, there is a performance problem with private attributes
> > (if you use g_type_class_add_private()) that don't exist in other
> > languages, as GObject's g_type_instance_get_private() can be
> > noticeably slow.
>
> That ca
Hi,
On Mon, 2008-12-22 at 16:44 +0100, Alberto Garcia wrote:
> However, there is a performance problem with private attributes
> (if you use g_type_class_add_private()) that don't exist in other
> languages, as GObject's g_type_instance_get_private() can be
> noticeably slow.
That can easily be
Am Mon, 22 Dec 2008 16:44:55 +0100
schrieb Alberto Garcia :
> On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote:
>
> > > the code generated for a virtual function in C++ is as far as I
> > > understand (as I said, noob here) in principle the same as the
> > > code you have to manually w
On Mon, Dec 22, 2008 at 02:44:40PM +, Ross Burton wrote:
> > the code generated for a virtual function in C++ is as far as I
> > understand (as I said, noob here) in principle the same as the
> > code you have to manually write in GObject to do the same thing,
> > it's just much more invisible
On Mon, 2008-12-22 at 15:22 +0100, Robin Sonefors wrote:
> I think I got this impression of GObject because it forces you to really
> see the overhead, when most other languages/libraries works harder to
> hide more. For instance, the code generated for a virtual function in
> C++ is as far as I u
On mån, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote:
> I haven't programmed much with gtk+, so forgive a noob if this is a
> silly question. My first impression when I looked at the architecture
> (using GObject etc.) was that this must take quite a bit of processing
> cycles and memory. So
Am Montag, den 22.12.2008, 14:27 +0100 schrieb Olav Vitters:
> On Mon, Dec 22, 2008 at 03:10:13PM +0200, Eugene Gorodinsky wrote:
> > >Vala is a high level language which is translated to GObject and C, so
> > >you are proposing to rewrite GObject using GObject.
> >
> > Vala can be modified, since
On Mon, Dec 22, 2008 at 03:10:13PM +0200, Eugene Gorodinsky wrote:
> >Vala is a high level language which is translated to GObject and C, so
> >you are proposing to rewrite GObject using GObject.
>
> Vala can be modified, since it is open source and all. I'm not sure if
> that's feasible though, a
>Vala is a high level language which is translated to GObject and C, so
>you are proposing to rewrite GObject using GObject.
Vala can be modified, since it is open source and all. I'm not sure if
that's feasible though, as I'm not familiar with it.
___
g
On Mon, 2008-12-22 at 13:12 +0200, Eugene Gorodinsky wrote:
> I haven't programmed much with gtk+, so forgive a noob if this is a
> silly question. My first impression when I looked at the architecture
> (using GObject etc.) was that this must take quite a bit of processing
> cycles and memory. So
2008/12/22 Eugene Gorodinsky :
> question. My first impression when I looked at the architecture (using
> GObject etc.) was that this must take quite a bit of processing cycles and
> memory. So my question is: is there any room for improvement by rethinking
> the architecture (using Vala for some o
I haven't programmed much with gtk+, so forgive a noob if this is a silly
question. My first impression when I looked at the architecture (using
GObject etc.) was that this must take quite a bit of processing cycles and
memory. So my question is: is there any room for improvement by rethinking
the
13 matches
Mail list logo
