Const se hornea en el código del cliente. Readonly no es. Pero const es más rápido. Aunque puede ser solo un poco¿Cuándo, si alguna vez, debemos usar const?
La pregunta es, ¿alguna vez hay alguna situación en la que prefiera const sobre readonly? O para reformular, ¿no estamos prácticamente siempre mejor usando readonly en lugar de const (teniendo en cuenta lo dicho anteriormente para hornear)?
creo que la única vez que "const" es apropiado es cuando hay una especificación de codificación que está en contra de que es más durable que el programa se está escribiendo. Por ejemplo, si está implementando el protocolo HTTP, es apropiado tener un miembro const para "GET" porque eso nunca cambiará, y los clientes ciertamente pueden codificarlo en sus aplicaciones compiladas sin preocuparse de que tendrá que cambiar el valor más tarde.
Si hay alguna posibilidad de que necesite cambiar el valor en versiones futuras, no use const.
¡Oh! Y nunca suponga que const es más rápido que un campo de solo lectura a menos que lo haya medido. Hay optimizaciones de JIT que pueden hacer que sea exactamente lo mismo.
Debe usar const siempre que pueda establecer el valor en la declaración y no tenga que esperar al constructor.
readonly es útil cuando la inicialización no es directa.
const se puede usar cuando esté seguro del valor antes de que se compile.
En cierto modo, de sólo lectura es un tiempo de ejecución const const & es un valor constante de tiempo de compilación.
EDIT: Si nos fijamos en algo de código usando www.koders.com, se dará cuenta de que hay un uso de sólo lectura, donde podría haber sido utilizado const. Creo que la razón detrás de eso podría ser que es modificable en el constructor (si es necesario). En el caso de const (especialmente público), tiene la posibilidad de romper el código del cliente dependiendo de su código.
Puede usar un valor const como caso en una instrucción switch, fwiw.
const no se puede utilizar para las clases o estructuras (a excepción de las constantes de cadena y nulo, como el Sr. Skeet señaló), sólo para los tipos de valor y se accede a campos estáticos. El valor de un const se establece en tiempo de compilación y debe establecerse cuando se declara.
readonly se puede utilizar para cualquier cosa excepto enumeraciones y puede ser un campo estático o de instancia. El valor de solo lectura se establece en tiempo de ejecución y se puede establecer de forma diferente según el constructor al que se llame.
Here's a good page para una visión general de la const, de sólo lectura y las palabras claves estáticas.
Flat out incorrecto. Creo que has confundido tus idiomas, esto es C++. – Arafangion
Mi error, de alguna manera, pensé que era C++. Parece que * I * mezcló mis idiomas ... – Arafangion
const se puede usar con tipos de referencia, es solo que las únicas constantes de tipo de referencia son constantes de cadena y nulo. –
Una breve sinopsis sobre las diferencias entre 'const' y 'sólo lectura' en C#: 'const':
- no puede ser estática.
- El valor se evalúa en tiempo de compilación.
- Iniciado en la declaración solamente.
'sólo lectura':
- puede ser o bien a nivel de instancia o estática.
- El valor se evalúa en tiempo de ejecución.
- Se puede inicializar en declaración o por código en el constructor.
Corrección: los Estados const anterior no puede ser estática. Ese es un nombre inapropiado. No pueden tener aplicada la palabra clave estática porque ya son estáticos.
Así que utiliza const para elementos estáticos que quiere evaluar en tiempo de compilación.
Un buen uso de const es para llaves de pares clave/valor. Por ejemplo, si todavía está utilizando AppSetting (en lugar de ApplicationSettings), realmente no tiene sentido cargar el nombre de la clave de una configuración. Si se usa en varios lugares, pega la llave en una const.
Debería preferir el modificador que se prueba en el tiempo de compilación sobre el modificador que se prueban durante el tiempo de ejecución (en este contexto, const sobre readonly). Y siempre debe usar los modificadores que soportan la semántica que necesita. Si algo no está destinado a ser modificado, protéjalo o alguien le escribirá algo (por accidente o por ignorancia).
Normalmente solo uso const para cosas que sé que nunca cambio como la temperatura de congelación.
Prefiero el readonly para cosas que podrían potencialmente cambiar. De esta manera, solo necesito recompilar un dll si ocurre un cambio. Una excepción a esta regla de oro es si la variable es privada/protegida/amigable para su propio ensamblaje. En esos casos, es seguro usar const.
Una declaración peligrosa: ¿con qué temperatura ambiente estamos congelados? :RE – Gusdor
"Si hay alguna posibilidad de que deba cambiar el valor en futuras versiones, no use const". No estoy siguiendo tu lógica. Parte del punto de una constante es que puedes cambiarlo en una versión futura. – Powerlord
Si una constante es más pública que "interna" (o si solo es interna pero tiene InternalsVisibleTo), los compiladores de IL pueden copiar el valor constante en ensamblados de referencia. Esto significa que si envía una nueva versión y cambia la constante, ahora estará fuera de sincronización con sus consumidores. –
@AndrewArnott ¡Gracias por esa última aclaración, me atrevo a decir que es un punto bastante importante! – AgentKnopf