On Thu, 16 Jan 2025 at 16:05, Matt Borland
Thanks. I'm trying to understand whether sticking to the TR has enough value. If it doesn't, maybe we could consider applying Peter's comments about making decimal32 be the fast one, or dropping sprintf.
The TR was a good starting point, but yes we have added much since then to make the types as seamlessly interoperable with the STL as we can. Like two weeks ago someone asked for <format> support and we provide that which obviously won't be in a TR from 2009. Is there any real gain from dropping a standard function that's already generally implemented? I don't think so especially if we pursue standardization. It's not a totally complete implementation of sprintf but it would groundwork for bolting on support to existing std:: implementations.
I didn't make my point here clear, sorry. I completely agree with including every cstdio function, except for sprintf. There's no way to communicate sprintf the length of the input buffer, so it's very easy to end up with buffer overflows. I can't think of a use case where sprintf should be used over snprintf, which just adds the length parameter. So that's the only function I was advising to be removed.
Some more questions: 1. As a user, when should I pick decimal64 vs decimal64_fast? I intend to implement support for your decimal types in the static interface of Boost.MySQL as part of this review - should I support decimalXY, decimalXY_fast, or both?
It would be a pretty easy template to support decimalXY and decimalXY_fast. I know for fact decimalXY is being used out in industry, but not sure about decimalXY_fast. It would be more space efficient to store as decimalXY.
I will implement both. It's true that from my library's perspective it doesn't matter. But I think as a user, I'd like to see some guidelines on what use cases should I employ each one for.
2. Is there a rationale behind only supporting the convenience header, as stated in the docs? Including the entire library in my machine (gcc-12, Ubuntu 22.04, -std=c++23) is about 4.5seconds - similar to the entire Asio in magnitude. Including only decimal32.hpp cuts the time to around 1s.
I never tried many of the permutations of headers outside of the convenience one. The library is structured to match the STL so that it is unsurprising to the average user. I think you could pick and choose if you wanted to.
I tried picking charconv and it didn't work :) I think that the actual header structure is good, matching STL as you said. I don't agree with recommending users to always include the entire library - I think that increases compile times without much benefit. Hence I was asking whether there was an actual reason to do it.
3. In the line of the previous question, is there a reason to have BOOST_DECIMAL_DISABLE_IOSTREAM instead of splitting iostream functionality to a separate header? In my experience, the more config macros you have, the more chances of getting bugs. Also, is the test suite being run with these macros defined?
We have a the options to disable a bunch of the clib functionality so that the library can run on embedded platforms. We do have QEMU of an STM board in the CI which tests all of this. Why test embedded you ask? It's not uncommon for finance devs to run on bare metal platforms.
I understand the objective, and I think it's great having tests for that. But I don't think the method is the best. I've reviewed all uses of BOOST_DECIMAL_DISABLE_IOSTREAM, and if I'm reading this correctly, they all guard functions that are exclusively used in the tests. I don't think these functions should be in the headers shipped to users, but in the tests. I acknowledge that these functions require access to private members of public classes, so I guess that's why they are defined there. I use a dummy friend struct placed in the detail namespace when I have such problems (I think I copied the pattern from Boost.Json). I think you can get rid of all the iostream includes altogether doing this (except for the ones in io.hpp, which are actually not guarded by the macro). BOOST_DECIMAL_DISABLE_CLIB ifdefs-out entire headers - wouldn't it be simpler to have a subset of headers allowable in embedded systems, with others just labelled as "not supported"? Regards, Ruben.