On Tue, Jan 04, 2005 at 15:16:51 +0100, Antonio Coralles wrote:
> Carl Nygard wrote:
>
> >On Mon, 2005-01-03 at 23:46 +0100, Antonio Coralles wrote:
> >>i know that this is more a libsigc++ question; but as gtkmm uses
> >>libsigc++ heavily and the libsigc++ mailinglist is not very populated i
> >>ask this question here too:
> >>
> >>is there an elegant way to "change *p_obj in mem_fun(*p_obj, ...)"
> >>after the signal is allredy attached to a concrete object , so that when
> >>the copy constructor of that object is called, some_signal.emit(...)
> >>calls the method in the object created by this copy constructor call ?
> >>or is it better to think of a different design, so that this question
> >>doesn't come up ?
> >>
> >>to avoid misunderstandigs, here is somekind of example:
> >>
> >>//just a useless signal
> >>sigc::signal<void> someSignal;
> >>
> >>//just a useless class
> >>class Useless : public sigc::trackable
> >>{
> >> public:
> >> void call_me() { ... }
> >>};
> >>
> >>//a useless scope
> >>....
> >>{
> >> Useless u1;
> >> someSignal.connect(sigc::mem_fun(u1, &Useless::call_me));
> >> //ok now connected - but how can i automatically change the target
> >>object to u2 - so that u2.call_me() is called due someSignal.emit() ?
> >> Useless u2(u1); //imagine this call is made at a comletly different
> >>part in my programm - for example in a clone method ....
> >> ....
> >>}
> >> ....
> >
> >This is a bad idea simply from the standpoint that C++ creates temporary
> >copies in a variety of situations, many of which you are not consciously
> >aware of. I'd find a different design.
> >
> >BTW, you can also disconnect the signal if you store the connection info
> >returned when you call connect(), so you can manually disconnect and
> >reconnect (so long as you have the original signal).
> >
> Well, i guess you are right, I should find another way, allthough
> temporary copies aren't a problem, because i could make the copy
> constructor private and use it only in a virtual clone method ....; but
> to store the the connection and the signal in the object to wich the
> signal was connected seems messy and error prone.
Actualy the callback will get the signal invocant (ie. the object
emiting the signal) as first argument no matter whether you use a method
or function. So I suggest connecting a static function that invokes
method on it's first argument.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature