Почему не делает IEnumerable <T>.Max, вынуждают T быть IComparable?
Еще один, основанный на предложении SilverTab, но созданный для поддержки x количества аргументов и не требующий Java 6. Он также не является универсальным, но я уверен, что его можно сделать универсальным.
private byte[] concat(byte[]... args)
{
int fulllength = 0;
for (byte[] arrItem : args)
{
fulllength += arrItem.length;
}
byte[] retArray = new byte[fulllength];
int start = 0;
for (byte[] arrItem : args)
{
System.arraycopy(arrItem, 0, retArray, start, arrItem.length);
start += arrItem.length;
}
return retArray;
}
2 ответа
Думаю, потому что он более гибкий. Например, у вас может быть IEnumerable , который содержит строки, и в этом случае Max () можно безопасно вызывать для него, несмотря на то, что тип Объект не реализует IComparable .
Сравнения ... забавно. Во-первых, у вас есть выбор: IComparable или IComparable - что бы вы выбрали? В настоящее время (через Comparer ) он поддерживает оба, но нет общего ограничения «это или то».
Затем возникает проблема Обнуляемый ; это «подняло» сравнения, поэтому сопоставимость результатов зависит от T ; но опять же, Comparer имеет дело с этим для нас ( Nullable не реализует ни IComparable , ни IComparable ).
Плюс; это экономит на распространении общих ограничений; как только у вас будет такое ограничение в коде библиотеки,