¿Por qué las funciones toman un int como argumento cuando su valor lógicamente no puede ser <0 - .net, argumentos, int, uint

Cuando escribo funciones que toman argumentos que determinan una cierta longitud, siempre uso uint. Ya que no tiene sentido que el valor sea un número negativo.

Pero veo lo contrario (muy a menudo) en el marco .Net. Por ejemplo: http://msdn.microsoft.com/en-us/library/xsa4321w.aspx

Inicializa una nueva instancia de la clase String con el valor indicado por un carácter Unicode especificado repetido un número específico de veces.

public String(
char c,
int count
)

También establece que un ArgumentOutOfRangeException se lanza cuando 'contar es menor que cero ".

¿Por qué no hacer el count un argumento uint ¿¡luego!?

Respuestas

tuve una pregunta similar hace años, aunque más para mis propias interfaces, no para las centrales.

La respuesta corta (dada nada menos que por Eric Lippert, y repetida en respuestas a otras preguntas) es: Las reglas de Common Language Specification establecen que no debe utilizar uint en interfaces públicas porque no todos los lenguajes que están diseñados para trabajar con .NET en realidad tener tal tipo. Me vienen a la mente derivados de Java como J #: Java solo tiene tipos integrales firmados.

Los tipos sin firmar en C tienen dos usos principales:

1. En algunos casos, es útil tener valores que"se ajusta" cuando los cálculos exceden el rango de un tipo. Por ejemplo, cuando se calculan muchos tipos de hash o suma de comprobación, es mucho más conveniente simplemente realizar un montón de adiciones o multiplicaciones ignorando el desbordamiento, que usar una variable de gran tamaño y / o lógica condicional para evitar el desbordamiento.

2. A veces es útil tener unala variable podrá contener un valor de hasta 65.535 en lugar de solo 32.767; ocasionalmente es útil que las variables de cuatro bytes suban a 4.294.967.295, pero eso es mucho menos común.

En C, un intento de almacenar -1 en un unsigned Se requirió la variable para almacenar (sin ningún tipode error o graznido) el valor que, sumado a +1, daría como resultado cero. Esto fue muy útil para el primer escenario de uso; no era deseable para el segundo, pero dado que C nunca tuvo ningún tipo de captura de desbordamiento en enteros con signo, podría considerarse una extensión del principio de que sucederán cosas malas cuando los cálculos en números (en lugar de anillos algebraicos) se salen de rango.

C #, a diferencia de C, admite desbordamiento numéricodetección y, por lo tanto, podría aplicarlo al segundo estilo de uso y, al mismo tiempo, permitir el primer estilo de uso. Desafortunadamente, la determinación se basa en contextos numéricos verificados o no verificados, más que en los tipos de variables, parámetros o valores. Por tanto, si un método aceptara un parámetro de tipo UInt32 y codificar en un unchecked contexto intentó pasar un valor de -1, elEl método lo vería como un valor de 4.294.967.295. No hay forma de que se pueda marcar un parámetro para que diga "Este debe ser un valor entre 0 y 4.294.967.295; graznar si es algo más, independientemente del estado marcado / no marcado. Por tanto, es más seguro que el código acepte un Int32 si un límite superior de 2,147,483,647 es suficiente, o Int64 si no.