views:

158

answers:

5

The following code causes a compiler error, as it is ambiguous call but the problem if we use object instead of ArrayList no error happens and the string version works fine; Do you have an explanation for that?

class A
{
    public A(string x)
    {
        Console.WriteLine("string");
    }
    public A(ArrayList x)
    {
        Console.WriteLine("ArrayList");
    }

}
    static void Main(string[] args)
        {
            A o = new A(null);
        }
+2  A: 

null could represent either a string, or an ArrayList. There's no information there is to which version of the method (in this case a constructor) you meant.

You can force it to use a specific one by casting:

static void Main(string[] args)
    {
        A o = new A((string)null);
    }

...or alternately implementing a constructor that behaves as you want (that takes no parameter)

Rowland Shaw
An `object` could be null too, but the OP indicated that changing `ArrayList` to `object` resolves the issue; so this isn't the whole picture. The real issue is that in this case, neither type will "win" in the eyes of the compiler because one does not inherit from the other. In the case of `string` vs. `object`, `string` wins out because it derives from `object` and is therefore more specific.
Dan Tao
What about using object, you did not answer me
Ahmed Said
+1  A: 
  1. Of course it's ambiguous: null could be either a string or an ArrayList. You'll need to qualify it, like (string) null.
  2. Did you know that ArrayList is deprecated? You should use one of the generic collection types instead
John Saunders
For the ArrayList, it depends on the version of the Framework he uses, I guess. But good point for the `null` ambiguity.
Will Marcouiller
@Will: if he's still using .NET 1.1, I'd tell him that .NET 1.1 has been deprecated.
John Saunders
Hehehe... Right! =) But sometimes one has to deal with administrative decisions. If it's not broken, don't fix it! But yet, I get your point anyway. =)
Will Marcouiller
I putted ArrayList as an example I am using .Net 3.5
Ahmed Said
`ArrayList` is a class you should no longer use. The direct replacement is `List<object>`.
John Saunders
+4  A: 

I could be wrong, but I think the reason it works when you change ArrayList to object is because string inherits from object and it decides to use the more specific string version. When it's string and ArrayList it doesn't know which one to use.

juharr
+14  A: 

The reason your code works fine if you change the constructor that takes an ArrayList to take an object is that the C# compiler will pick the most specific type applicable. In the case of string/object, string actually derives from object and is therefore "more specific" and will be inferred by the compiler. With string versus ArrayList, it's apples and oranges: either can be null, but neither is more "specific" than the other.

Dan Tao
+1 beat me to the explanation. Your answer is the only one that answers the actual question.
klausbyskov
Line of the day : *it's apples and oranges: either can be null, but neither is more "specific" than the other.* :)
TheMachineCharmer
@TheMachineCharmer: What, you've never eaten a null apple? They're delicious.
Dan Tao
@Dan Tao, NO. There were only 4 null apples. And they were all consumed by by Adam,Isaac Newton,Steve Jobs and you! (chronologically) :) lol
TheMachineCharmer
A: 
TheMachineCharmer
It's not really to do with them being nullable\reference types, but rather that there is no 'best' option to choose between string and ArrayList. If you had a function with an overload taking a Stream, and one taking a MemoryStream and called it with null then the compiler would be able to resolve it.
Lee
@Lee Thanks! But could you please explain how compiler resolves it in that case?
TheMachineCharmer
This post from Eric Lippert explains overload resolution better than me - http://stackoverflow.com/questions/2856023/c-method-generic-params-parameter-bug/2858949#2858949.
Lee