Por que as sobrecargas de String.Format existem?
Eu estava usando o Reflector para examinar a implementação de String.Format e sempre tive a impressão de que as sobrecargas de String.Format que usavam 1, 2 e 3 argumentos eram versões otimizadas do método que utiliza uma matriz de objetos. No entanto, o que descobri foi que, internamente, eles criam uma matriz de objetos e depois chamam um método que utiliza uma matriz de objetos.
1 arg
public static string Format(string format, object arg0)
{
if (format == null)
{
throw new ArgumentNullException("format");
}
return Format(null, format, new object[] { arg0 });
}
2 args
public static string Format(string format, object arg0, object arg1)
{
if (format == null)
{
throw new ArgumentNullException("format");
}
return Format(null, format, new object[] { arg0, arg1 });
}
3 args
public static string Format(string format, object arg0, object arg1, object arg2)
{
if (format == null)
{
throw new ArgumentNullException("format");
}
return Format(null, format, new object[] { arg0, arg1, arg2 });
}
Matriz de objetos
public static string Format(string format, params object[] args)
{
if ((format == null) || (args == null))
{
throw new ArgumentNullException((format == null) ? "format" : "args");
}
return Format(null, format, args);
}
Internamente, todos acabam usando o mesmo código e, portanto, as versões 1, 2 e 3 do argumento não são mais rápidas que a versão da matriz de objetos.
Então, minha pergunta é -por que eles existem?
Quando você usa a versão da matriz de objetos com uma lista de valores separados por vírgula, o compilador converte automaticamente os argumentos em uma matriz de objetos por causa da palavra-chave params / ParamArray, que é essencialmente o que as versões 1, 2 e 3 fazem, para que pareçam redundantes. Por que os designers da BCL adicionaram essas sobrecargas?