Re: Converting double to widestring
* Doug Harrison [MVP]:
On Thu, 27 Mar 2008 12:42:33 +0100, "Alf P. Steinbach" <alfps@start.no>
wrote:
However, I'm now looking at them again, and _ecvt and _fcvt use a statically
allocated buffer, which may be a little unthread-safe (not that I thought of
that earlier, at least as far as I can recall). And _gcvt, where you can
specify the buffer, doesn't have a precision argument (OP requires to be able to
specify "how many decimal places to be used"), but a total number of digits.
This essentially means having to call it twice for each number.
If using these functions I think I'd take my chances with _ecvt and/or _fcvt,
since they have precision arguments, but that would require much testing for
multi-threading.
The multithreaded CRT libraries use TLS for static buffers in functions
such as these, so thread safety should not be an issue.
Although it is what's expected and natural, that doesn't seem to be documented.
E.g., the documentation of strtok says "calling this function simultaneously
from multiple threads does not have undesirable effects", which presumably
refers to multiple threads when using the multi-threaded CRT, but the
documentation of _ecvt, in my old MSDN lib, doesn't mention any such feature.
However, checking the source code can be an alternative to thorough testing.
And the source code indicates that also _ecvt uses TLS (via internal function
_fpcvt). But anyway, one is then back to relying on undocumented functionality.
More undocumented stuff: the buffer size is
# define _CVTBUFSIZE (309+40)
which seems to allow for largest double value with about 37 decimals for _fcvt.
Cheers,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?