|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
Los defines de preprocesador y los nombres de las estructuras est疣 EN_MAYUSCULAS. Las funciones y las variables est疣 en_min?culas. Los NombresConMay?culasMezcladas son malvados y no deber?n ser usados. Esa est?ida notaci? m_pH?gara es _realmente_ malvada, y ni si quiera deber? pensar en ella.
Todos los s?bolos deber?n ser declarados como static, a no ser que sea imposible hacerlo, en cuyo caso deber?n ser prefijados con un subrayado.
Ejemplo de d?de poner espacios:
char *p;
if (condicion) { }
for (x=0; x<10; x++) { }
funcion(foo, bar);
(BITMAP *)data[id].dat;
Los cr馘itos de autor deben ser a?didos en orden cronol?ico, y las direcciones de email no deben ser incluidas: esa informaci? se puede encontrar en el fichero principal de cr馘itos, y si s?o existe en un lugar, es m疽 f當il actualizarla cuando alguien cambie de email./* ______ ___ ___ * /\ _ \ /\_ \ /\_ \ * \ \ \L\ \\//\ \ \//\ \ __ __ _ __ ___ * \ \ __ \ \ \ \ \ \ \ /'__`\ /'_ `\/\`'__\/ __`\ * \ \ \/\ \ \_\ \_ \_\ \_/\ __//\ \L\ \ \ \//\ \L\ \ * \ \_\ \_\/\____\/\____\ \____\ \____ \ \_\\ \____/ * \/_/\/_/\/____/\/____/\/____/\/___L\ \/_/ \/___/ * /\____/ * Lea en readme.txt la informaci? de copyright. */
Las personas s?o deben ser inclu?as en la cabecera del c?igo fuente si han hecho alguna contribuci? significativa (las correcciones de una l?ea no entrada para el contribuyente. Adem疽, cualquier cosa mayor que una modificaci? min?cula debe ser a?dida al fichero docs/changes._tx, que crece desde arriba en orden cronol?ico inverso. Este fichero debe describir fichero nombrado en MAKEFILE_INC para proveer informaci? adicional espec?ica de cada plataforma. Los ficheros fuente actuales est疣 listados en el fichero makefile.lst.
Hay tres versiones de la biblioteca de funciones: alleg (versi? final), alld (depuraci?), y allp (profiling). Los ficheros objeto van en obj/compilador/version/, donde versi? es alleg, alld, o allp. Los ficheros .lib van en lib/compilador/. Algunas cosas generadas (asmdefs.inc, mmxtest.s, etc), van en el directorio ra? obj/compilador/. Las dependencias son generadas con "make depend", y van en obj/compilador/version/makefile.dep, que es inclu?o por makefile.all.
Cuando ejecuta "make clean", esto solamente borra los ficheros generados por Para pasar l?eas de comando largas a los enlazadores de MSVC y Watcom, el programa runner.exe es compilado usando gcc, para que les pueda pasar un n?ero decente de par疥etros. Este programa salva los par疥etros en un fichero temporal, y entonces invoca al programa usando el fichero con los argumentos como entrada.
para inclu? el n?ero de versi? en cosas como el nombre de fichero de la DLL.
allegro.h vive en el directorio include/. Este incluye otros ficheros de otros ficheros de cabecera en include_sistema/allegro/. Esto evita inundar los directorios de sistema con cientos de ficheros de cabecera, y a la vez permite a un programa incluir solamente <allegro.h>, y hace posible el acceso a las cabeceras internas mediante #include <allegro/include/aintern.h>.
allegro.h incluye alconfig.h, el cual detecta la plataforma actual e incluye un fichero de cabecera adicional para este compilador (aldjgpp.h, almsvc.h, alwatcom.h, etc). Ese fichero de cabecera adicional define un grupo de macros que describen el sistema, emula lo que sea necesario para hacer que el c?igo compile adecuadamente, y opcionalmente define ALLEGRO_EXTRA_HEADER y ALLEGRO_INTERNAL_HEADER si va a necesitar otros ficheros de cabecera espec?icos de la plataforma.
Tras incluir el fichero de cabecera de plataforma, el resto de alconfig.h define un mont? de macros gen駻icas de ayuda a sus valores por defecto, pero s?o si el fichero de cabecera de plataforma no las ha sustituido por algo espec?ico.
allegro.h contiene definiciones de estructuras y prototipos de funciones. Al final del fichero, incluye alinline.h, el cual define todas las rutinas inline y los wrappers vtable, junto con versiones en C de las rutinas definido, allegro.h lo incluye al final. Este define suele incluir aldos.h, alwin.h, etc, que definen cosas espec?icas para cada plataforma, como valores ID para los drivers hardware. A diferencia de los ficheros de plataforma incluidos al principio de allegro.h, 駸tos son espec?icos para cada SO en vez de para cada compilador, por lo que el mismo fichero alwin.h puede ser usado tanto con MSVC como con MinGW32. Describen funciones de la biblioteca relacionadas con la plataforma, mientras los ficheros de cabecera previos describ?n la sintaxis b疽ica del lenguaje.
aintern.h es como internal.h en versiones previas de Allegro, y define rutinas compartidas entre m?tiples ficheros de c?igo fuente, pero que generalmente no queremos que sean usadas por programas de usuario. Para En plataformas que tienen rutinas API espec?icas y no portables, 駸tas deber?n ir en un fichero de cabecera especial en la ra? del directorio include, ej: winalleg.h. Este puede ser incluido por programas de usuario que quieran acceder a estas rutinas, a la vez que se les indica claramente que al incluir este fichero de cabecera est疣 escribiendo c?igo no portable.
Todos los prototipos de funciones de cabecera deben usar la macro AL_FUNC(). Las rutinas en l?ea usan la macro AL_INLINE(). Las variables globales usan AL_VAR() o AL_ARRAY(). Los punteros globales a funciones usan AL_FUNCPTR(). Los punteros a funciones que se pasan como par疥etros a otras rutinas o que est疣 almacenados en una estructura usan AL_METHOD(). Esto puede parecer innecesario, pero da mucha flexibilidad para a?dir a una DLL especificadores de importaci?/exportaci?, marcadores de convenci? de llamada como __cdecl, e incluso transformar los nombres de los s?bolos en algunos compiladores. Si biblioteca. Si quiere incluir una funci? en l?ea en su c?igo fuente, use la macro INLINE. Para declarar arrays de tama? cero en una estructura, use int x[ZERO_SIZE]. Para usar enteros de 64 bits, declare la variable como lo que debe ser extremadamente cuidadoso manipulando cadenas de texto. ｡No lo olvide y nunca use una rutina libc con ellas!
Use las funciones Unicode para manipular todo el texto: lea los detalles en la documentaci?. Cuando reserve memoria para su cadena, asuma que cada proveer usted el espacio de conversi?, reservando buf como un objeto temporal en la pila.
Para convertir en sentido contrario (ej. antes de pasar una cadena de texto de Allegro a una rutina de SO que espera datos ASCII), llama a indefinidamente), tras convertirla al formato de codificaci? actual. Esta funci? es genial porque le evita la molestia de reservar memoria para los datos convertidos, y porque permite que la cadena sea reemplazada por las traducciones de language.dat. Debe tener la seguridad de pasar siempre cadenas constantes a get_config_text(), en vez de texto generado o datos de otras cadenas variables de texto: esto es para que el script findtext.sh pueda encontrar f當ilmente las cadenas que necesiten ser traducidas.
Los desplazamientos de estructuras est疣 definidos en asmdef.inc, el cual es generado por asmdef.c. Esto permite usar al c?igo en ensamblador nombres legibles por un humano para los miembros de una estructura, y ajustarlos autom疸icamente cuando se modifique la estructura para a?dir m疽 valores, por lo que siempre siempre se ajustar疣 al formato interno de las estructuras de C.
El c?igo en ensamblador debe usar la macro FUNC(nombre) para declarar el comienzo de una rutina, y GLOBL(nombre) cuando se quiera acceder a un s?bolo externo (ejemplo: una variable o funci? de C). Esto es para manejar las transformaciones de nombres de un modo portable (COFF requiere un subrayado como prefijo, ELF no lo necesita).
Puede modificar %ds y %es en ensamblador, siempre y cuando recupere sus valores. Si USE_FS y FSEG est疣 definidos, tambi駭 puede modificar %fs, de otro modo esto no es requerido, y puede usar sin problemas el acceso con nearptr para todo.
No asuma que los c?igos de operaci? MMX est駭 soportados: no todas las versiones de ensamblador los conocen. Compruebe la macro ALLEGRO_MX, y sustituya su c?igo MMX en caso de que estas instrucciones no est駭 disponibles.
Cualquier rutina portable que se ejecute en un temporizador o una funci? callback de entrada debe estar fijando (lock) todo el c?igo y datos que toque. Esto se hace poniendo END_OF_FUNCTION(x) o END_OF_STATIC_FUNCTION(x) tras toda definici? de funci? (no obstante, esto no es requerido si declara la funci? como INLINE), y llamando a LOCK_FUNCTION() en alguna parte del c?igo de inicializaci?. Use LOCK_VARIABLE para fijar variables