I have a simple GUI program that uses a custom stringstream to redirect output from the console to a text field in the GUI (under some circumstances). currently. the window redraws any time I hit enter, but it's possible that output could be generated at other times. Is there a way to register a function with the stringstream that gets executed every time the << operator is used on the stream?
NOTE
I should have pointed out that I cannot use C++11 in my solution. the machines on which this will be compiled and run will not have c++11 available.
Personally, I wouldn't use an std::ostringstream (or even an std::stringstream) for this at all! Instead, I would create my own stream buffer taking care of sending the data to the GUI. That is, I'd overwrite std::streambuf::overflow() and std::streambuf::sync() to send the current data to the GUI. To also make sure that any output is sent immediately, I'd set up an std::ostream to have std::ios_base::unitbuf set. Actually, sending the changes to a function is quite simple, i.e., I'll implement this:
#include <streambuf>
#include <ostream>
#include <functional>
#include <string>
#include <memory>
#include <iostream> // only for testing...
#if HAS_FUNCTION
typedef std::function<void(std::string)> function_type;
#else
class function_type
{
private:
struct base {
virtual ~base() {}
virtual base* clone() const = 0;
virtual void call(std::string const&) = 0;
};
template <typename Function>
struct concrete
: base {
Function d_function;
concrete(Function function)
: d_function(function) {
}
base* clone() const { return new concrete<Function>(this->d_function); }
void call(std::string const& value) { this->d_function(value); }
};
std::auto_ptr<base> d_function;
public:
template <typename Function>
function_type(Function function)
: d_function(new concrete<Function>(function)) {
}
function_type(function_type const& other)
: d_function(other.d_function->clone()) {
}
function_type& operator= (function_type other) {
this->swap(other);
return *this;
}
~function_type() {}
void swap(function_type& other) {
std::swap(this->d_function, other.d_function);
}
void operator()(std::string const& value) {
this->d_function->call(value);
}
};
#endif
class functionbuf
: public std::streambuf {
private:
typedef std::streambuf::traits_type traits_type;
function_type d_function;
char d_buffer[1024];
int overflow(int c) {
if (!traits_type::eq_int_type(c, traits_type::eof())) {
*this->pptr() = traits_type::to_char_type(c);
this->pbump(1);
}
return this->sync()? traits_type::not_eof(c): traits_type::eof();
}
int sync() {
if (this->pbase() != this->pptr()) {
this->d_function(std::string(this->pbase(), this->pptr()));
this->setp(this->pbase(), this->epptr());
}
return 0;
}
public:
functionbuf(function_type const& function)
: d_function(function) {
this->setp(this->d_buffer, this->d_buffer + sizeof(this->d_buffer) - 1);
}
};
class ofunctionstream
: private virtual functionbuf
, public std::ostream {
public:
ofunctionstream(function_type const& function)
: functionbuf(function)
, std::ostream(static_cast<std::streambuf*>(this)) {
this->flags(std::ios_base::unitbuf);
}
};
void some_function(std::string const& value) {
std::cout << "some_function(" << value << ")\n";
}
int main() {
ofunctionstream out(&some_function);
out << "hello" << ',' << " world: " << 42 << "\n";
out << std::nounitbuf << "not" << " as " << "many" << " calls\n" << std::flush;
}
A fair chunk of the above code is actually unrelated to the task at hand: it implements a primitive version of std::function<void(std::string)> in case C++2011 can't be used.
If you don't want quite as many calls, you can turn off std::ios_base::unitbuf and only sent the data upon flushing the stream, e.g. using std::flush (yes, I know about std::endl but it unfortunately is typically misused to I strongly recommend to get rid of it and use std::flush where a flush is really meant).
In order to do this you should create your own streambuf class. streambuf classes represent IO devices and each one takes care of the various issues specific to that kind of device. The standard defines a streambuf for files and another for strings. Network access would use another, and output to a GUI should also be represented as another kind of device if you're going to use streams at all.
Writing an appropriate streambuf class isn't trivial and seems to be kind obscure, but there are resources out there. The C++ Standard Library - A Tutorial and Reference has a small section on this. Standard C++ IOStreams and Locales: Advanced Programmer's Guide and Reference provides in-depth information. A search for subclassing basic_streambuf will also turn up some free resources online.
If you haven't already, can you derive a subclass from stringstream and overload its stream insertion operator to generate events?
Pseudocode:
class AlertingStream : public stringstream
{
ostream& operator << (type)
{
for (each listener in listeners)
{
listener.notify();
}
perform insertion;
return *this;
}
}
Related
I'm facing maybe a non-problem with some C++ class design, mostly because I need to integrate a database into my system. I've got a base class that has some child classes. I find it redundant to have a member called type which is an enum which described the type of child it is. Example
enum FooTypes {
kFooTypeGeneric,
kFooTypeA,
kFooTypeB
};
class Foo {
public:
Foo(FooTypes type):type(type){}
FooTypes type;
};
class FooA : public Foo {
public:
FooA():Foo(kFooTypeA){}
};
class FooB : public Foo {
public:
FooB() :Foo(kFooTypeB) {}
};
The reason that I feel forced to maintain an enum is because owners of Foos want to store what they have created into a database table. If the system reboots, they should be able to look into their own table and say, "Oh yeah, I have a FooA that I need to initialize", and that can only really be done by setting a column called "FooType" to 1 in this case.
I'm just wondering if this way of giving child classes a type that is part of an enum that they then must know about is bad design. It seems redundant among other things.
You could use polymorphism and use overridden streaming functions for the derived classes.
You'd then need a factory function to create different derived object depending on what you read from the database.
Here's a small example where the database is an std::istringstream holding what has previously been saved.
#include <iostream>
#include <memory>
#include <sstream>
#include <string>
#include <unordered_map>
#include <vector>
// An abstract base class for all entities you can store in the database
struct Foo {
virtual ~Foo() = default;
virtual void serialize(std::ostream&) const = 0; // must be overridden
virtual void deserialize(std::istream&) = 0; // must be overridden
};
// streaming proxies, calling the overridden serialize/deserialize member functions
std::ostream& operator<<(std::ostream& os, const Foo& f) {
f.serialize(os);
return os;
}
std::istream& operator>>(std::istream& is, Foo& f) {
f.deserialize(is);
return is;
}
//--------------------------------------------------------------------------------------
class FooA : public Foo {
public:
void serialize(std::ostream& os) const override {
// serializing by streaming its name and its properties
os << "FooA\n" << a << ' ' << b << ' ' << c << '\n';
}
void deserialize(std::istream& is) override {
// deserializing by reading its properties
if(std::string line; std::getline(is, line)) {
std::istringstream iss(line);
if(not (iss >> a >> b >> c)) is.setstate(std::ios::failbit);
}
}
private:
int a, b, c;
};
class FooB : public Foo {
public:
void serialize(std::ostream& os) const override {
os << "FooB\n" << str << '\n';
}
void deserialize(std::istream& is) override {
std::getline(is, str);
}
private:
std::string str;
};
//--------------------------------------------------------------------------------------
// A factory function to create derived objects from a string by looking it up in a map
// and calling the mapped functor.
//--------------------------------------------------------------------------------------
std::unique_ptr<Foo> make_foo(const std::string& type) {
static const std::unordered_map<std::string, std::unique_ptr<Foo>(*)()> fm = {
{"FooA", []() -> std::unique_ptr<Foo> { return std::make_unique<FooA>(); }},
{"FooB", []() -> std::unique_ptr<Foo> { return std::make_unique<FooB>(); }},
};
if(auto it = fm.find(type); it != fm.end()) return it->second(); // call the functor
throw std::runtime_error(type + ": unknown type");
}
//--------------------------------------------------------------------------------------
// Deserialize all Foos from a stream
//--------------------------------------------------------------------------------------
std::vector<std::unique_ptr<Foo>> read_foos(std::istream& is) {
std::vector<std::unique_ptr<Foo>> entities;
std::string type;
while(std::getline(is, type)) { // type is for example "FooA" here
// Call make_foo(type), put the result in the vector and
// stream directly to the added element (C++17 or later required)
if(not (is >> *entities.emplace_back(make_foo(type)))) {
throw std::runtime_error(type + ": deserializing failure");
}
}
return entities;
}
//--------------------------------------------------------------------------------------
int main() {
std::istringstream db(
"FooA\n"
"1 2 3\n"
"FooB\n"
"Hello world\n"
);
auto entities = read_foos(db);
std::cout << "serialize what we got:\n";
for(auto& fooptr : entities) {
std::cout << *fooptr;
}
}
Output:
serialize what we got:
FooA
1 2 3
FooB
Hello world
This is fine. Generally you want to avoid the need to "know" a type in a polymorphic hierarchy ‐ if you're fine with the performance of virtual dispatch, it should be all you need in a good design.
But sometimes you do need a strong mapping (say, for passing to some external resource), and having an enum identify the actual "type" of an instance saves you having a string of dynamic_cast to do the same job.
You could have the best of both worlds, and make a virtual function that returns the right enum for the class. But then frankly you're forcing a loss of performance for nothing.
I would like to define something like a new cout, which I can use to log my data:
some_type cout2( Message_type message ){
cout << message;
logfile.save(message);
}
so I will use it with
cout2 << "some message" << endl;
Up to now I was not able to find out how the code above has to look like exactly.
Thanks for your help.
You can create your own logger like:
class Logger {
public:
Logger(std::string const& filename)
: stream_(filename, std::ofstream::out | std::ofstream::app)
{
if (!stream_) {
// Error...
}
}
Logger& operator<<(std::string const& str) {
std::cout << str;
stream_ << str;
return *this;
}
private:
std::ofstream stream_;
};
Generally speaking, classes from C++ standard library are not designed to be derived, and that is true for stream classes.
So IMHO, it is better to specify what method you will need on your cout2 object, and then:
design a class containing a ostream& object, initialized in ctor
delegate actual output to that internal object
do whatever log you need in your methods
You should use templated a operator << to be able to easily process any class that std::ostream can process.
class LogStream {
std::ostream& out;
Logfile logfile;
LogStream(std::ostream& out, /* param for logfile initialization */ ...)
: out(out), logfile(...) {}
... // other useful methods for state
};
template<typename T>
LogStream& operator << (LogStream& out, T val) {
out.out << message;
// should first test whether T is manipulator, and choose whether and how it should be logged
logfile.save(message);
}
You don't want to modify std::cout.
Instead, you want to create a specialised std::streambuf that writes to two buffers rather than one. For example;
#include <streambuf>
template <typename char_type,
typename traits = std::char_traits<char_type> >
class basic_teebuf:
public std::basic_streambuf<char_type, traits>
{
public:
typedef typename traits::int_type int_type;
basic_teebuf(std::basic_streambuf<char_type, traits> * sb1,
std::basic_streambuf<char_type, traits> * sb2)
: sb1(sb1)
, sb2(sb2)
{
}
protected: // override virtuals inherited from std::basic_streambuf
virtual int sync()
{
int const r1 = sb1->pubsync();
int const r2 = sb2->pubsync();
return r1 == 0 && r2 == 0 ? 0 : -1;
}
virtual int_type overflow(int_type c)
{
int_type const eof = traits::eof();
if (traits::eq_int_type(c, eof))
{
return traits::not_eof(c);
}
else
{
char_type const ch = traits::to_char_type(c);
int_type const r1 = sb1->sputc(ch);
int_type const r2 = sb2->sputc(ch);
return
traits::eq_int_type(r1, eof) ||
traits::eq_int_type(r2, eof) ? eof : c;
}
}
private:
std::basic_streambuf<char_type, traits> * sb1;
std::basic_streambuf<char_type, traits> * sb2;
};
typedef basic_teebuf<char> teebuf;
Then you need to create a specialised ostream which uses such a buffer
#include <ostream>
class teestream : public std::ostream
{
public:
// Construct an ostream which tees output to the supplied
// ostreams.
teestream(std::ostream & o1, std::ostream & o2);
private:
teebuf tbuf;
};
teestream::teestream(std::ostream & o1, std::ostream & o2)
: std::ostream(&tbuf)
, tbuf(o1.rdbuf(), o2.rdbuf())
{
}
All the above does is create a specialised std::ostream that uses our specialised buffer, which in turn makes use of two buffers.
Now, our teestream needs to be initialised using two streams. For example
#include <fstream>
#include <iostream>
// include the preceding definition of teestream here
int main()
{
std::ofstream logfile("hello-world.log");
teestream tee(std::cout, logfile);
// tee is now a stream that writes the same output to std::cout and logfile
tee << "Hello, world!\n";
return 0;
}
The advantage of this is that all stream insertions (operator <<) will work with our teestream - even for classes with overloaded versions.
When main() returns, the streams will also be closed cleanly.
I've written the specalised streambuf as a template (std::streambuf is a specialisation of a templated class named std::basic_streambuf). For generality, it would probably be better to do the same with the stream (using the fact that std::ostream is also a specialisation of a templated std::basic_ostream). I leave that sort of generalisation as an exercise.
The logging systems I've seen, built on this idea look something like this:
#define MY_PRINT(x, ...) \
{ \
fprintf(logFile, x, ##__VA_ARGS__); \
fflush(acuLogFile); \
}
And you would use it like:
MY_PRINT("this is just a test\n");
Even though this is the C way of doing things, it is very versatile and work in C++ as well.
You just have to use your newly define print function everywhere in the code.
Maybe you should have an instance based logger with a .log() method, that, depending on implementation can log to file, write to stdout etc, rather than trying to overload free functions from std namespace?
Your intent will be clearer and it will be more object orientated.
In fact here is an example of a pretty cookie-cutter event logger I wrote recently, if that helps you to understand the sort of thing I'm talking about. My design allows for dependnacy injection, as well as keeping boring decisions about how something should be formatted as output and where it should go (stdout or file etc) in the logger.
Of course you can define your own cout.
First you need a class which can handle the << operator and contains an fstream and an ostream (like cout).
class logstream
{
private:
fstream *filestream;
ostream *cout;
public:
logstream(fstream* filestream, ostream* cout)
{
this->cout = cout;
this->filestream = filestream;
}
string operator<< (char* s)
{
*cout << s;
*filestream << s;
return s;
}
};
To use this, simply initialize it with cout and a fstream.
fstream lout = fstream("Filename", ios::app);
logstream cout = logstream(&lout, &std::cout);
And now you have what you wanted.
cout << "message";
EDIT: Don't forget to include
#include <iostream>
#include <fstream>
and
using namespace std;
I have a 3rd party (logging) class that overloads the << operator. The client code using this logger class can use this by calling one of the pre-defined macros. As an example:
//logs can be filtered based on this module id string
LOGGER_INFO("MODULE_ID_STR") << "Logging at info level";
I'd like to extend this feature wherein the class/module using this 3rd party logger does not have to include the module id string each time. Meaning - the client code should set the module id string once and then be able to do this:
cLogger.INFO << "Logging at info level";
The above call should internally use the registered module id string registered earlier and then use that to make the actual 3rd party log call. So can this be done elegantly in C++ by overloading the << operator for each of the log levels.
Some additional details...I started out by doing this:
This is the class that extends the functionality of the 3rd party logger:
class LoggerEx
{
public:
LoggerEx(const std::string &moduleToLog)
{
m_ModuleID = moduleToLog;
};
virtual ~LoggerEx() {};
class Debug
{
//overload the << operator (how to write this..??)
LOGGER_INFO(m_ModuleID) << "Logging at info level";
};
class Info
{
//overload the << operator
};
//Note that there could be more such levels
// (INFO, WARN, ERROR, TRACE, FATAL, etc).
public:
Debug DEBUG;
Info INFO;
protected:
std::string m_ModuleID
};
Some client code using the logger class should be allowed to do this...
class Xyz
{
public:
Xyz() : l("Xyz")
{}
void doSomething()
{
l.DEBUG << "Doing something";
}
protected:
Logger l;
};
Another client class...
class Mno
{
public:
Xyz() : l("Mno")
{}
void processSomething()
{
l.INFO << "Process something";
}
protected:
Logger l;
};
Since the original logger supports several data types (int, float, chars, std::string), will the above be the approach, or are there any other ideas/solutions to do this more elegantly in C++ without writing a full blown wrapper (or duplicating code) to the logger?
Thanks...
This is actually harder than one might think, mostly because in a typical logging library, the LOGGER_INFO macro or its equivalents do more than just giving you a stream. Here's a typical macro from Boost:
#define BOOST_LOG_STREAM_WITH_PARAMS_INTERNAL(logger, rec_var, params_seq)\
for (::boost::log::record rec_var = (logger).open_record((BOOST_PP_SEQ_ENUM(params_seq))); !!rec_var;)\
::boost::log::aux::make_record_pump((logger), rec_var).stream()
A quick look at this code shows that it creates a new record, creates a pump, gets the stream from this pump, and your << "log text here" << " more log stuff" calls actually operates on that stream. It is when the pump and record gets destructed, at the end of the statement, that the message actually get pushed out into a single log entry, which makes sense when you think of it - you'd expect LOGGER_INFO(m_ModuleID) << "Logging at info level" << "more text"; to produce one log entry instead of two.
Thus a naive implementation like
class LoggerEx
{
public:
LoggerEx(const std::string &moduleToLog) : Debug(moduleToLog)
{ }
~LoggerEx() {}
class Debug
{
private:
std::string m_ModuleID;
public:
Debug(const std::string &module) : m_ModuleID(module) {}
template <typename T>
const Debug & operator << (const T& thing_to_log) const {
LOGGER_INFO(m_ModuleID) << thing_to_log;
return *this;
}
};
public:
Debug DEBUG;
};
will only work if you only use << once per statement in your logging code.
One possible way of getting around it would be to use an internal stream to store the log-entry-in-making:
class LoggerEx
{
public:
LoggerEx(const std::string &moduleToLog) : m_module(moduleToLog)
{ }
~LoggerEx() {}
class Debug
{
private:
std::string m_ModuleID;
std::stringstream m_ss;
public:
Debug(const std::string &module) : m_ModuleID(module) {}
Debug(const Debug &other) : m_ModuleID(other.m_ModuleID) {}
~Debug() {
std::string str = m_ss.str();
if(!str.empty())
LOGGER_INFO(m_ModuleID) << str;
}
template <typename T>
Debug & operator << (const T& thing_to_log) {
m_ss << thing_to_log;
return *this;
}
};
public:
Debug DEBUG() { return Debug(m_module);}
private:
std::string m_module;
};
It would be called like
l.DEBUG() << "Some stuff " << some_number << " some more stuff";
The idea is that the DEBUG() call produces a temporary object; your operator << calls on that temporary object writes stuff into the stringstream, and at the end of the line, when the temporary object gets destructed, the things in the stringstream get pushed out to the logging library.
Continuing from the question that I asked here: C++ multi-dimensional data handling
In my example: I have many Chips, each Chip has many Registers, each Register has many Cells, and each Cell has many Transistors. I asked whether to use one complex STL container for them, or to implement full classes for them. And, as advised, I chose to implement full classes for them. I have:
class Chip
{
map<RegisterLocation, Register> RegistersPerLocation;
};
class Register
{
map<CellLocation, Cell> CellsPerLocation;
};
// etc..
Now, I need to fill the data to the classes, and I can't decide: Should reading the data be responsibility of these classes, or should they just wrap the containers and the reading will be done outside.
I mean I have to choose one of the following: Either:
class Chip
{
map<RegisterLocation, Register> RegistersPerLocation;
public:
void AddRegisterPerLocation(RegisterLocation, Register);
};
void ReadChipData(Chip & chip)
{
for (RegisterLocation loc = 0; loc < 10; loc++)
{
Register reg;
ReadReg(reg);
chip.AddRegisterPerLocation(loc, reg);
}
}
void ReadReg(Register & reg)
{
for (CellLocation loc = 0; loc < 10; loc++)
{
Cell cell;
ReadCell(cell);
reg.AddRegisterPerLocation(loc, cell);
}
}
//etc...
Or:
class Chip
{
map<RegisterLocation, Register> RegistersPerLocation;
public:
void ReadData();
};
void Chip::ReadData()
{
for (RegisterLocation loc = 0; loc < 10; loc++)
{
Register reg;
reg.ReadData();
RegistersPerLocation[loc] = reg;
}
}
//etc...
void ReadChipData(Chip & chip)
{
chip.ReadData();
}
Thank you.
If you are thinking of tying the reader/writer to the domain objects in order to follow the principle of encapsulation, you are correct to a certain extent. But remember: You bind not just any action, but a valid behavior. Valid as in makes sense for the object in the domain.
Another thing to keep in mind is separation of concerns. Serializability is not a Chip's intrinsic behavior -- modeling that into the domain object would be unfair IMO. YMMV.
Separate the reading(and writing) from the classes. As the library does. Expose iterators if you have to. And you can overload the '<<' and '>>' operators for syntactic sugar ;)
A minor nit on the classes -- a template based approach looks so promising.
Here's some code I cooked up: you can try the following as well.
(I've successfully compiled and run this on a MS VS2005 but check it out on your system. Also, can someone fix the tabbing -- feeling too lazy to do this :P)
/*+-----------8<----------------------------8<-----------+*/
#include <vector>
#include <iostream>
#include <algorithm>
#include <map>
#include <iterator>
/* mother template */
template<class _Item>
struct Hardware
{
Hardware() : _myCont(2 + ::rand() % 5) {}
private:
typename vector<_Item> _myCont;
// i/o friends
template<class _Item>
friend ostream& operator<<(ostream& output,
const Hardware<_Item>& me);
template<class _Item>
friend istream& operator>>(istream& in,
const Hardware<_Item>& me);
};
/* actual domain objects */
/* base object */
struct Transistor {
};
/* built objects */
typedef Hardware<Transistor> Cell;
typedef Hardware<Cell> Register;
typedef Hardware<Register> Chip;
/* poorman's introspection utility */
template<class T>
const char *who() { return ""; }
template<>
const char *who<Transistor>() { return "Transistor"; }
template<>
const char *who<Cell>() { return "Cell"; }
template<>
const char *who<Register>() { return "Register"; }
template<>
const char *who<Chip>() { return "Chip"; }
/* writer/serialize out */
template<class T>
ostream& operator<<(ostream& out, const Hardware<T>& hw) {
// whatever you need to do to write
// os << chip works fine, because you will provide a specialization
out << "[ " << ::who<Hardware<T>>() << " ]\n\t";
std::copy(hw._myCont.begin(), hw._myCont.end(),
std::ostream_iterator< T >(std::cout, "\n\t"));
return out;
}
/* specialize for base object */
ostream& operator<< (ostream& out, const Transistor& hw) {
out << "[ " << ::who<Transistor>() << " ]\n";
return out;
}
/* reader/serialize in */
template<class T>
istream& operator>>(istream& in, const Hardware<T>& hw) {
// whatever you need to do to read
// similarly in >> chip works fine,
return in;
}
// driver showing relationships
// Chip -> Register -> Cell -> Transistor
int main() {
Transistor t;
std::cout << t << std::endl;
Cell ce;
std::cout << ce << std::endl;
Register r;
std::cout << r << std::endl;
Chip C;
std::cout << C << std::endl;
}
/*+-----------8<----------------------------8<-----------+*/
Caveat: Haven't tested, so there may be quite a few compiler errors/warnings. But this should give you an idea of what I am trying to say.
Making classes responsible for their serialization is better - once you change the class fields you have to change the same class serializeation method, not some reader/writer code over there.
I've been trying to implement a C#-like event system in C++ with the tr1 function templates used to store a function that handles the event.
I created a vector so that multiple listeners can be attached to this event, i.e.:
vector< function<void (int)> > listenerList;
I'd like to be able to remove a handler from the list to stop a listener receiving events.
So, how can I find the entry in this list that corresponds to a given listener? Can I test if a 'function' object in the list refers to a particular function?
Thanks!
EDIT: Having looked into the boost::signal approach, it seems it's probably implemented using a token system as some of you have suggested. Here's some info on this. An observer retains a "Connection" object when they attach to an event, and this connection object is used to disconnect if needed. So it looks like whether you use Boost or roll your own with tr1, the basic principle's the same. i.e. it will be a bit clumsy :)
I don't know if you're locked into std C++ and tr1, but if you aren't, it seems like your problem could be completely avoided if you just used something like boost::signal and boost::bind to solve your original problem - creating an event system - instead of trying to roll your own.
Okay, you got me working. The hard part is trying to match the exact usage pattern of C# events. If you skip that, there are MUCH easier ways to do what you're asking. (My co-worker Jason uses a Notifier object all over the place.) Anyway, here's the incredibly boring code which does what you want. Unfortunately, it doesn't allow you to pass parameters from the Subject to the Observer. To do that, you'd need to add even more smarts.
#include "stdafx.h"
#include <iostream>
#include <string>
#include <list>
#include <algorithm>
#include <boost/tr1/functional.hpp>
#include <boost/tr1/memory.hpp>
using namespace std;
using namespace std::tr1;
template <typename T>
class ObserverHandle
{
public:
typedef boost::function<void (T*)> const UnderlyingFunction;
ObserverHandle(UnderlyingFunction underlying)
: _underlying(new UnderlyingFunction(underlying))
{
}
void operator()(T* data) const
{
(*_underlying)(data);
}
bool operator==(ObserverHandle<T> const& other) const
{
return (other._underlying == _underlying);
}
private:
shared_ptr<UnderlyingFunction> const _underlying;
};
class BaseDelegate
{
public:
virtual bool operator==(BaseDelegate const& other)
{
return false;
}
virtual void operator() () const = 0;
};
template <typename T>
class Delegate : public BaseDelegate
{
public:
Delegate(T* observer, ObserverHandle<T> handle)
: _observer(observer),
_handle(handle)
{
}
virtual bool operator==(BaseDelegate const& other)
{
BaseDelegate const * otherPtr = &other;
Delegate<T> const * otherDT = dynamic_cast<Delegate<T> const *>(otherPtr);
return ((otherDT) &&
(otherDT->_observer == _observer) &&
(otherDT->_handle == _handle));
}
virtual void operator() () const
{
_handle(_observer);
}
private:
T* _observer;
ObserverHandle<T> _handle;
};
class Event
{
public:
template <typename T>
void add(T* observer, ObserverHandle<T> handle)
{
_observers.push_back(shared_ptr<BaseDelegate>(new Delegate<T>(observer, handle)));
}
template <typename T>
void remove(T* observer, ObserverHandle<T> handle)
{
// I should be able to come up with a bind2nd(equals(dereference(_1))) kind of thing, but I can't figure it out now
Observers::iterator it = find_if(_observers.begin(), _observers.end(), Compare(Delegate<T>(observer, handle)));
if (it != _observers.end())
{
_observers.erase(it);
}
}
void operator()() const
{
for (Observers::const_iterator it = _observers.begin();
it != _observers.end();
++it)
{
(*(*it))();
}
}
private:
typedef list<shared_ptr<BaseDelegate>> Observers;
Observers _observers;
class Compare
{
public:
Compare(BaseDelegate const& other)
: _other(other)
{
}
bool operator() (shared_ptr<BaseDelegate> const& other) const
{
return (*other) == _other;
}
private:
BaseDelegate const& _other;
};
};
// Example usage:
class SubjectA
{
public:
Event event;
void do_event()
{
cout << "doing event" << endl;
event();
cout << "done" << endl;
}
};
class ObserverA
{
public:
void test(SubjectA& subject)
{
subject.do_event();
cout << endl;
subject.event.add(this, _observe);
subject.do_event();
subject.event.remove(this, _observe);
cout << endl;
subject.do_event();
cout << endl;
subject.event.add(this, _observe);
subject.event.add(this, _observe);
subject.do_event();
subject.event.remove(this, _observe);
subject.do_event();
subject.event.remove(this, _observe);
cout << endl;
}
void observe()
{
cout << "..observed!" << endl;
}
private:
static ObserverHandle<ObserverA> _observe;
};
// Here's the trick: make a static object for each method you might want to turn into a Delegate
ObserverHandle<ObserverA> ObserverA::_observe(boost::bind(&ObserverA::observe, _1));
int _tmain(int argc, _TCHAR* argv[])
{
SubjectA sa;
ObserverA oa;
oa.test(sa);
return 0;
}
And here's the output:
doing event
done
doing event
..observed!
done
doing event
done
doing event
..observed!
..observed!
done
doing event
..observed!
done
FAQ #1 in the boost function documentation seems to address your question - and the easy answer is "no".
The proposal (section IIIb.) states they will not be comparable in any way. If you attach some extra information to them, you can easily identify each callback. For instance, if you simply define a struct wrapping the function pointer, you can remove them (assuming you have the same struct you inserted). You can also add some fields to the struct (like an automatically generated guid the client can hold on to) and compare against that.
If you are storing function pointers only (and not other functors that match the signature required), this is easy (see code below). But in general, the answer, like other posters have said, is no. In that case, you probably want to store your functors in a hash, as values, with keys being something the user supplies on adding and removing.
The code below demonstrates how to get the functor/pointer object that is to be called. To use it, you must know the exact type of the object to extract (i.e., the typeid of the type you specify must match the typeid of the contained functor/pointer).
#include <cstdio>
#include <functional>
using std::printf;
using std::tr1::function;
int main(int, char**);
static function<int (int, char**)> main_func(&main);
int
main(int argc, char** argv)
{
printf("%p == %p\n", *main_func.target<int (*)(int, char**)>(), &main);
return 0;
}
What about
map<key-type, function<void (int)> > listeners;
I had a similar problem and found a solution to it. I used some C++0x features, but only for convenience, they are not an essential part. Take a look here:
> Messaging system: Callbacks can be anything