Re: Decimal: Formal review begins.

From: Matt Borland (matt_at_[hidden])
Date: 2025-01-18 15:03:03

> > 

> > The only update I found was https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html. I emailed Dietmar a while back to ask why it was never accepted, but I did not receive a response.
> 

> 

> I found this SO answer, quite informative:
> 

> I happened to be at the meeting where IBM initially proposed the decimal types to WG14 and WG21. Their initial proposal was to provide them as native types, which is pretty much the only solution in C. However, WG21 wasn't entirely convinced and pointed out that C++ already has std::complex<> as a mathematical type in the library, so why not std::decimal<>? Initial confusion about the performance overhead was quickly ended when it was pointer out that std::decimal could obviously wrap a _Decimal compiler extension.
> 

> After poiting out that this could be done in a library, the next question was then whether this should be in the Standard library. It's after all a specialized domain in which this is useful. The most commonly though-of domain, finance, doesn't actually need it (they really need decimal fixed-point, not decimal floating point). IBM didn't push their proposal a lot further, after this feedback.
> 

> These types do not resolve the issue of floating-point inaccuracy. 1/3 still isn't representable. However, 1/5 is.
> 

That's a decent perspective. Assuming Decimal makes it into Boost it will be broadly and easily accessible anyway. Again there is also the implementation factor. This library took Chris and I a solid 18 months in our specialty domain. Is it worth the time for all the standard library implementers to re-implement something that's already portable and accessible? SLOCCounts analysis is a bit more draconian:

"generated using David A. Wheeler's 'SLOCCount'.":
Total Physical Source Lines of Code (SLOC)                = 58,068
Development Effort Estimate, Person-Years (Person-Months) = 14.23 (170.74)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 1.47 (17.63)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 9.69
Total Estimated Cost to Develop                           = $ 1,922,097
 (average salary = $56,286/year, overhead = 2.40).

Matt