I just spent a few hours debugging an interesting case. I figured that I would be able to declare a std::vector of independent signals, which does not seem to be the case. Here is a minimal example:
-----begin code------ #include <iostream> #include <vector> #include <sigc++/sigc++.h> void printInt(int val) { std::cout << val << std::endl; } int main() { std::vector< sigc::signal<void> > sigVec(2); sigVec[0].connect( sigc::bind( sigc::ptr_fun( printInt ), 0 ) ); sigVec[1].connect( sigc::bind( sigc::ptr_fun( printInt ), 1 ) ); sigVec[0].emit(); sigVec[1].emit(); return 0; } -----end code------ What I was expecting to see printed to the console was: 0 1 But what I got was: 0 1 0 1 So, I guess I didn't realize that a sigc::signal object was a kind of reference, and that: sigc::signal<void> sigA; sigc::signal<void> sigB = sigA; actually only creates one signal with two names. The documentation on http://www.cplusplus.com/reference/stl/vector/vector/ says that the "Repetative sequence constructor" initializes the vector with "n copies" of the same value, so no surprises there... just that I wasn't expecting assignment of a signal object to copy the actual signal. This is neither a complaint or a request since the only problem is that my assumption was incorrect so my expectations were not met... but I felt the need to share this little tidbit, since searching the web and the list didn't point out to this feature. Of course, checking back to the documentation I found this: "When signals are copied they share the underlying information, so you can have a protected/private sigc::signal member and a public accessor method." (http://developer.gnome.org/libsigc ++/stable/group__signal.html#_details) So the information was there, I guess I just missed it. _______________________________________________ libsigc-list mailing list libsigc-list@gnome.org http://mail.gnome.org/mailman/listinfo/libsigc-list