Tengo una duda, cuando estas declarando constantes puedes hacer por ejemplo esto:
CONST
BYTE HOLA = 3;
END
¿Ponerle el byte o cualquier otro dentro de const?
Otra, en todos los proyectos el .prg que se ejecuta el primero tiene que tener lo de PROGRAM NOMBRE;
Me imagino que si, si lo puedes hacer como global...
Global
byte A = 0;
Pero el END sobra.
Pero me refiero si dentro de un CONST puedo poner lo de BYTE NOMBRE = 2; ?
Sipo, un const es una variable que no cambia su valor.
Si lo que quieres es hacer constantes tipo C puedes usarlas igual:
#define NOMBRE_CONSTANTE "valor"
ahí ya no puedes poner el tipo de dato. A este tipo de constantes se les llama macros y son sustituidas en tiempo de compilación por su valor, a diferencia de las "const" que son sustituidas en tiempo de ejecución.
Gracias por lo de las constantes :)
Otra cosa
¿ El primer .prg que se ejecuta tiene que llevar obligatoriamente lo de PROGRAM NOMBRE; ?
Hombre claro que si, lo de separar el programa en trozos (.prg's o libs o el nombre que le llames) salío despúes.
Program sólo tienes uno, aunque lo subdividas en millones de ficheros externos .prg
El END no sobra.
En vez de PROGRAM nombreprograma; se puede poner PROCESS Main() en el cuerpo del código principal.
Gracias solo queria asegurarme
La línea program no hace falta para nada, independientemente de si pones "proces Main()" o no, pero si la pones debe ser la primera sino no compilará tu ".prg"
a ver si me explico mejor con ejemplos:
program miejemplo;
import "mod_say";
begin
say("Hola Mundo");
end
import "mod_say";
begin
say("Hola Mundo");
end
import "mod_say"
Process main()
begin
say("Hola Mundo");
end
program miejemplo;
import "mod_say"
Process main()
begin
say("Hola Mundo");
end
Todas funcionan igual pero si intentaramos esto:
import "mod_say";
program miejemplo;
begin
say("Hola Mundo");
end
Daría un error.
Por cierto el punto y coma del final de las líneas import no es necesario, pero SplinterGU siempre lo pone y creo que lo recomienda.
Al igual que el end al final de cada bloque de datos, no es necesario pero lo mismo, SplinterGU siempre lo pone y recomienda. No se exactamente el motivo, si quiere que nos lo diga.
Ejemplos de lo que digo:
import "mod_say";
const
string hola_mundo = "Hola Mundo";
end
begin
say(hola_mundo);
end
import "mod_say";
const
string hola_mundo = "Hola Mundo";
end
global
string adios ;
end
begin
adios_mundo= "Adios";
say(hola_mundo);
say(adios);
end
import "mod_say";
const
string hola_mundo = "Hola Mundo";
end
global
string adios ;
begin
adios_mundo= "Adios";
say(hola_mundo);
say(adios);
end
import "mod_say"
const
string hola_mundo = "Hola Mundo";
global
string adios ;
begin
adios_mundo= "Adios";
say(hola_mundo);
say(adios);
end
Todos compilan, en este último quité tambien el punto y coma del import para ver que también compila.
Splinter, te veo activo ahora por el foro, ¿podrías exclarecer algo más en este tema? por ejemplo el uso de ";" después de un import o el uso de "end" en el final de un bloque de datos, o el porqué de la variedad de estructuras.
Gracias.
no lo recuerdo, tendria que revisar el codigo... y ahora estoy por salir...
creo que las constantes no llevan tipo...
ah, el ; es opcional en el import... por compatibilidad es opcional...
lo correcto es...
si empieza con # no lleva ;
si no empieza con # lleva ;
los END serian lo recomendable... en algunos casos es obligatorio, en otros no.
Las CONST no llevan tipo, lo verifico, son simples sustituciones.
Hoy mismo estaba pensando en que sería interesante disponer de un ámbito a caballo entre CONST y GLOBAL, por ejemplo, necesitaba tener un vector con valores constantes para los precios de unas unidades en un juego de estrategia, y he tenido que usar GLOBAL, lógicamente.
Sería interesante poder especificar que esa GLOBAL está de alguna manera protegida y no puede verse modificada. Entiendo que basta con tener cuidado, pero el código quedaría mucho más claro si se prefija de alguna manera, por ejemplo:
GLOBAL
constant int precios [ 4 ] = 1 , 10 , 25 , 50 , 100;
END
Y yo siempre recomiendo poner END en todo bloque GLOBAL, CONST, LOCAL, queda más elegante, sobre todo si declaras varios bloque en diferentes puntos del programa, son zonas del código importantes y no está de más separarlas de las instrucciones :D
wind, sí que llevan tipo, lo que pasa es que bennu por defecto usa int. Prueba a crear una constante de una cadena e imprimirla sin poner string.
:o. Anda, pues va, esto juraría que no debiera de ser así, tendré que revisar el tema de las "const" más detenidamente.
Edit: además viene bien explícito en la wiki que no está permitido poner el tipo de la variable.
http://wiki.bennugd.org/index.php?title=Const#example
Estoy taco rallao, entonces no veo diferencia en usar #define o const, siempre supuse y usé el bloque const como las variables que en c tienen esa restrinción.
Quote from: DCelso on April 27, 2010, 12:07:08 AM
wind, sí que llevan tipo, lo que pasa es que bennu por defecto usa int. Prueba a crear una constante de una cadena e imprimirla sin poner string.
Sí que llevan tipos de dato predefinidos como string, char, float e int, pero no es posible definir constantes para estructuras, vectores, etc. A eso me refería, ya me he encontrado proyectos en los que interesaría tener un vector de enteros protegido frente a manazas :P
Nada, es una simple sugerencia para la 2.0
si, llevan tipos... la cosa es que las constantes no son variables... son como defines de datos, pero con tipo...
pues si llevan tipos la wiki está mal, Splinter me gustaría que me pusieras exactamente cómo se usan las constantes, diferencias con #defines y cuando usar una u otra constante para documentar la wiki corretamente, gracias.
creo q lo q dice splinter es que las constantes se adapatan al tipo de dato cuando son declaradas...
Const
numeroEntero = 15347;
CadenaDeCaracteres = "...";
NumeroFlotante = 12.54;
END
Sí, eso es lo que quiere decir. No es necesario prefijarlas con int ni nada parecido, se adaptan al tipo del dato que se les asigna siempre que sea un tipo de dato predefinido.
La verdad es que sobre constantes no hay mucho que discutir, tal y como están ahora mismo son simples y funcionales.
En cuanto a la diferencia entre DEFINE y CONST: Con DEFINE es posible declarar un "patrón" de sintaxis, de forma que por ejemplo puedas definir la función
#define write_simple ( a ) write ( 0 , 0 , 0 , 0 , a );
Y por ahí abajo se ha dicho que CONST sustituye en ejecución mientras que DEFINE sustituye durante la compilación. Qué friki es este lenguaje joder...
eso lo dije yo y ahora lo dudo, Splinter podrá resolvernos la duda.
Quote from: Rein (K´)ah Al-Ghul on April 27, 2010, 06:49:51 PM
creo q lo q dice splinter es que las constantes se adapatan al tipo de dato cuando son declaradas...
Const
numeroEntero = 15347;
CadenaDeCaracteres = "...";
NumeroFlotante = 12.54;
END
como tambien se adaptan las variables...
como dice wind, defines permite declarar patrones de reemplazo... las constantes, me referia a que se comportan como un define, pero a nivel de poner un valor fijo. No son variables dentro del dcb.
Ya que se esta tratando el tema de la compilacion de constantes me gustaria preguntar... ¿se ofuscar el codigo?
En caso negativo, ¿existe la opcion?
Quote from: Mr Matsusaka on April 27, 2010, 09:59:48 PM
Ya que se esta tratando el tema de la compilacion de constantes me gustaria preguntar... ¿se ofuscar el codigo?
En caso negativo, ¿existe la opcion?
Si te refieres a distribuir el juego sin el código abierto, puedes distribuir sólo el .dcb ya compilado para que sólo se interprete, aunque esa práctica la considero un poco... Gay ;D
Yo que soy así :P
Quote from: Windgate on April 27, 2010, 10:31:48 PM
Quote from: Mr Matsusaka on April 27, 2010, 09:59:48 PM
Ya que se esta tratando el tema de la compilacion de constantes me gustaria preguntar... ¿se ofuscar el codigo?
En caso negativo, ¿existe la opcion?
Si te refieres a distribuir el juego sin el código abierto, puedes distribuir sólo el .dcb ya compilado para que sólo se interprete, aunque esa práctica la considero un poco... Gay ;D
Yo que soy así :P
Yo solo quiero ofuscar para reducir el tamaño del dcb
El prg se puede distribuir aunque ofusques el dcb
Oh ya entiendo... Te refieres al renombrado automático de funciones, variables, etc. a nombres más cortos, ¿No?
Quizás con algún parámetro del bgdc, lo sabrá mejor Splinter... Yo ni idea
no entiendo...
ofuscar o comprimir?
codigo o dcb?
Quote from: SplinterGU on April 28, 2010, 01:07:42 PM
no entiendo...
ofuscar o comprimir?
codigo o dcb?
En mi anterior curro hacia juegos de movil, y alli el ofuscador era importantisimo para conseguir jars de tamaño minusculo corriendo en moviles. Al menos hasta donde yo entiendo, ofuscacion es tambien compresion de datos, pues se cambian todas las variables por letras y numeros cortisimos, reduciendo considerablemente el codigo. Aparte de eso hay luego ofuscadores que ademas te quitan codigo innecesario (comentarios, ifs vacios, variables que no se usan) reduciendo el codigo muchisimo.
Todo esto se guarda en el jar, el codigo original se queda tal cual.
Lo que estaria genial seria conseguir un dcb reducidisimo tras haber compilado con ofuscacion.
De todos modos entiendo que en proyectos de pc no sea necesario nada similar, pues no estamos tan limitados en cuanto a espacio en disco, aunque tal vez para GP2X/Wiz si vendria de lujo ahorrar un poquito de espacio.
para bennu no hay nada...
Hombre, creo que los nombres de variables y eso en el DCB no se guardan, sino referencias a direcciones de memoria de la zona reservada a contener tales cosas. Ya lo de quitar código inservible y demás ya es trabajo del programador, por eso los programadores de java se han llevado la fama de "vagos" y el lenguaje de "hacer cosas innecesarias si el programador es más o menos decente".
Ademas, me parece que java usa código en plan scripts (texto plano), bennu usa un fichero binario.
Aparte de eso, no se si el compilador hace alguna optimización similar a C o no, pero ¿el DCB va comprimido con la ZLIB? Para Bennu los ficheros con este formato de compresión son transparentes (salvo con FREAD/FWRITE, que es manual).
Maldito ofuscator, con una herramienta de ingenieria inversa (no me acuerdo cual, pero ripea classes java con bastante exito, aunque nada que ver con reflector para ripear cosas .net).
Obtenia el código fuente de los jar, eso sólo hace cambiar el nombre de las clases por letras a,b,c, etc, engorrar el código fuente para que quien lo rippea no lo entienda, eso si, cumplia con su objetivo porque hasta partes go to raras salian al obtener el código fuente...
Por cierto los comentários puedes creerte que el ofuscator no limpia, porque todos los compiladores ignoran los comentários al compilar, o sea, eso se limpia en todos los entornos :D
se guardan los nombres de las variables locales y globales, para poder ser accedidas en los modulos... no recuerdo ahora, pero las demas se deberian guardar solo si se esta en modo debug... aunque ahora mismo no lo recuerdo...