Page 1 of 2

Idea's for a code repository directory layout

Posted: October 3rd, 2011, 9:35 pm
by Polter
Just for reference: http://www.boost.org/development/requir ... tructureAn alternative organization could be the one delineated in Syd Logan's "Cross-Platform Development in C++" in the "Organizing the Project in CVS or SVN" section (just google for "Organizing the Project in CVS or SVN"). An obvious one is also QuantLib, but I was unable to find a document that lists the rules.Boost is way more loosely coupled than QuantLib (with the implications for organization), which could be a plus or a minus. To clarify: multi-level hierarchies in Boost are very rare (although not non-existent), since it's a collection of largely independent libraries -- for instance, you don't need to know anything about Boost.uBLAS to use Boost.Random (and you might as well delete / never even download the headers of Boost.uBLAS if Boost.Random is the only thing you care about). In contrast, in QuantLib, the QuantLib::EuropeanOption class inherits from a few classes (and you'd better not remove the corresponding header files): http://quantlib.sourcearchive.com/docum ... on.htmlThe question is how much is this coupling due to the inherent nature of financial instruments (EuropeanOption is-a VanillaOption is-an OneAssetOption is-an Option is-an Instrument -- "hey, that's true enough") and how much decoupling can we achieve (without crippling flexibility, extendability, etc.) -- and it's a valid question that inevitably arises as soon as someone mentions the Open-Closed Principle.So, what seemed (to me) initially like a simple question might be impossible to resolve without having a design up front.Other than that, to the extent that we can (which remains an open question), I'd be inclined to adopt the Boost Library Requirements and Guidelines pretty much verbatim (substituting the library name for "Boost" where applicable). Well, with possible exceptions, like "Aim first for clarity and correctness; optimization should be only a secondary concern in most Boost libraries." -- while correctness is fundamental and obviously has to overrule anything else, I'd be open to sacrifice clarity (which is a subjective quality) a little bit if significant optimization opportunities are present (e.g., parametric polymorphism & CRTP might be less "clear" to some than inclusion polymorphism & virtual member functions, but I wouldn't rule it out if its benefits would outweigh its costs in a given case).However, I think we can decide on identifying and adopting the uncontroversial, design-independent rules ("Files intended to be processed by a C++ compiler as part of a translation unit should have a three-letter filename extension ending in "pp". Other files should not use extensions ending in "pp". This convention makes it easy to identify all of the C++ source in Boost.") immediately.

Idea's for a code repository directory layout

Posted: October 4th, 2011, 7:47 am
by Cuchulainn
QuoteOriginally posted by: outrunregarding coupling.Suppose we look at it as a set of project, ..with the following code reuse rules & priority:* our Layer N* our layer N-1* ..* our layer 1* BOOST* standard C++/STLI think we should minimize the number of layers because that might make things more loosely coupled. If we have 10 layers, then new project A will link to layer 8 new project B will link to layer 3... we will get too many interface definitions ans chaos.Microkernel? "The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration"

Idea's for a code repository directory layout

Posted: October 4th, 2011, 8:07 am
by semanticum
More on the Microkernel Pattern in this Word Doc: Microkernel Pattern - an overview ...

Idea's for a code repository directory layout

Posted: October 4th, 2011, 8:46 am
by Cuchulainn
Microkernel and other system patterns are described in detail here.

Idea's for a code repository directory layout

Posted: October 4th, 2011, 9:59 am
by Polter
outrun: what about levels (of inheritance, for instance) within a layer? For instance, in "our" layer 3, how would an equivalent of QuantLib::EuropeanOption look like?I'm a bit wary of "microkernel"-anything, in the OS world it's something I consider close to GOTO (there's a reason it hasn't proven itself in modern commercially successful OSes -- many have tried, performance was never there), but I could be too sensitive: if we keep the number of layers below that required in the OS; and I suppose low-latency HFT isn't anywhere near the goals of the library anyway; also, the problem of microkernel arch in the OS world was insufficient performance on the hardware-software boundary, perhaps QFCL is a more compute-bound project?Seeing as even Mac OS X (the closest to "modern commercially," etc.) is a hybrid, perhaps this is a more realistic goal:http://en.wikipedia.org/wiki/Hybrid_kernel ?Note that this is mostly about choosing what's in the user mode, what's in the kernel mode, so perhaps the analogy is a stretch.Although it might be useful when considering the placement of modules within layers and see if this analogy sheds some light on whether it's a good idea:"While there is no performance overhead for message passing and context switching between kernel and user mode, as in monolithic kernels, there are no performance benefits of having services in user space, as in microkernels." I've looked at semanticum's document and there's this: "The Microkernel architectural framework also has liabilities: performance, complexity of design and implementation." Hm...

Idea's for a code repository directory layout

Posted: October 4th, 2011, 10:18 am
by Cuchulainn
QuoteI'm a bit wary of "microkernel"-anything, in the OS world it's something I consider close to GOTO (there's a reason it hasn't proven itself in modern commercially successful OSes -- many have tried, performance was never there), but I could be too sensitive: if we keep the number of layers below that required in the OS; and I suppose low-latency HFT isn't anywhere near the goals of the library anyway; also, the problem of microkernel arch in the OS world was insufficient performance on the hardware-software boundary, perhaps QFCL is a more compute-bound project?I have witnessed MK in applications (transportation, hw systems) where it has both been a failure and a success. Developers can sometimes over-engineer an othewise good design.//BTW what's wrong with GOTO("Dijkstra said so" )

Idea's for a code repository directory layout

Posted: October 4th, 2011, 10:41 am
by Polter
Cuch, sure, my problem is something that sacrifices _both_ out of "performance, complexity of design and implementation", wondering if that's the way to go./* I sure hope we can avoid thread-drift here (there's Programming forum for that :]), but code readability and maintainability in short.Compare FORTRAN 77do label var = expr1, expr2, expr3 statementslabel continuewith Fortran 90:do var = expr1, expr2, expr3 statementsend doIn FORTRAN 77 you have to maintain the "label" (avoid collisions, remember to match the right one) and you introduce syntactic noise -- as in here: do 20 i = 10, 1, -2 write(*,*) 'i =', i 20 continueWhat you care about is "10, 1, -2" -- "20" is just a distraction and stands in the way of expressing your intent most clearly and succinctly (the point is not that you jump to label 20, the point is that you're looping).And, sure, what Dijkstra said (structured programming), although that's of lesser importance than the clarity point to me (we break pure structured programming in a lot of ways).Although, if you can save some significant no. of CPU cycles and the only / best way to do that is to use GOTO, then go ahead, I'm not dogmatic.*/

Idea's for a code repository directory layout

Posted: October 4th, 2011, 2:24 pm
by Polter
Just like Boost then, awesome! Hope we can achieve that