QuoteOriginally posted by: outrun.. so this mechanism of disabling checking can be added to a V2 without breaking a V1 interface. The V2 interface will have an additional tag.NET uses Reflection and Attributes. Now that's maybe possible in MPL?

Here is an initial version of the popular Observer pattern using a less OO approach and using boost::function. I have tried to sum up some of the advantages. There may be disadvantages as it is tested against different kinds of applications. At some stage using signals is good but I was getting compiler error in some cases. So for the moment I stick to boost::function.For those who use C#, many of the conclusions hold as well since .NET delegates are the C# equivalent of boost(function, signals) AFAIK.Feedback welcome. Thanks./* Features of this solution vs GOF Observer 1. Non-intrusive and no inheritance needed 2. Observers implement a signature, not rigid Update() 3. No virtual functions 4. Observers can be 'any' function (global, member, lambda, function object); it is possible to reuse existing GOF Observer code by boost::bind 5. Objects be both observables and observers(this is thus the Propagator pattern) 6. No multiple inheritance needed 7. Use of "template template parameter" mechanism to use a different container from list<T> 8. Return type is generic and not just void 9. Arbitary data types supported (e.g. matrices, algorithmsa, other embedded patterns) 10. Other signatures possible (generic) 11. Dynamic registration/unregistration of observers 12. Boost libraries and C++ 11 13. Loose coupling between components; configuable; add and delete observers at run-time.*/

QuoteOriginally posted by: outrunthanks!I'm not sure if this is correct, but here is an idea I had:I've quite often used "std::sort" "std::map" etc with my own user-defined compare like below. Could you do the same for the f() in your example and eliminate the need of boost::function?It could be possible but why would you want to eiminate the need for boost function? it is a *protocol* and already subsumes any kind of function you throw at it. You can define any comparitor and use it to instantiate the boost function. It is the same as .NET delegate type vs delegate instance.Do you want to make the s/w so generic that even boost function has been templated away? If so, then the code will be very difficult to understand.The core issue is that we want to get away from GOF Observer and if people think this functional programming approach is better.edit: Somehow, I prefer using boost function to generic function objects because former are more robust.

QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunthanks!I'm not sure if this is correct, but here is an idea I had:I've quite often used "std::sort" "std::map" etc with my own user-defined compare like below. Could you do the same for the f() in your example and eliminate the need of boost::function?Not sure what this means, exactly.It could be possible but why would you want to eiminate the need for boost function? it is a *protocol* and already subsumes any kind of function you throw at it. You can define any comparitor and use it to instantiate the boost function. It is the same as .NET delegate type vs delegate instance.Do you want to make the s/w so generic that even boost function has been templated away? If so, then the code will be very difficult to understand.The core issue is that we want to get away from GOF Observer.I don't see it as "so generic that even..". The example I gave is not complicated is it, is simple plain C++, nothing fancy, no effort, right..? Anyone can use std::sort without having to install, use (and learn) boos::function. To me that is a benefit towards users of my code. So It's an honest question.I write two types of code:1) Application that perform tasks. For those I use boost.2) generic code / modules / libraries. For those I don't want to force dependency on boost unless is has a very obvious benefit (like not having to implement things have already been done in boost).I think you are in 1) and I in 2) when we talk about QFCL, and QFCL is both, because it has many levels. We had a discussion like this before, right? E.g. the container bindings is also an attempt of me to remove explicit dependencies of 3rd party -or self introduced- containers. That's the same thing...but let's stick to the purpose of you demo "The core issue is that we want to get away from GOF Observer", ..which is what you've demonstrated with your code Yes, very good. I am a library user.Actually, IMHO boost function should be in C++ 11. Functional programming is so useful in this context. QuoteAnyone can use std::sort without having to install, use (and learn) boos::function. To me that is a benefit towards users of my code. So It's an honest question.I see it takes people 10 minutes to learn function After that they apply it and that is ongoing.QuoteThe example I gave is not complicated is it, is simple plain C++, nothing fancy, no effort, right..? sort() is special case. Things become more tricky with other STL algorithms, e.g. inner_product.

QuoteOriginally posted by: outrunQuoteOriginally posted by: Cuchulainnsort() is special case. Things become more tricky with other STL algorithms, e.g. inner_product.I'll have see that (I believe you for now ). ..But what about "observer"?..anyway: maybe we shouldn't discuss this a-priori? Let's wait and see if things like this end up in core libraries (for which we have a set some goals regarding dependencies between internal and external libraries). It all started purely out of curiosity,.. and that was triggered by you posting some code for the sake of discussing it.The crucial flaw in GOF Observer pattern is that the observable has a pointer to observer's base class. With signals and function the observable talls to a delayed 'function' having a compatible signature. Then it can be instantiated by anything, as my code shows for lambda; we could use a global function instead.If you run the code you can see the effect.

Do C developers need to use OOP/GP for this pattern? No, they use global functions.

Quotemake it simpler and more generic by removing dependency on boost::function AFAI see at this moment there is nothing more generic than boost::function. Ergo, using it is (more than) OK.This assumption might be wrong but at the moment the idea seems to be holding up.

QuoteOriginally posted by: outrunYou pattern is fine.It would be nice to kick the tires by testing it against other libraries that use GOF.