|
このページは大阪弁化フィルタによって翻訳生成されたんですわ。 |
Para poder soportar compiladores que no conocen la palabra clave `const', o quiz疽 usan una palabra clave diferente, el s?bolo de preprocesador AL_CONST es usado en lugar de `const'. Note que en la documentaci? se usa `const' para que sea m疽 legible.
Estos son, generalmente, totalmente transparentes al usuario. No he cambiado
el comportamiento de ninguna funci?; ?icamente los tipos de los par疥etros.
B疽icamente, si puede pasar a una funci? type* ptr, entonces
puede pasar const type* ptr sin ning? problema adicional.
Algunas funciones callback tienen ahora un tipo diferente - usan punteros `const' en lugar de punteros no constantes. Por lo que se, un compilador Me doy cuenta de que esto es un cambio a la API de Allegro, y que supuestamente hay que evitar 駸tos a toda costa, pero esencialmente corrige un fallo en Allegro y a la vez modifica el comportamiento. Por favor note que para la funci? Unicode ugetx(), he proporcionado una versi? alternativa ugetxc(), que toma un par疥etro `const char**' a diferencia del par疥etro `char**'. Esto es porque es v疝ido pasar tanto un `char**' como un `const char**', pero desafortunadamente no hay forma de decirle al compilador cu疝 queremos.
Allegro representa tanto la pantalla como un bitmap con un mismo objeto: un BITMAP. Desafortunadamente, estas dos cosas pueden ser muy diferentes. Por ejemplo, leer un pixel de un bitmap aparentemente no lo modifica, pero si estamos leyendo de una pantalla, entonces es posible que deba ser alterado alg? par疥etro de la tarjeta de v?eo para seleccionar la l?ea correcta, etc.
Por consiguiente, un par疥etro const BITMAP no tiene sentido, y no se usa en ning? punto de la librer?. Esto es desafortunado, pero no veo ning? modo de solucionarlo.
S?o he probado esto con DJGPP 2.95.2, por lo que si tiene experiencias en las que esto no funciona (he intentado que los ports Linux y BeOS funcionen correctamente, pero no puedo garantizarlo...) m疣dame por email el