Re: [gtk-list] Re: C++ and Gtk
- From: Brian Stempel <stempel oneimage com>
- To: Kenneth Albanowski <kjahds kjahds com>
- cc: gtk-list redhat com
- Subject: Re: [gtk-list] Re: C++ and Gtk
- Date: Wed, 27 May 1998 09:50:36 -0600 (MDT)
> > The idea is that you receive the signal data as a pointer-to-instance,
> > and then make a reference from that. You could just as easily receive
> > the data as a pointer-to-instance, and then just use the -> operator,
> > rather than the . operator, but I prefer the above syntax, and I
> > *believe* it's slightly more efficient that way.
>
> I'd be astonished if it were more efficient, as it's the identical
> operation -- though the compiler might not be smart enough to figure that
> out.
Yeah, I guess that's true, I don't really know how the compiler will handle
it exactly, but it's certainly not less efficient.
> In any case, my only complaint with the described technique is that you
> lose the "data" slot, in using it as your 'this' pointer, which requires
> no end of pains with set_data and get_data to make up for the loss, and
> really causes headaches with the MenuFactory. I assume gtk-- has decent
> solutions to all of this.
Hmm, in practice I've never had a problem with the above, and neither
has anyone I've worked with who was familiar with the technique.
Really, *all* the data I've ever needed can be gotten from my object as data
members or from other objects using access functions, and since the signal
handler itself is part of the object, it has access to all the object's
private data.
In fact, I think that using "this" is probably the most flexible choice as a
candidate for the slot, because it basically allows the static function to
simulate a regular object method, with the same access, scope, etc. that the
other non-static methods of the object have. Can you give an example of
where you'd need to use set_data/get_data, rather than having the data in
question be a member of the class?
AFA MenuFactory, I cannot comment, as I have only done menus using the manual
approach, but I still do not see why a MenuFactory, ensconced in some type of
menu managing class, could not achieve the same effect? Can you elaborate
please on why it is so difficult to use MenuFactory with this technique?
I ask because, as I said before, I'm planning on doing some stuff shortly
here, and I'd like to know if there's some things I need to address.
Brian
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]