Binding local variables to a signal connection

  • Thread starter Matthias Kaeppler
  • Start date
M

Matthias Kaeppler

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
 
J

Jeff Flinn

Matthias Kaeppler said:
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
 
M

Matthias Kaeppler

Jeff said:
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::eek:perator<< would have segfaulted?

Regards,
Matthias
 
J

Jeff Flinn

Matthias Kaeppler said:
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.


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::eek:perator<< would have segfaulted?


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

Jeff Flinn
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top