By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,215 Members | 1,930 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,215 IT Pros & Developers. It's quick & easy.

Binding local variables to a signal connection

P: n/a
Hi,

it might be a stupid question, but i'll take the chance and ask:

void connect() {

std::string str;

// ...

some_signal.connect(
bind(mem_fun(some_obj, &SomeObj::signal_handler), str));

}

void SomeObj::signal_handler(const std::string &str) {
std::cout << str << std::endl; // does this segfault?
}

I used the sigc syntax in the example code, but it's really a question
which applies to the technique of binding variables in general.

Will cout'ing the string in the signal handler fail because str is
already destroyed, or will it continue living because it's copied and
reference counted?

Thanks,
Matthias
Dec 1 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a

"Matthias Kaeppler" <vo**@void.com> wrote in message
news:dm*************@news.t-online.com...
Hi,

it might be a stupid question, but i'll take the chance and ask:

I'll answer below, you can decide if I'm stupid or not. :)
void connect() {

std::string str;

// ...

some_signal.connect(
bind(mem_fun(some_obj, &SomeObj::signal_handler), str));
I've been seeing this usage a bit lately in newsgroup postings and am
puzzled at the penchant for using mem_fun rather than one of these
alternatives:

some_signal.connect( bind( &SomeObj::signal_handler, some_obj, str );

some_signal.connect( bind( &SomeObj::signal_handler, &some_obj, str );

some_signal.connect( bind( &SomeObj::signal_handler, ref(some_obj),
str );

Out of curiosity what was your motivation?
}

void SomeObj::signal_handler(const std::string &str) {
std::cout << str << std::endl; // does this segfault?
}

I used the sigc syntax in the example code, but it's really a question
which applies to the technique of binding variables in general.

Will cout'ing the string in the signal handler fail because str is already
destroyed, or will it continue living because it's copied and reference
counted?


bind copies it's arguments. I think mem_fn holds a reference to some_obj,
and the resulting mem_fn object is copied in your original expression along
with str. In the alternatives I presented, the first copies some_obj, the
second copies a pointer to some_obj, and the third copies a boost::ref that
refers to some_obj.

Jeff Flinn
Dec 1 '05 #2

P: n/a
Jeff Flinn wrote:
// ...

some_signal.connect(
bind(mem_fun(some_obj, &SomeObj::signal_handler), str));

I've been seeing this usage a bit lately in newsgroup postings and am
puzzled at the penchant for using mem_fun rather than one of these
alternatives:

some_signal.connect( bind( &SomeObj::signal_handler, some_obj, str );

some_signal.connect( bind( &SomeObj::signal_handler, &some_obj, str );

some_signal.connect( bind( &SomeObj::signal_handler, ref(some_obj),
str );

Out of curiosity what was your motivation?


I wan't aware that I can pass a pointer-to-memberfunction directly to
bind. For some reason I thought to remember it expects a functor of some
sort to be passed as the first argument (maybe it's constructed
automatically from the pointer).

Good to know I can write it this way, thanks.
bind copies it's arguments. I think mem_fn holds a reference to some_obj,
and the resulting mem_fn object is copied in your original expression along
with str. In the alternatives I presented, the first copies some_obj, the
second copies a pointer to some_obj, and the third copies a boost::ref that
refers to some_obj.


So if I had bound the string using sigc::ref, then the call to
cout::operator<< would have segfaulted?

Regards,
Matthias
Dec 1 '05 #3

P: n/a

"Matthias Kaeppler" <m_******@SCIEDU.com> wrote in message
news:dm**********@news.uni-kl.de...
Jeff Flinn wrote:
// ...

some_signal.connect(
bind(mem_fun(some_obj, &SomeObj::signal_handler), str));

I've been seeing this usage a bit lately in newsgroup postings and am
puzzled at the penchant for using mem_fun rather than one of these
alternatives:

some_signal.connect( bind( &SomeObj::signal_handler, some_obj,
str );

some_signal.connect( bind( &SomeObj::signal_handler, &some_obj,
str );

some_signal.connect( bind( &SomeObj::signal_handler, ref(some_obj),
str );

Out of curiosity what was your motivation?


I wan't aware that I can pass a pointer-to-memberfunction directly to
bind. For some reason I thought to remember it expects a functor of some
sort to be passed as the first argument (maybe it's constructed
automatically from the pointer).

Good to know I can write it this way, thanks.
bind copies it's arguments. I think mem_fn holds a reference to some_obj,
and the resulting mem_fn object is copied in your original expression
along with str. In the alternatives I presented, the first copies
some_obj, the second copies a pointer to some_obj, and the third copies a
boost::ref that refers to some_obj.


So if I had bound the string using sigc::ref, then the call to


I had assumed that signal, bind and ref were from boost(or tr1), so being
unfamiliar with 'sigc', I'm not sure anything I've stated is valid in that
case.
cout::operator<< would have segfaulted?

Probably but not a certainty, just as when dealing with any invalidated
reference.

Jeff Flinn
Dec 1 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.