为什么IsNan是Double类的静态方法而不是实例属性？

Question

The question is in the title, why :

return double.IsNaN(0.6d) && double.IsNaN(x);

Instead of

return (0.6d).IsNaN && x.IsNaN;

I ask because when implementing custom structs that have a special value with the same meaning as NaN I tend to prefer the second.

Additionally the performance of the property is normally better as it avoid copying the struct on the stack to call the IsNaN static method (And as my property isn't virtual there is no risk of auto-boxing). Granted it isn't really an issue for built-in types as the JIT could optimize this easilly.

My best guess for now is that as you can't have both the property and the static method with the same name in the double class they favored the java-inspired syntax. (In fact you could have both as one define a get_IsNaN property getter and the other an IsNaN static method but it will be confusing in any .Net language supporting the property syntax)

Answer 1

Static Methods are thread safe, methods on primitives generally need to be thread safe to support threading in the platform (meaning at least safe from internal race conditions), instance methods take a managed pointer to a structure, meaning that the structure/primitive might be modified concurrently while the method executes, on the other hand static methods take a copy of the structure/primitive and therefore are safe from threading race conditions.

If the structure is intended to be thread safe, then the methods should be made instance methods only if they do atomic operations, else static methods should be chosen.

(As another option, instance methods that use locking could be used but they are more expensive than, copying)

Edit: @VirtualBlackFox I've prepared and example to show that instance methods on structures are not thread safe even on immutable structures:

using System;
using System.Threading;

namespace CA64213434234
{
    class Program 
    {
        static void Main(string[] args)
        {
            ManualResetEvent ev = new ManualResetEvent(false);
            Foo bar = new Foo(0);
            Action a =  () => bar.Display(ev);
            IAsyncResult ar = a.BeginInvoke(null, null);
            ev.WaitOne();
            bar = new Foo(5);
            ar.AsyncWaitHandle.WaitOne();
        }
    }

    public struct Foo
    {
        private readonly int val;
        public Foo(int value)
        {
            val = value;
        }
        public void Display(ManualResetEvent ev)
        {
            Console.WriteLine(val);
            ev.Set();
            Thread.Sleep(2000);
            Console.WriteLine(val);
        }
    }
}

The display Instance method prints: 0 5

even though the structure is immutable. For thread safe methods use static methods.

Answer 2

Interesting question; don't know the answer - but if it really bugs you, you could declare an extension method, but it would still use the stack etc.

static bool IsNaN(this double value)
{
    return double.IsNaN(value);
}

static void Main()
{
    double x = 123.4;
    bool isNan = x.IsNaN();
}

It would be nicer (for the syntax) if C# had extension properties, but the above is about the closest you can get at the moment, but it should "inline" quite well anyway.

---

Update; thinking about it, there is another difference between static and instance; C# always calls instance methods with " callvirt " rather than " call ", even if ther type is sealed an non-nullable. So perhaps there is a performance benefit from having it static? Luckily, extension methods still count as static, so you get to retain this behavior.

Answer 3

@Pop Catalin: I'm not ok with what you said in :

If the structure is intended to be thread safe, then the methods should be made instance methods only if they do atomic operations, else static methods should be chosen.

Here is a small program that demonstrate that static methods don't solve this problem for structs :

using System;
using System.Threading;
using System.Diagnostics;

namespace ThreadTest
{
    class Program
    {
        struct SmallMatrix
        {
            double m_a, m_b, m_c, m_d;

            public SmallMatrix(double x)
            {
                m_a = x;
                m_b = x;
                m_c = x;
                m_d = x;
            }

            public static bool SameValueEverywhere(SmallMatrix m)
            {
                return (m.m_a == m.m_b)
                    && (m.m_a == m.m_c)
                    && (m.m_a == m.m_d);
            }
        }

        static SmallMatrix s_smallMatrix;

        static void Watcher()
        {
            while (true)
                Debug.Assert(SmallMatrix.SameValueEverywhere(s_smallMatrix));
        }

        static void Main(string[] args)
        {
            (new Thread(Watcher)).Start();
            while (true)
            {
                s_smallMatrix = new SmallMatrix(0);
                s_smallMatrix = new SmallMatrix(1);
            }
        }
    }
}

Note that this behavior can't be observed with double values on common processor as most x86 instructions have a version working with 64bits chunks such as movl .

So thread safety doesn't seem a good reason for IsNaN to be static :

1. The framework should be platform agnostic and so it shouldn't presuppose things like the processor architecture. IsNaN thread-safety is dependent on the fact that 64bits values are always accessed and modified atomicaly on the target architecture (And Compact framework targets aren't x86...).
2. IsNaN is useless by itself and in a context where multiple thread could access someVar this code is anyway unsafe (regardless of the thread safety of IsNaN) :

print("code sample");
if (!double.IsNaN(someVar))
    Console.WriteLine(someVar);

What i mean is that even if IsNaN is implemented by doing == comparisons with all possible NaN values... (not really possible) ...who care that the value evolve during the execution of the method if anyway it could have changed once the method terminate... or it could even be an intermediate value that should never have been here if the target architecture isn't x86...

Accessing intristic values in two different threads is NOT safe in general so i see no interest in providing some illusion of safety by putting any method static when dealing with structs or any other type,

Answer 4

The distinction between an instance and a static is a fundamental point which the C# language (and Java as you say) chooses to make clear (in C++, you can call a static method through an instance, but thats just syntax - under the hood instance.StaticX is the same saying instance Class.StaticX.

The move towards fluent interfaces has started unravelling a lot of this though...

Answer 5

I remember the words of a mentor, praying that any method, that does not use any other variables than the parameters are static methods.

I really do not know why, and havent thought on the behind, but logically, it seems good. Interested in the answer anyhow ;-)

Answer 6

I think Marc was onto the answer.

The problem is when you need to call instance methods on valuetypes, the value is boxed. This would cause a severe performance penalty.

Answer 7

Double.IsNan follows the same pattern as String.IsNullorEmpty. The latter behaves as it does because there is regrettably no way to declare that a non-virtual instance method should be usable with a null "this". While such behavior might be odd for mutable reference types, it would be very useful for things that have to be reference types but which should behave semantically like immutable values. For example, the "String" type would have been much more convenient if invoking its properties on a null object would have behaved identically to invoking them on an empty string. As it is, there's an odd mish-mosh of contexts in which a null string object will be regarded as an empty string, and those in which trying to use one will generate an error. It would have been much cleaner if string had behaved consistently as a value type which is initialized to an empty string.