QuoteJust focusing on libraries may not be sufficient, as we all know. More is needed.Unfortunately, C++ does not support interfaces/components, which could be a problem with system integration. The biggest risk imo is the scaleability.Definitely! (thanks for the link Cuch! so are you well into it?)But I am still learning the fundamentals about patterns and hoped that C++ could still be used effectively for interfaces/components However my example was probably not clear enough: I just wanted to say that no payoff language in the financial sw arena has become standard yet so it's hard at this stage to prepare for it. On the other hand a payoff language can always live aside of precooked pricing modules without necessarily requiring big architectural worries, even if this is not so elegant.A (slightly) better example might be e.g. CVA, here layers and componets per se might not be enough and one needs to design ahead: focusing on european exercise for clarity, think how a classical pricer merges to some extent scenario generation (even from a client module), payoff evaluation and expectation in one loop; this will be useless for CVA whre netting loops are introduced. Sure, you can have classical and CVA pricers living in parallel without forcing an integration, just as with payoff languages... but as similar issues accumulate the increase in overall modules/complexity sounds exponential to me.Was this clear enough?Or imagine someday wanting a bayesian framework instead of the "handcrafted" calibration route, will it be a straightforward extension or a major architectural issue?That is, maybe both OO and components (afaiu) are not enough still. But it'd be extremely nice to be proven wrong.Other examples might come from adaptive numerics, where feedbacks interfere with a simple layered architecture. And that's where I would like to contribute...Surely enough this is not meant to spoil the game, quite on the contrary ;-)And definitely working on the flat math interface now is useful already.Oh well, maybe this topic should be shifted to the architecture thread now.

FPML will take awhile for it to become a standard, it is also currently limited on product scope. Either: build our own standard (gulp), or use a standard (FPML or other) that people can translate to.Is FPML that widespread in adoption? Is it any good?

QuoteBut I am still learning the fundamentals about patterns and hoped that C++ could still be used effectively for interfaces/components A major effort is in decomposing your systems into cohesive, loosely-coupled subsystems/components having standardised interfaces. How to do this is well-known (e.g. my 5 domain architecture reference models).What will be sub-optimal as kick-off is 1. jump straight into programming2. GOF patterns for large systemsCombine top-down and bottom-up. Boost function and signals can define flexible interfaces.

QuoteOriginally posted by: outrunboost::function used to have overhead, ..but no longer!Quoteinvoking a boost::function incurs the cost of one call through a function pointer in most cases. In other words, if you were going to have to use function pointers anyhow, and you get a bunch of enhanced functionality for free.Wonderful! A dream come true. Quotebtw Cuch: I think *you* need to start a design suggestion Write something in a doc? Maybe example code so that we can explore pro's/con's? Yep, on the TODO list.

QuoteOriginally posted by: rmaxFPML will take awhile for it to become a standard, it is also currently limited on product scope. Either: build our own standard (gulp), or use a standard (FPML or other) that people can translate to.Is FPML that widespread in adoption? Is it any good?As a matter of interest, there's also ISO 20022, organizations participating in 20022 include: FPL (FIX), ISDA (FpML), OMGEO, and Visa.More information:- http://www.iso20022.org/- http://en.wikipedia.org/wiki/ISO_20022- Investment Roadmap - ISO 20022- and, this cute little video: ISO 20022 (for financial information) made simple