const estática vs #define

¿Es mejor usar static constvars que #definepreprocesador? ¿O tal vez depende del contexto?

¿Cuáles son las ventajas / desventajas de cada método?

Personalmente, odio el preprocesador, así que siempre iría con const .

La principal ventaja de un #define es que no requiere memoria para almacenar en su programa, ya que en realidad solo reemplaza parte del texto con un valor literal. También tiene la ventaja de que no tiene ningún tipo, por lo que puede usarse para cualquier valor entero sin generar advertencias.

Ventajas de "const " s son que pueden ser alcanzados, y pueden usarse en situaciones en las que se necesita pasar un puntero a un objeto.

Sin staticembargo , no sé exactamente a qué te refieres con la parte " ". Si está declarando globalmente, lo pondría en un espacio de nombres anónimo en lugar de usar static. Por ejemplo

namespace {
   unsigned const seconds_per_minute = 60;
};

int main (int argc; char *argv[]) {
...
}

Pros y contras entre #defines, constsy (lo que has olvidado) enums, dependiendo del uso:

1. enums:

   • solo es posible para valores enteros
   • Los problemas de choque de identificador / ámbito adecuadamente manejados bien, particularmente en clases de enumeración de C ++ 11 donde las enumeraciones para enum class Xson ambiguas por el alcanceX::
   • fuertemente tipado, pero con un tamaño int con signo o sin signo suficientemente grande sobre el que no tiene control en C ++ 03 (aunque puede especificar un campo de bits en el que se deben empaquetar si la enumeración es un miembro de struct / class / union), mientras que C ++ 11 se establece de manera predeterminada intpero el programador puede establecerlo explícitamente
   • no puede tomar la dirección: no hay una, ya que los valores de enumeración se sustituyen efectivamente en línea en los puntos de uso
   • Restricciones de uso más fuertes (por ejemplo, incrementos: template <typename T> void f(T t) { cout << ++t; }no se compilará, aunque puede ajustar una enumeración en una clase con un constructor implícito, un operador de conversión y operadores definidos por el usuario)
   • cada tipo de constante tomada de la enumeración adjunta, así que template <typename T> void f(T)obtenga una instanciación distinta cuando pase el mismo valor numérico de enumeraciones diferentes, todas las cuales son distintas de cualquier f(int)instanciación real . El código de objeto de cada función podría ser idéntico (ignorando las compensaciones de dirección), pero no esperaría que un compilador / vinculador elimine las copias innecesarias, aunque puede verificar su compilador / vinculador si le importa.
   • incluso con typeof / decltype, no puedo esperar que numeric_limits proporcione información útil sobre el conjunto de valores y combinaciones significativas (de hecho, las combinaciones "legales" ni siquiera están anotadas en el código fuente, considere enum { A = 1, B = 2 }- es A|B"legal" desde la lógica de un programa ¿perspectiva?)
   • el nombre de tipo de la enumeración puede aparecer en varios lugares en RTTI, mensajes de compilación, etc., posiblemente útil, posiblemente ofuscación
   • no puede usar una enumeración sin que la unidad de traducción realmente vea el valor, lo que significa que las enumeraciones en las API de la biblioteca necesitan los valores expuestos en el encabezado, makey otras herramientas de compilación basadas en la marca de tiempo activarán la recompilación del cliente cuando se cambien (¡mal! )

2. consts:

   • Los problemas de enfrentamiento de identificador / alcance adecuadamente manejados bien
   • tipo fuerte, único, especificado por el usuario
     • puede intentar "escribir" un #defineala #define S std::string("abc"), pero la constante evita la construcción repetida de temporarios distintos en cada punto de uso
   • Complicaciones de una regla de definición
   • puede tomar direcciones, crear referencias constantes a ellas, etc.
   • más similar a un noconst valor, que minimiza el trabajo y el impacto si se cambia entre los dos
   • el valor se puede colocar dentro del archivo de implementación, lo que permite una recompilación localizada y solo enlaces de clientes para recoger el cambio

3. #defines:

   • alcance "global" / más propenso a usos conflictivos, que pueden producir problemas de compilación difíciles de resolver y resultados inesperados en tiempo de ejecución en lugar de mensajes de error razonables; mitigar esto requiere:
     • identificadores largos, oscuros y / o coordinados centralmente, y el acceso a ellos no puede beneficiarse de la coincidencia implícita del espacio de nombres, los alias de espacios de nombres, etc.
     • Si bien la práctica recomendada de triunfo permite que los identificadores de parámetros de plantilla sean letras mayúsculas de un solo carácter (posiblemente seguidas de un número), otro uso de identificadores sin letras minúsculas está convencionalmente reservado y se espera de las definiciones de preprocesador (fuera de la biblioteca del sistema operativo y C / C ++ encabezados). Esto es importante para que el uso del preprocesador a escala empresarial siga siendo manejable. Se puede esperar que las bibliotecas de terceros cumplan. Observar esto implica que la migración de concursos o enumeraciones existentes a / desde definiciones implica un cambio en la capitalización y, por lo tanto, requiere modificaciones en el código fuente del cliente en lugar de una compilación "simple". (Personalmente, escribo en mayúscula la primera carta de enumeraciones, pero no las contiendas, por lo que también me vería obligado a migrar entre esas dos, tal vez sea hora de repensar eso).
   • Se pueden realizar más operaciones en tiempo de compilación: concatenación literal de cadenas, stringificación (tomando el tamaño de las mismas), concatenación en identificadores
     • desventaja es que dado #define X "x"y algunos Ala uso del cliente "pre" X "post", si usted quiere o necesita para hacer X un tiempo de ejecución modificables variable en lugar de una constante se fuerza ediciones en código de cliente (en lugar de sólo recompilación), mientras que la transición sea más fácil a partir de una const char*o const std::stringdado que ya obliga al usuario a incorporar operaciones de concatenación (por ejemplo, "pre" + X + "post"para string)
   • no se puede usar sizeofdirectamente en un literal numérico definido
   • sin tipo (GCC no advierte si se compara con unsigned)
   • algunas cadenas de compilador / enlazador / depurador pueden no presentar el identificador, por lo que se verá reducido a mirar "números mágicos" (cadenas, lo que sea ...)
   • no puedo tomar la dirección
   • el valor sustituido no necesita ser legal (o discreto) en el contexto donde se crea el #define, ya que se evalúa en cada punto de uso, por lo que puede hacer referencia a objetos aún no declarados, depende de la "implementación" que no necesita pre-incluirse, crear "constantes" como las { 1, 2 }que pueden usarse para inicializar matrices, #define MICROSECONDS *1E-6etc. (¡ definitivamente no lo recomiendo!)
   • algunas cosas especiales como __FILE__y__LINE__ se pueden incorporar en la macro sustitución
   • puede probar la existencia y el valor en las #ifdeclaraciones para incluir condicionalmente el código (más potente que un "si" posterior al preprocesamiento, ya que el código no necesita ser compilable si el preprocesador no lo selecciona), use#undef -ine, redefine, etc.
   • el texto sustituido tiene que estar expuesto:
     • en la unidad de traducción que usa, lo que significa que las macros en las bibliotecas para uso del cliente deben estar en el encabezado, por lo que makeotras herramientas de compilación basadas en la marca de tiempo activarán la recompilación del cliente cuando se cambien (¡mal!)
     • o en la línea de comando, donde se necesita aún más cuidado para asegurarse de que el código del cliente se vuelva a compilar (por ejemplo, el Makefile o script que proporciona la definición debe aparecer como una dependencia)

Mi opinión personal:

Como regla general, uso constsy considero que es la opción más profesional para uso general (aunque los otros tienen una simplicidad atractiva para este viejo programador perezoso).

Si esta es una pregunta de C ++ y menciona #definecomo alternativa, entonces se trata de constantes "globales" (es decir, de alcance de archivo), no de miembros de la clase. Cuando se trata de tales constantes en C ++ static constes redundante. En C ++ consttiene un enlace interno por defecto y no tiene sentido declararlos static. Por lo que es realmente acerca de constfrente #define.

Y, finalmente, en C ++ constes preferible. Al menos porque tales constantes están escritas y definidas. Simplemente, no hay razones para preferir #definemás const, aparte de algunas excepciones.

Las constantes de cadena, por cierto, son un ejemplo de dicha excepción. Con #definelas constantes de cadena d se puede usar la función de concatenación en tiempo de compilación de compiladores C / C ++, como en

#define OUT_NAME "output"
#define LOG_EXT ".log"
#define TEXT_EXT ".txt"

const char *const log_file_name = OUT_NAME LOG_EXT;
const char *const text_file_name = OUT_NAME TEXT_EXT;

PD: De nuevo, por si acaso, cuando alguien menciona static constcomo una alternativa #define, generalmente significa que está hablando de C, no de C ++. Me pregunto si esta pregunta está etiquetada correctamente ...

#define puede conducir a resultados inesperados:

#include <iostream>

#define x 500
#define y x + 5

int z = y * 2;

int main()
{
    std::cout << "y is " << y;
    std::cout << "\nz is " << z;
}

Da como resultado un resultado incorrecto:

y is 505
z is 510

Sin embargo, si reemplaza esto con constantes:

#include <iostream>

const int x = 500;
const int y = x + 5;

int z = y * 2;

int main()
{
    std::cout << "y is " << y;
    std::cout << "\nz is " << z;
}

Produce el resultado correcto:

y is 505
z is 1010

Esto se debe a que #definesimplemente reemplaza el texto. Debido a que esto puede arruinar seriamente el orden de las operaciones, recomendaría usar una variable constante.

Usar una constante estática es como usar cualquier otra variable constante en su código. Esto significa que puede rastrear el origen de la información, en lugar de un #define que simplemente se reemplazará en el código en el proceso de compilación previa.

Es posible que desee echar un vistazo a C ++ FAQ Lite para esta pregunta: http://www.parashift.com/c++-faq-lite/newbie.html#faq-29.7

• Se escribe una constante estática (tiene un tipo) y el compilador puede verificar su validez, redefinición, etc.
• un #define puede redifinarse indefinido lo que sea.

Por lo general, debe preferir const estáticos. No tiene desventaja. El procesador debe usarse principalmente para la compilación condicional (y, a veces, para trucos realmente sucios).

#defineNo se recomienda definir constantes utilizando la directiva de preprocesador para aplicar no solo en C++, sino también en C. Estas constantes no tendrán el tipo. Incluso en Cse propuso utilizar constpara constantes.

Ver aquí: static const vs define

Por lo general, una declaración constante (tenga en cuenta que no necesita ser estática) es el camino a seguir

Siempre prefiera usar las funciones del lenguaje sobre algunas herramientas adicionales como el preprocesador.

ES.31: No use macros para constantes o "funciones"

Las macros son una fuente importante de errores. Las macros no obedecen las reglas habituales de alcance y tipo. Las macros no obedecen las reglas usuales para pasar argumentos. Las macros aseguran que el lector humano vea algo diferente de lo que ve el compilador. Las macros complican la construcción de herramientas.

De las pautas básicas de C ++

Si está definiendo una constante para ser compartida entre todas las instancias de la clase, use const estática. Si la constante es específica para cada instancia, solo use const (pero tenga en cuenta que todos los constructores de la clase deben inicializar esta variable miembro const en la lista de inicialización).