QuoteOriginally posted by: tomodachiAre the signals in the MC project only for giving progress updates on the computation? That seems to have nothing to do with MC itself. Do you think it is possible to factor that out? Maybe a policy class or something might give people more choices.The design uses Boost Function and Signals as the glue between modules. The whole point is that they can be assigned to a policy or something or anything we wish to throw at them. They are _higher order functions_ HOF and in general terms subsume any offunction pointersmember functionslambda functionsstatic member functionsSo, write supplier code using HOF and consumers/configurators specialise to the above special kinds of functions. Signals can have multiple dynamic slots and they support plug and socketsftp://db.stanford.edu/pub/cstr/reports/csl/tr/95/674/CSL-TR-95-674.pdfA signal is just a function, really. So it is not scary.Using a software technique other than the above will reduce flexibility. This conclusion after some thinking/experiments on the different options.This is the single best solution imo at this moment. C# has the same in the form of delegates.QuoteCuch really likes it, and maybe he is onto something. You are free to start coding an present alternatives and compare pro's con's. There won't be consensus -that's not a goal-. Instead there will be choices between MC engines with those pro/cons. Cuch is using signals to glue various modules together run-time (I think) in a graph like way with 1:N relations between modules.Yes. And Boost Function/Bind as well.I am sure I am on to something if I may say so most humbly; software that looks like hardware. I just need to specify the interfaces and they (i.e. CONTRACTS) can be implemented by other team members.And each slot has a thread implementation. Robert and myself have done this in another non-QF application.

QuoteThis is the single best solution imo at this moment. C# has the same in the form of delegates.Indeed Sir,BTW, have you used QT signals and slots? Exactly the same concept with the benefit of having been around for much longer.

QuoteOriginally posted by: SierpinskyJanitorQuoteThis is the single best solution imo at this moment. C# has the same in the form of delegates.Indeed Sir,BTW, have you used QT signals and slots? Exactly the same concept with the benefit of having been around for much longer.Serp,I have had a deep look, indeed. Cool stuff. Anecdote tells that QT was the inspiration for Boost Signals(2).BTW Signals is more functional than delegates. I think there is no going back

QuoteOriginally posted by: outrunWe used publishers/subscriber in an algo trading engine, -that was the design-, and then we had various implementations of that design. We used signal if we needed runtime configuration, we used templates is it was compiletime configurable, we also used Linux sockets for inter process communication, and top sockets for inter-machine.So for me signals is a specific fine -but non dogmatic- implementation choice. The design is the graph idea.On top of that we had two different modes: event push and data-pull.Were you using the strict GOF/POSA (aka Observer) pattern?

In general, the classical OOP Observer pattern breaks down big time when the dependency graph becomes more complicated than a tree of depth ONE. Quantlib uses this approach and there many horror stories down the years of how developers in many areas tried to adapt it to complex cases. Classical Observer is a very bad pattern. I have a short list of 10 issues that we have come across with, each of which has been resolved by Signals.Signals(2) resolve many of these problems (and muuuuch more); even better the code is ready to run. Hence, one of the reason why I think this is correct. For complex graphs and cycle avoidance, Boost Graph can be used. //In Dutch, I am making a 'constatering', i am just relaying the experience with this pattern. Once the limitations are made explicit then we decide whether to use it, or not.

Some remarks/findings on SignalsQuote/* 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, algorithms, 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. Configurable; add and delete observers at run-time.*/

QuoteOriginally posted by: outrunI'm saying that signals is *library*, the design can also e.g. be done compile-time without using signals at all.First, we can design (on paper) to find the modules and interfaces, the use Boost to implement my design. Personally, I want to avoid using home-grown Observer; in general they are not robust. Of course, each to his own.QuoteTo me this reads the same as saying "I'm using boost graph library for my design", which is also an implementation choice, there are other ways to setup graphs.No, I am not saying that.Graph theory is a branch of mathematics. BGL is a library that realises data structures and algorithms from graph theory. I draw a clear distinction between the two.

.

.

QuoteOriginally posted by: CuchulainnQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunI'm saying that signals is *library*, the design can also e.g. be done compile-time without using signals at all.First, we can design (on paper) to find the modules and interfaces, the use Boost to implement my design.yes! But that's what you are doing already, right?I think the role of "signals" in your design was/is not clear to everyone and this single sentence already helps a lot: it's show that the two are not the same (design, and using signals) which wasn't always clear.Maybe you also use signals as a design concept (abstract of implementation) instead of a signals as a library choice (with its specific interfaces that you can look up in the code ref manual)? You mentioned software as hardware or something, that I liked a lot. In our algo-engine design we talked about publishers and subscribers (like newspapers) to keep the design talk free of specific implementation library choices. A publisher could have multiple subscribers etc. We tried many terminologies, but they kept causing confusion because we discussed the design on so many levels (including implementation possibilities) edit:E.g. can you define the design? You compare it in the context of GOF with the list of features that relate a lot to OO design element (like inheritance), but that's mainly because you compare it against OO. Can you also define it in itself? Can the design also be used in non-OO languages, -I'm saying yes- e.g. I can build an Excel worksheet and mark cell ranges as modules or variables, and link things up with cell references.Edit2:The hardware as software concept shows that it's about wel defined interfaces and communicating on those via a glue mechanism. It very suitable for various layers, also linking up modules running on different machines, and an alternative implementation of the same design could be done on top of asio, right?Here is a very good review of 3 different kinds of architectures. This is front-end to C++/C#ftp://db.stanford.edu/pub/cstr/reports/ ... 95-674.pdf QuoteThree Concepts of System Architecture 1 Introductionftp://db.stanford.edu/pub/.../CSL-TR-95-674.pdf - Vertaal deze paginaBestandsformaat: PDF/Adobe Acrobat - Snelle weergavedoor DC Luckham - 1995 - Geciteerd door 82 - Verwante artikelenDavid C. Luckham ... face connection architecture, and plug and socket architecture. ... services service connection , are introduced to de ne plug and socket ... See my article on mapping this arch to OO language.

Dr. Cuch, 2 blank posts + a copypaster - r u OK? Shall we call an ambulance?