¿Las enumeraciones tienen un límite de miembros en C#?

Question

Me preguntaba si el tipo de estructura enum tiene un límite en sus miembros. Tengo esta gran lista de "variables" que necesito almacenar dentro de una enumeración o como constantes en una clase, pero finalmente decidí almacenarlas dentro de una clase, sin embargo, estoy un poco curioso sobre el límite de miembros. de una enumeración (si la hay)

Entonces, ¿las enumeraciones tienen un límite en .Net?

Answer 1

Sí. El número de miembros con valores distintos está limitado por el tipo subyacente de enum - por defecto es Int32, por lo que puede obtener tantos miembros diferentes (2^32 - Me parece difícil que llegue a ese límite), pero puede especificar explícitamente el tipo subyacente de esta manera:

enum Foo : byte { /* can have at most 256 members with distinct values */ } 

Por supuesto, puede tener tantos miembros como desee si todos tienen el mismo valor:

enum { A, B = A, C = A, ... } 

En cualquier caso, no es probablemente algún límite definido por la implementación en el compilador de C#, pero yo ex Tenga en cuenta que es MIN (rango de Int32, memoria libre), en lugar de un límite estricto.

Answer 2

Debido a un límite en el formato de archivo PE, es probable que no pueda superar los 100.000,000 de valores. Tal vez más, tal vez menos, pero definitivamente no es un problema.

Answer 3

Desde el C# Language Specification 3.0, 1,10:

formato de almacenamiento de un tipo de enumeración y rango de valores posibles están determinada por su tipo subyacente.

Aunque no estoy 100% seguro de que sería de esperar compilador Microsoft C# sólo permite valores de enumeración no negativos, por lo que si el tipo subyacente es un Int32 (que es, por defecto), entonces yo esperaría alrededor de 2^31 valores posibles, pero este es un detalle de implementación ya que no está especificado. Si necesita más que eso, probablemente esté haciendo algo mal.

Answer 4

En teoría, podría usar int64 como su tipo de base en la enumeración y obtener 2^63 entradas posibles. Otros te han dado excelentes respuestas sobre esto.

Creo que hay una segunda pregunta implícita de si utiliza una enumeración para algo con una gran cantidad de elementos. Esto se aplica directamente a su proyecto de muchas maneras.

Una de las mayores consideraciones sería la mantenibilidad a largo plazo. ¿Cree que la empresa alguna vez cambiará la lista de valores que está utilizando? Si es así, ¿debe haber compatibilidad con versiones anteriores de listas anteriores? ¿Qué tan significativo podría ser este problema? En general, cuanto mayor sea el número de miembros en una enumeración se correlaciona con una mayor probabilidad de que la lista deba ser modificada en una fecha futura.

Las enumeraciones son geniales para muchas cosas. Son limpios, rápidos y simples de implementar. Funcionan muy bien con IntelliSense y facilitan el trabajo del siguiente programador, especialmente si los nombres son claros, concisos y, si es necesario, bien documentados.

El problema es que una enumeración también presenta inconvenientes. Pueden ser problemáticos si alguna vez necesitan ser cambiados, especialmente si las clases que los usan se están conservando.

En la mayoría de los casos, las enumeraciones se conservan en el almacenamiento como sus valores subyacentes, no como sus nombres descriptivos.

enum InsuranceClass 
    { 
    Home,  //value = 0 (int32) 
    Vehicle, //value = 1 (int32) 
    Life,  //value = 2 (int32) 
    Health //value = 3 (int32) 
    } 

En este ejemplo, el valor InsuranceClass.Life conseguiría persistido como un número 2.

Si otro programador hace un pequeño cambio en el sistema y se suma a la enumeración de mascotas como esto;

enum InsuranceClass 
    { 
    Home,  //value = 0 (int32) 
    Vehicle, //value = 1 (int32) 
    Pet,  //value = 2 (int32) 
    Life,  //value = 3 (int32) 
    Health //value = 4 (int32) 
    } 

Todos los datos que salen del almacenamiento mostrará ahora la vida políticas como mascotas políticas. Este es un error extremadamente fácil de hacer y puede introducir errores que son difíciles de rastrear.

El segundo problema importante con las enumeraciones es que cada cambio de datos requerirá que reconstruya y vuelva a implementar su programa. Esto puede causar diferentes grados de dolor. En un servidor web que puede no ser un gran problema, pero si se trata de una aplicación utilizada en sistemas de escritorio 5000, tiene un costo completamente diferente para volver a implementar su cambio de lista menor.

Si es probable que su lista cambie periódicamente, debería considerar un sistema que almacene esa lista de alguna otra forma, muy probablemente fuera de su código. Las bases de datos se diseñaron específicamente para este escenario o incluso se podría usar un archivo de configuración simple (no la solución preferida). La planificación inteligente de los cambios puede reducir o evitar los problemas asociados con la reconstrucción y la reubicación de su software.

Esto no es una sugerencia para optimizar prematuramente su sistema para la posibilidad de cambio, pero más una sugerencia para estructurar el código para que un posible cambio en el futuro no cree un problema importante. Diferentes situaciones requerirán decisiones de diferencia.

Aquí están mis reglas generales para el uso de enumeraciones;

1. Úselos para clasificar y definir otros datos, pero no como datos . Para ser más claros, usaría InsuranceClass.Life a para determinar cómo deberían usarse los demás datos de una clase, pero no haría que el valor subyacente de {pseudocode} InsuranceClass.Life = $653.00 y no utilice el valor en sí en los cálculos. Los mensajes no son constantes. Hacer crea confusión.
2. Use las enumeraciones cuando la lista de enumeración no es probable que cambie. Las entradas son geniales para conceptos fundamentales pero deficientes para cambiar constantemente de ideas. Cuando crea una enumeración, este es un contrato con los programadores futuros que desea evitar romper.
3. Si debe cambiar una enumeración, luego tiene una regla que todos siguen que agrega al final, no al medio. La alternativa es que defina valores específicos para cada enumeración y nunca los cambie. El punto es que es poco probable que sepa cómo otros están utilizando sus enumeraciones subyacentes valores y cambiarlos puede causar sufrimiento para cualquier otra persona que use su código . Este es un orden de magnitud más importante para cualquier sistema que persista datos.
4. El corolario de # 2 y # 3 es nunca eliminar un miembro de una enumeración. Existen círculos específicos del infierno para los programadores que hacen esto en una base de código utilizada por otros.

Esperemos que haya ampliado las respuestas de manera útil.