I understand today is the last day of the Formal Review, and author has not made any comments for the last two days, so my vote will be based on how things stand now.
I vote that the library is NOT accepted. I think it has major issues (showstoppers) which were raised on this forum during the Formal Review, and the library is simply not ready to be accepted. Particularly: USABILITY/DOCUMENTATION 1. No references to prior art by the author. This is a shame, because library addresses the needs that existed for really long time, and prior art *is* available. (Mention of COBOL does not count, as it is not backed up by any detail. No indication is given whether library works as COBOL or how it differs -- is every user supposed to find it out themselves?) The lack of prior art in this case is a **showstopper**. 2. The definition of the library goals is too general. Rationale claims that library provides "what's needed for financial software". My opinion, the Rationale has to enumerate in finer detail what use cases it supports, and provide code examples. (I.e. "if you need to achieve such-and-such thing, your code should look like this") This is **major** issue, because it affects expectations. 3. I posted previously that I encountered two needs in my financial applications: a. data class, with precise representation of decimal numbers of up to declared by programmer fixed scale, with small footprint. b. calculations with maximum possible precision, and variable (floating) scale, which would guarantee precision for ADD/SUB and where possible for MUL/DIV/MOD. As it stands right now, the proposed library does not provide good solution to either of these needs. Author has not commented whether he is planning to address these needs or not. The bottom line is that I will not use the library (although based on declared goals I could), so to me this is **showstopper**. DESIGN/IMPLEMENTATION The decision to design the decimal class as lightweight is good. The design of numerical operations is poor: 1. a + b != b + a; and also a * b != b * a These are **major** inconveniences, for numerical class. 2. a = b does NOT imply that a == b Particular implication is that class is not std::vector-compatible **showstopper** 3. rounding, determined by scale of operands instead of the result: decimal a( 1, "1.5" ); decimal b( 1, "1.5" ); decimal c( 2 ); c = a * b; // c != 2.25 c [round_up]= a * b; // c != 2.25 c = a [round_up]* b; // c != 2.25, BUT value of a is changed <- simply bug? c = decimal( 2, a ) * b; // is this what's needed to get 2.25? These comments have been made in earlier threads, and they are fixable, but author has not responded conclusively on how he plans to address them. As long as this is the case, I consider the issues unresolved and my vote is "NO". -- Thanks & Best Regards. Ilya Buchkin MetaCommunications Engineering mailto:[EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost