Constantes en C

[L3m0n]

Buenas, el tema es preguntaros como manejáis vosotros las constantes en C, y que veis mejor usar si el típico #define, un enum o un const int (aunque este último no funciona demasiado bien en C).

[amchacon]

const de C++

Me parece mejor los const porque resulta menos ambiguo. Desde el principio sabes el tipo de dato que guardas, mientras que con un define hay que hacer una conversión implicita (ya sea float, double, int...).

[vosk]

Si no importa el valor a mi personalmente me gustan los enum, p.ej. un array con enteros pero donde cada entero simboliza una cosa, el enum es la lista inteligible de lo que hay en el array

Código:

enum {
    COLOR,
    SIZE,
    EFFECT,
    ATTRIBUTE_COUNTER
} ATTRIBUTES;

int attributes[ATTRIBUTE_COUNTER] = {
	0xff0000,
	14,
	0
};

Me parece mas asequible para casos en que aun siendo datos constantes dentro de la instancia no lo sean dentro de la aplicacion (o esten definidos por defecto pero puedan ser personalizables).

Pero si debo guardar algun tipo de dato concreto para todas las instancias de una misma aplicacion suelo usar una cabecera con defines

Código:

#define APP_NAME "Nombre Aplicacion"
#define APP_SVERSION "1.0"
#define APP_USERAGENT "NomApp/1.0"

#define DEF_WIDTH 800
#define DEF_HEIGHT 600

En caso de librerias que necesitan guardar tipos de datos acostumbro a bloquear memoria para un struct (o los que necesite) y guardo ahi todo lo que sea de la libreria.

Saludos
vosk

[guzzano]

Depende del caso. Generalmente uso #define cuando sé que es algo muy especifico. Recuerda que un #define puede sustituir a otro. Si tenemos en un header #define ERROR_ABRIR -1 y en otro el mismo pero con diferente valor, se sustituirá y en caso de debuggear será algo más difícil. Son las clases de errores que se puede cometer sin darse cuenta y al final dan un dolor de cabeza. Recordemos que es #define es un preprocesador, y sólo está sustituyendo los valores en el programa, es difícil debuggear pues sólo es una sustitución a donde se le hace referencia.

Enum es algo más flexible, más seguro y más fácil de darse cuenta en caso de debuggear.


Saludos.

[ElPatoGarrido]

Código:

enum {
    COLOR,
    SIZE,
    EFFECT,
    ATTRIBUTE_COUNTER
} ATTRIBUTES;

int attributes[ATTRIBUTE_COUNTER] = {
	0xff0000,
	14,
	0
};

Me ha confundido ese codigo, ¿que hace exactamente?, se que el enum es una enumeracion y todos los valores dentro de el los representan enteros, pero con lo de attributes quede colgado...

[vosk]

Es un ejemplo de como me organizo las cabeceras y los datos a usar. En este ejemplo las constantes enumeradas son la forma 'humana' o facil de identificar los datos que hay en un array de datos tambien constantes en una instancia de la aplicacion.

La idea está en que las constantes pueden afectar solo a determinadas partes de la aplicacion (una ventana de configuracion, un visor, etc lo que sea) y ademas pueden ser personalizables (si por ejemplo tengo un visor con una constante que simboliza el nivel de detalle, puedo dejar que sea personalizable o no, si no es personalizable pongo un #define y listos, pero si es personalizable debo guardarla en una variable). Por eso tal vez no sean constantes para toda la aplicacion pero si para determinadas partes de ella: puedo iniciarlas con un valor por defecto (por si falla algo) pero durante la carga les asigno el valor (las relleno con los valores personalizados previamente guardados).

En el caso del enum el valor en si de cada cosa no es importante (por eso lo comento en la parte de que no me importa el valor que tengan), lo importante es que esten relacionados con los datos de otra lista (que tambien puede ser constante).

Hasta aqui ok, pero para que complicarlo tanto? Puedes pensar que en el ejemplo con solo 3 const int ya lo tengo solucionado y aun queda mas facil. El problema esta cuando tienes mas de 3 constantes, y si ademas son personalizables tendras que guardarlas en algun sitio y (aunque pueda hacerse) no vas a cargarlas una por una, y menos aun si te las descargas como pack de enteros de algun servidor. Esto te permite serializar el trabajo.

El ejemplo que colgué es la idea de como estaba maquetado un codigo que hice (no se cuando) para una GUI para Allegro. En los objetos de esa gui no solo tenia una lista de 3 atributos, sino que habia nosecuantos para cada uno (colores de: fondo / letra / borde / fondo con foco / letra con foco / borde con foco, tamaños de letra / borde, margenes, etc no me acuerdo que mas tenia). En ese caso no voy a crear una lista de 15 const int constantes para cada objeto y que sean variables para cada instancia del objeto, ok? Esas listas de enteros podian ser cargadas directamente de un archivo de configuracion, es decir, que se carga todo un paquete de enteros y como puedes imaginar no voy a ir desgranando cada elemento para asignarlo a un consta char que tengo por ahi, sino que lo guardo en un array de enteros y del cual se la funcion de cada elemento por la enumeracion.


"... pero con lo de attributes quede colgado..."

Solo lo puse a modo de ejempo, podria haber rescatado trozos de codigo de otras aplicaciones y el nombre tampoco tendria sentido; ademas parece que tampoco tiene sentido tanto codigo solo para 3 elementos, puse solo 3 para simplificar y los rellené manualmente para que se vea lo que quiero hacer.

La funcionalidad es esta: imagina que cargas una lista de enteros de un archivo y esos enteros son los atributos de un objeto (o aunque no la cargues de un archivo sino que la tengas en una cabecera de datos constantes para la aplicacion), tienes una lista de atributos con datos pero no sabes en que orden, o si lo sabes pero no vas a acceder a ellos directamente con los indices (se supone que por dentro de los codigos no tiene que haber datos hardcoded), es decir que si quieres recuperar el color de la lista de atributos no usaras 'atributos[0]' aun sabiendo que bajo el indice 0 esta el valor del color sino que usaras 'atributos[INDICE_COLOR]'.

No era mi intencion liarla tanto :)
Saludos
vosk