Is .NET double.ToString threadsafe?

I'm seeing an issue in a production ASP.NET application that involves the following code, which is used to render the geocoordinates of a particular object:

private double _longitude;
private double _latitude;

public string ToCsvString()
{
    return _latitude + "," + _longitude;
}

Thread.CurrentThread.CurrentCulture will be set to different values based on the incoming request. The behavior I'm seeing is that the result of this function will vary independent of the threadlocal culture. At times the decimal points and commas are incorrect for the current culture. More strangely, it see开发者_开发百科ms that once set wrong, the wrong value persists.

Does ToString on double cache values?

---

It shouldn't cache the values, especially because of the culture issue you mentioned. Two things come to mind:

1. How/where do you set the culture? Perhaps there is a bug there?
2. Are you sure it is THIS place that creates the bug? Perhaps the culture is different than you think? Perhaps the results of this function are cached elsewhere in your code?

---

Why not use the explicit ToString methods which allow you to manually specify a culture-specific IFormatProvider?

---

For rendering geocoordinates, I suggest that you best define your own fixed formatting or culture rather than leaving it for the framework, default culture setting or culture info of the running thread.

I would do it like this to format it to 4 decimal points:

return _latitude.ToString("0.0000") + "," + _longitude.ToString("0.0000");

or

string.Format("{0:0.0000}, "{1:0.0000}", _latitude, _longitude);

Or if you want the decimal separator to be culture specific,

CultureInfo ci = System.Globalization.CultureInfo.GetCultureInfo("en-AU");
return _latitude.ToString("N4", ci) + "," + _longitude.ToString("N4", ci);

---

If you always want Double.ToString to return consistent values regardless of culture, use an InvariantCulture:

someDouble.ToString(CultureInfo.InvariantCulture); 

---

Operations such as ToString on double or any other immutable object are by definition thread safe. Since you are guaranteed that the state of those object never change an operation will always yield the same result, that result might however be based on the environment it's executed in but it will always yield the same result in the same environment. Since there are no side effects on immutable types ToString cannot cache the result

---

Any page in msdn will show you the fact that "Any public static (Shared in Visual Basic) members of this type are thread safe. Any instance members are not guaranteed to be thread safe"

for instance look at this one http://msdn.microsoft.com/en-us/library/system.delegate.aspx

So, double.ToString() is not guaranteed to be thread safe since it is an instance methods.

I would echo what Anon suggested and use IformatProvider