Re: Converting double to widestring
* Doug Harrison [MVP]:
On Thu, 27 Mar 2008 16:49:25 +0100, "Alf P. Steinbach" <alfps@start.no>
wrote:
Although it is what's expected and natural, that doesn't seem to be documented.
Indeed. The TLS usage is to be expected, since this is what MS did for
functions which use static buffers perhaps 15 years ago when they created
the MT libraries, and it's easily verified by examining the source code.
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.
I don't know that I would feel too comfortable in establishing the thread
safety of an opaque function by "thorough testing".
You always (analysis or documentation or testing) just end up with a
probability, a measure of confidence, which must be weighted against cost of
possible failure.
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.
I know it's undocumented; I resisted the temptation to comment that while
this fact isn't mentioned explicitly, at least we're told, "This function
is deprecated because a more secure version is available; see _ecvt_s". :)
Yes, much better wrt. buffer, but AFAICS still doesn't mention anything about
multi-threading.
The bottom line is that if you program only to what's documented in MSDN,
you won't get very far. You won't be able to write MT programs, period,
because AFAIK, MS has yet to define a MT programming model, as POSIX did
10-15 years ago. That said, everyone knows that the same memory visibility
rules apply to things like mutex usage. MSDN is nowhere near as rigorous
as, say, the C++ standard, which has its own ambiguities and omissions. Of
course, you have to be able to investigate and judge what you can and can't
rely on.
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.
I'm not sure where you get 37 decimals
Range of double 1.7E-308 ... 1.7E308, latter requires 109 digits for integer
part, 40 buf chars left, minus one for sign, one for radix point and one '\0'.
, but anyway, the second one is
actually documented, nowadays at least:
http://msdn2.microsoft.com/en-us/library/ex8sf9x0(VS.80).aspx
<q>
The total number of digits returned by _fcvt will not exceed _CVTBUFSIZE
</q>
Uhm, goodie, now if they'd just care to mention sign, radix point and
terminating zero, and giving the numeric value, like "The maximum number of
digits returned by _fcvt is _CVTBUFSIZE-3, where _CVTBUFSIZE=309+40 (note: range
of double is...)", then that would have been actually useful! :-)
Then add in documentation of the format produced, and one would be almost in
documented-land! <g>
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?