November 9th, 2011, 12:43 pm
QuoteOriginally posted by: outrunQuoteOriginally posted by: CuchulainnQuoteOriginally posted by: outrunQuoteOriginally posted by: Cuchulainn What I like is methods for {Min, Max} Index in loops instead of inane 0 and size - 1. BTW my Vector<> is already STL-compliant.I'm thinking about the compliance the other way around. E.g. * The algorithm that uses DD_Vector<> should also work with std::vector, or any other container that provided a stl compliant interface. * {Min, Max} preferences inside the algorithm should not result in interface requirement to the vector container, because stl doesn't have that, and that would cause the algorithm not to work on stl compiant containers. E.g. a user might prefer std::vector over DD_VectorDesign choices like that... Does that make sense? Regarding boost. I think we said that we prefer STL dependency, *then* boost, then self-written code. Lots of libs in boost end up in the C++ standard. It's more likely that functionality in boost will end up in the standard than serlf-written functionality, hence the preference of boost of writing thing yourself.My Vector class is consistent with what we call a mathematical vector space, which std::vector is not. Thus, the latter is the wrong container for maths (valarray tried to solve this, but was not successful). UBLAS vector would be closer to My Vector.std::vector is just a container, so I would not use it in a solver.And MinIndex() flexible is a must (C, Fortran styles). A lot of Boost ends up in C++ and lot does not.Ok, so on this we disagree! I want the algorithms to support std::vector, iterators, not self written stuff, that will only make thing complicated and steepen the learning curve.The solution is to implement both.I'll refactor the heat equation solver *algorithm* into one that's STL compliant, and release it on a different brand, call it the C++ STL compliant / generic programming QFCL or something like that.I would say two design decisions that we can check against ISO9126. For FDM apps, std::vector is *mathematically incorrect*. I have tried it already, so not again for FDM. My Vector has been around > 15 years and is easy to use, so in V1 FDM this is what I will deliver (it works now as it is). If anything, uBLAS vector and this 1st option. Contributors can put this it into V2, which is fine.
Last edited by
Cuchulainn on November 8th, 2011, 11:00 pm, edited 1 time in total.