I've been looking at a few signal/slot implementations, and with no exception they were pretty complicated, some even relying on MOC and extra code generation, like those of Qt.
I realize there are concerns such as threat safety and whatnot, but for a simple, single threaded scenario, is there something wrong with going for a simple approach, something like:
typedef void (*fPtr)();
class GenericButton
{
public:
GenericButton() : funcitonToCall(nullptr) {}
void setTarget(fPtr target) {
funcitonToCall = target;
}
void pressButton() {
if (funcitonToCall) funcitonToCall();
}
private:
fPtr funcitonToCall;
};
void doSomething(){
std::cout << "doing something..." << std::endl;
}
void doSomethingElse(){
std::cout << "doing something else..." << std::endl;
}
int main(){
GenericButton myButton;
myButton.setTarget(doSomething);
myButton.pressButton();
myButton.setTarget(doSomethingElse);
myButton.pressButton();
}
It is still possible to chain several other methods and pass data in the target void function. So why all the complexity for something as trivial as executing some code when a button gets clicked.
This is a perfectly sensible solution, but don't restrict yourself to just function pointers. Use std::function which allows you to bind things, call member functions on objects, use lambdas and still resort to a function pointer where it makes sense. Example:
#include <iostream>
#include <functional>
using namespace std::placeholders;
class GenericButton
{
public:
typedef std::function<void()> fPtr;
GenericButton() : funcitonToCall(nullptr) {}
void setTarget(fPtr target) {
funcitonToCall = target;
}
void pressButton() {
if (funcitonToCall) funcitonToCall();
}
private:
fPtr funcitonToCall;
};
struct foo {
void doSomething() const {
std::cout << "doing something in a foo..." << std::endl;
}
static void alternative(int i) {
std::cout << "And another, i=" << i << "\n";
}
};
void doSomethingElse() {
std::cout << "doing something else..." << std::endl;
}
int main() {
GenericButton myButton;
foo f;
myButton.setTarget(std::bind(&foo::doSomething, &f));
myButton.pressButton();
myButton.setTarget(doSomethingElse);
myButton.pressButton();
myButton.setTarget(std::bind(foo::alternative, 666));
myButton.pressButton();
myButton.setTarget([](){ std::cout << "Lambda!\n"; });
myButton.pressButton();
}
There's almost always a better solution in C++ than function pointers.
If you don't have std::function/std::bind there's always alternatives in boost that work and you can roll your own std::function alternative without too much work which would be worth doing if you want to make something like this.
Most of the signal/slot mechanisms that are around date from a time when things like boost::bind was not a viable option. Those days are long gone and you can get something standard and more flexible for little more complexity than just a function pointer.
Related
Almost every OOP programmer has been exposed to the concept of Inversion of control. In C++, we can implement that principle with dynamic callbacks (i.e. functors such as lambdas and function pointers). But if we know at compile time what procedure we are to inject into the driver, theoretically I believe that there is a way to eliminate the overhead of function passing and invoking by composing the callbacks and the driver/signal/what-so-ever function into an "unrolled procedure". Here is an example.
For a GUI program, we have logic on window 1) setup, 2) loop, and 3) termination. We can inject code 1) after window setup, 2) in each render loop, 3) and before termination. A procedural approach is to write in this manner:
// Snippet 1:
init_window();
init_input_handler();
init_canvas();
init_socket();
while (!window_should_close()) {
update_window();
handle_input();
draw_on_canvas();
send_through_socket();
}
drop_input_handler();
drop_canvas();
drop_socket();
terminate_window();
OOP programmers pride ourselves in decoupling and proper abstraction. Instead, we write this:
// Snippet 2:
init_window();
on_window_init_signal.send();
while (!window_should_close()) {
update_window();
on_render_signal.send();
}
on_exit_signal.send();
terminate_window();
But this brings an unwanted overhead as said above. My question is: How can we utilize the C++ metaprogramming mechanisms to achieve zero-overhead inversion of control so that code in a similar form of snippet 2 can be transformed into snippet 1 statically (i.e. at compile time)?
EDIT: I can think of loop optimizations widely found in optimizers. Maybe this is a generalized version of that issue.
"Zero Overhead" & "But if we know at compile time what procedure we are to inject into the driver, " is possible.
You can use a template class to pass the functions to call like that:
struct SomeInjects
{
static void AtInit() { std::cout << "AtInit from SomeInjects" << std::endl; }
static void AtHandleInput() { std::cout << "AtHandleInput from SomeInjects" << std::endl; }
static void AtDraw() { std::cout << "AtDraw from SomeInjects" << std::endl; }
};
struct OtherInject
{
static void AtInit() { std::cout << "AtInit from OtherInject" << std::endl; }
static void AtHandleInput() { std::cout << "AtHandleInput from OtherInject" << std::endl; }
static void AtDraw() { std::cout << "AtDraw from OtherInject" << std::endl; }
};
template < typename Mixin >
struct Win
{
void Init()
{
Mixin::AtInit();
}
void HandleInput()
{
Mixin::AtHandleInput();
}
void Draw()
{
Mixin::AtDraw();
}
};
int main()
{
Win<SomeInjects> wsi;
wsi.Init();
wsi.HandleInput();
wsi.Draw();
Win<OtherInject> wso;
wso.Init();
wso.HandleInput();
wso.Draw();
}
But this has the drawback, that it needs static functions.
More elaborated try:
struct SomeInjects
{
void AtInit() { std::cout << "AtInit from SomeInjects" << std::endl; }
void AtHandleInput() { std::cout << "AtHandleInput from SomeInjects" << std::endl; }
void AtDraw() { std::cout << "AtDraw from SomeInjects" << std::endl; }
};
struct OtherInject
{
void AtInit() { std::cout << "AtInit from OtherInject" << std::endl; }
void AtHandleInput() { std::cout << "AtHandleInput from OtherInject" << std::endl; }
void AtDraw() { std::cout << "AtDraw from OtherInject" << std::endl; }
};
template < typename Mixin >
struct Win: Mixin
{
void Init()
{
this->AtInit();
}
void HandleInput()
{
this->AtHandleInput();
}
void Draw()
{
this->AtDraw();
}
};
int main()
{
Win<SomeInjects> wsi;
wsi.Init();
wsi.HandleInput();
wsi.Draw();
Win<OtherInject> wso;
wso.Init();
wso.HandleInput();
wso.Draw();
}
The last technique is called Mixin.
If your compiler inlines all and everything depends on many things. But typically all calls are inlined if the called functions are not really to big.
But if you need any runtime changeable callbacks, you have to use some kind of callable representation. That can be function pointers or things like std::function. The last generates more or less always some minor overhead.
But remember: A simple dereferenced pointer is typically not the speed problem at all. More important is, that in such cases constants can not be propagated, the code can't be inlined and as a result an overall optimization is not longer possible. But if runtime flexibility is needed, it will have some cost. As always: Measure before optimize!
Within JavaScript, you can pull off something like this:
function bunny() { alert("The bunny jumped."); }
var oldBunny = bunny;
function bunny() {
oldBunny();
alert("The bunny also ran.");
}
bunny(); // The bunny Jumped. The bunny also ran.
As one can see, the old "bunny" function had code appended to it by copying to a variable, then recreating the function with the same name. The copy of the original function runs, and the new code also runs.
I wish to replicate a similar mechanic in C++.
Now before you have a meltdown and start explaining the differences between static and dynamic languages, I get it. I'm not looking for something identical to what's provided, but I do desire something similar.
Furthermore, I'm not trying to do this to modify existing code; I wish to format my own source code to allow such a mechanic for other users to take advantage of.
One of the first ideas I had was to perhaps setup various macros within the code that could later be modified by other files.
Another idea would be to create a Signal and Slots system like in QT. Though I have no clue how to do such a thing myself.
Thank you for reading; I hope you have some suggestions.
Well, if you recognize which feature of JavaScript functions makes this possible, it's not too hard to do the same in C++. In JavaScript functions also have closures, which regular function in C++ don't have. But C++ lambdas are of a closure type. And if one defines bunny to be something which can both hold an object of a closure type, and be reassigned, you're all set.
The C++ standard library offers a nice default choice for this, in the form of std::function. We can just re-write your original JavaScript as follows:
std::function<void()> bunny = [] {
std::cout << "The bunny jumped.\n";
};
auto oldBunny = std::move(bunny);
bunny = [oldBunny] {
oldBunny();
std::cout << "The bunny also ran.\n";
};
bunny();
You can use functors.
#include <iostream>
#include <string>
class Base
{
public:
virtual std::string operator ()()
{
return "Base call";
}
virtual ~Base() {}
};
class Derived : public Base
{
public:
virtual std::string operator()()
{
return "Wrapper: " + Base::operator()();
}
};
int main()
{
Base* pFun = new Base;
std::cout << "Now check Base: " << (*pFun)() << std::endl;
delete pFun;
pFun = new Derived;
std::cout << "Now check Derived: " << (*pFun)() << std::endl;
return 0;
}
Assuming the goal is to allow the calling code to extend the program's functionality beyond what the initial code provided, I might use a user-updatable array of functor-objects, something like this:
#include <iostream>
#include <memory>
class Function
{
public:
virtual void Call() = 0;
};
typedef std::shared_ptr<Function> FunctionSharedPointer;
class OldBunny : public Function
{
public:
virtual void Call()
{
std::cout << "The bunny jumped." << std::endl;
}
};
class NewBunny : public Function
{
public:
NewBunny(FunctionSharedPointer oldFunction) : _oldFunction(oldFunction) {/* empty */}
virtual void Call()
{
_oldFunction->Call();
std::cout << "The bunny also ran." << std::endl;
}
private:
FunctionSharedPointer _oldFunction;
};
enum {
FUNCTION_BUNNY,
// other functions could be declared here later...
NUM_FUNCTIONS
};
// Our table of functions that the user can Call() if he wants to
static FunctionSharedPointer _functionTable[NUM_FUNCTIONS];
// Wrapper function, just to keep users from accessing our table directly,
// in case we ever want to change it to something else
void CallFunction(int whichFunction)
{
_functionTable[whichFunction]->Call();
}
// Another wrapper function
void SetFunction(int whichFunction, FunctionSharedPointer newFunctionDefinition)
{
_functionTable[whichFunction] = newFunctionDefinition;
}
// And another
FunctionSharedPointer GetFunction(int whichFunction)
{
return _functionTable[whichFunction];
}
int main(int argc, char ** argv)
{
// Our default function values get set here
SetFunction(FUNCTION_BUNNY, std::make_shared<OldBunny>());
std::cout << "before:" << std::endl;
CallFunction(FUNCTION_BUNNY);
// Now let's update an entry in our function table to do something different!
FunctionSharedPointer op = GetFunction(FUNCTION_BUNNY);
FunctionSharedPointer np = std::make_shared<NewBunny>(op);
SetFunction(FUNCTION_BUNNY, np);
std::cout << "after:" << std::endl;
CallFunction(FUNCTION_BUNNY);
return 0;
}
void bunny()
{
cout << "The bunny jumped." << endl;
}
void oldBunny()
{
bunny();
}
void newBunny()
{
bunny();
cout << "The bunny also ran." << endl;
}
#define bunny newBunny
int main()
{
bunny();
return 0;
}
If you don't need oldBunny(), just remove it.
So, I've got this situation:
#include "ActionLog.h"
class Library{
ActionLog aLog;
// ... the rest of it is private, mind you :D
public:
Library(...);
void addBook(...);
void removeBook(...);
// ... aaand there's a whole bunch of these :)
};
Now, class ActionLog has a public method void log(...);. It should, once implemented, record the beginning of any activity listed as a method of class Library (and eventually it's success/failure, which is optional).
I'm wondering this: Is there some more elegant way of making every class Library's method call the aLog.log(...); method when/before it starts executing? By "elegant" I mean other than just calling it explicitly in every single method...
I am aware of the Python version of the solution for the similar problem, but I'm not familiar with Python, so I'm not even sure that the same class-related principles apply.
C++ doesn't have any means of reflection built-in. There's no way to list methods neither in runtime, nor in compile-time. The best you can do is to hide logging into some #define that you will use to define every method, but preprocessor usage is an antipattern in modern C++.
Stick to the current approach.
As polkovnikov.ph said, without reflection you wouldn't be able to use the python's approach to this.
Just for fun I am going to leave this here but I wouldn't recommend its use:
#include <iostream>
class Logger
{
public:
void log(std::string entry)
{
std::cout << entry << std::endl;
}
};
class A
{
Logger mylog;
public:
void foo()
{
std::cout << "Doing foo" << std::endl;
}
Logger& getLogger()
{
return mylog;
}
};
#define CALL_FUNC_AND_LOG(obj,func) \
{ obj.getLogger().log("Logging "#func); obj.func(); }
int main()
{
A a;
CALL_FUNC_AND_LOG(a,foo);
return 0;
}
http://ideone.com/q0VHj6
Or another version that automatically logs the end of scope of the method.
#include <iostream>
class Logger
{
std::string _entry;
public:
Logger(std::string entry)
{
_entry = entry;
std::cout << "Starting execution of " << entry << std::endl;
}
~Logger()
{
std::cout << "Ending execution of " << _entry << std::endl;
}
};
class A
{
public:
void foo()
{
std::cout << "Doing foo" << std::endl;
}
};
#define CALL_FUNC_AND_LOG(obj,func) \
{ \
Logger _mylogger(""#func); \
obj.func(); \
\
}
int main()
{
A a;
CALL_FUNC_AND_LOG(a,foo);
return 0;
}
http://ideone.com/DHf3xu
I have a class foo. Operations on foo require a call to foo::open(), a number of foo::write(), and must end with a foo::close() call:
#include <iostream>
class foo
{
public:
foo()
{
std::cout << "foo::foo()" << std::endl;
}
~foo()
{
std::cout << "foo::~foo()" << std::endl;
}
void open()
{
std::cout << "foo::open()" << std::endl;
}
void close()
{
std::cout << "foo::close()" << std::endl;
}
void write(const std::string& s)
{
std::cout << "foo::write(" << s << ")" << std::endl;
}
private:
// state that must be retained for entire lifetime of object
};
static void useFoo(foo& my_foo)
{
my_foo.open();
my_foo.write("string1");
my_foo.write("string2");
my_foo.close();
}
int main( int argc, char* argv[] )
{
foo my_foo;
useFoo(my_foo);
useFoo(my_foo);
}
As expected, this outputs the following:
foo::foo()
foo::open()
foo::write(string1)
foo::write(string2)
foo::close()
foo::open()
foo::write(string1)
foo::write(string2)
foo::close()
foo::~foo()
I want to give users of my class foo a way of ensuring that they don't forget to call foo::close(), and to ensure that foo::close() gets called if an exception happens. I can't use foo's destructor as foo must continue to exist after a foo::close(), ready for the next foo::open().
I came up with this RAII implementation:
#include <iostream>
class foo
{
public:
class opener
{
public:
explicit opener(foo& my_foo):foo_(my_foo)
{
foo_.open();
};
~opener()
{
foo_.close();
};
private:
foo& foo_;
};
foo()
{
std::cout << "foo::foo()" << std::endl;
}
~foo()
{
std::cout << "foo::~foo()" << std::endl;
}
void open()
{
std::cout << "foo::open()" << std::endl;
}
void close()
{
std::cout << "foo::close()" << std::endl;
}
void write(const std::string& s)
{
std::cout << "foo::write(" << s << ")" << std::endl;
}
opener get_opener()
{
return(opener(*this));
}
private:
// state that must be retained for entire lifetime of object
};
static void useFoo(foo& my_foo)
{
foo::opener my_foo_opener = my_foo.get_opener();
my_foo.write("string1");
my_foo.write("string2");
}
int main( int argc, char* argv[] )
{
foo my_foo;
useFoo(my_foo);
useFoo(my_foo);
}
For simplicity I haven't included the obvious improvement of having the foo::opener class expose the foo::write() method, though in a real object I'd do this to prevent a write() being possible before an open().
EDIT As Nawaz points out below, a real class would also need a copy constructor and assignment operator.
This seems quite a lot of boilerplate just to ensure that a close() gets called. Two questions arise:
Is this still simpler than forcing the users of my class to use a try/catch?
Is there a simpler way to achieve what I want: provide the basic exception guarantee and ensure that close() always follows open()?
The nested class opener should implement the copy-semantics, as the default code generated by the compiler would produce undesirable result, if I correctly understood your intention.
So please implement copy-constructor, and copy-assignment.
Or alternatively, you may want to disable copy-semantic altogether, by making their declarations1 private, much like implementation of all standard stream classes. I would prefer this approach.
1. Note that you don't need to define them. Just declaring them in the private section is enough.
Can close ever fail? If it can, then you're going to need to take extra care regardless of approach. I think the RAII way is simpler than forcing exception handling/closing on your users though.
Is foo really so complex (or is it a global?) to create and destroy that you can't just have its destructor call close instead of using the opener to do the matching open/close?
Or if this is implementing some sort of transaction semantics I can't see a simpler way than the opener class (but as noted in other answers you probably want to disable copying and assignment of the opener class).
I think you should separate your concerns:
one class to store the state that is carried throughout
one class to handle the transient state within a open/close, which also takes care of all the "transient" operations like write
The "transient" class takes the "data" class as parameter (by reference) and will update it during the various method calls.
Then you can use typical RAII on the transient class and still have state propagated throughout.
This is a classic case for using RAII. Do use the constructor and destructor: if you want to open() again, instantiate a new foo. The idea of RAII is that an instantiation represents a single resource use. That's how you get the guarantee for resource cleanup.
struct foo {
foo() { open(); }
~foo() { close(); }
void write(const std::string& s);
private: // or public
foo(const foo&);
foo& operator=(const foo&);
};
// ...
{ foo fooa;
fooa.write("hello 0");
} { foo foob;
foob.write("hello 1");
}
You could add a flag to the class, that is set to true if you called open() and to false if you called close(). If open() is called you can check if the flag is true or false and and close if you need to do so before proceeding.
Suppose I have an RAII-style C++ class:
class StateSaver
{
public:
StateSaver(int i) { saveState(); }
~StateSaver() { restoreState(); }
};
...to be used like so in my code:
void Manipulate()
{
StateSaver save(1);
// ...do stuff that modifies state
}
...the goal being to enter some state, do stuff, then leave that state when I leave that scope. Is there a way to make this typo not compile (or warn, or somehow complain so that the mistake can be noticed)?
void Manipulate()
{
StateSaver(1); // ruh-roh, state saved and immediately restored!
// ...do stuff that modifies state
}
I'm not aware of anything in C++ itself which I could use to prevent this, but that doesn't mean it doesn't exist. If there isn't anything in C++, compiler-specific extensions would be acceptable. I'm primarily interested in anything targeting gcc and msvc (someday icc, ideas for other compilers welcome but less likely to be useful) so hacks for any of them would be useful (abstracted into appropriately #ifdef'd macro definitions, of course).
I'm not sure if anything can be done at compile-time. For a run-time check, you could do this:
struct SaveMatrix
{
SaveMatrix(const SaveMatrix& that) {
assert(this == &that);
glPushMatrix();
}
~SaveMatrix() { glPopMatrix(); }
};
Which requires the client to write:
SaveMatrix sm(sm);
and there's no way to do the same for a temporary without binding it to an identifier (at which point it's no different from an auto variable).
SaveMatrix save(); doesn't define an object either. It declares a function.
There's very little you can do to prevent others (or yourself, FTM) from doing something else than they wanted to. The only thing I can think of is not writing the code itself, but writing a macro instead.
#define SAVE_MATRIX SaveMatrix save ## __LINE__
However, this is quite ugly. OTOH, it does catch the error at compile-time.
I actually had to tweak my solution in a bunch of ways from the variant Waldo posted, but what I eventually got to is a macro-ized version of:
class GuardNotifier
{
bool* notified;
public:
GuardNotifier() : notified(NULL) { }
void init(bool* ptr) { notified = ptr; }
~GuardNotifier() { *notified = true; }
};
class GuardNotifyReceiver
{
bool notified;
public:
GuardNotifyReceiver() : notified(false) { }
void init(const GuardNotifier& notifier)
{ const_cast<GuardNotifier&>(notifier).init(¬ified); }
~GuardNotifyReceiver() { assert(notified); }
};
class StateSaver
{
GuardNotifyReceiver receiver;
public:
StateSaver(int i,
const GuardNotifier& notifier = GuardNotifier())
{
receiver.init(notifier)
saveState();
}
~StateSaver()
{
restoreState();
}
};
The class can never tell if it was instantiated as a temporary (SaveMatrix()) or as a variable (SaveMatrix save;). I think the best way to stop the programmer doing that without stack or macro hacks is to force a member function call after construction, eg:
class RAII
{
public:
bool valid;
RAII()
: valid(false)
{
cout << "RAII ctor" << endl;
}
void Do()
{
valid = true;
}
~RAII()
{
assert(valid);
cout << "RAII dtor" << endl;
}
};
This then works as follows:
{
// Intended use
RAII raii;
raii.Do();
cout << "Some task" << endl;
}
{
// Woops: forgot Do()
RAII raii;
cout << "Some task" << endl;
}
{
// Woops: forgot Do()
RAII();
cout << "Some task" << endl;
}
{
// Programmer shot self in foot, hopefully the act of typing this would make them realise that
RAII().Do();
cout << "Some task" << endl;
}