Gemix Studio

Bloque typedef, eso no me lo esperaba...
Dara un poco de claridad, la posibilidad de separar todos los typedef en un prg aparte...

- un PROCESS puede tener un parametro puntero a un tipo usuario
- una FUNCTION puede tener un parametro o un tipo de retorno a un tipo usuario

entonces los procesos no pueden recibir un typedef como parametro?

se te echaba de menos en la comunidad Cictec

bienbenido de nuevo

necro_vampire wrote:Bloque typedef, eso no me lo esperaba...

En principio no pensaba ponerlo para esta beta, pero el problema de conexion me dejo imposible seguir con el porting a iOS y las mejoras en Mac, asi que para ahorrar tiempo de espera hice esta otra feature.

necro_vampire wrote: Dara un poco de claridad, la posibilidad de separar todos los typedef en un prg aparte...

- un PROCESS puede tener un parametro puntero a un tipo usuario
- una FUNCTION puede tener un parametro o un tipo de retorno a un tipo usuario

entonces los procesos no pueden recibir un typedef como parametro?

Si que puede, pero debe ser puntero, no variable (como muestra el ejemplo)

g1tp111ricard8 wrote:Hola Cictec...

La verdad te felicito por los avances, y se ve que cada vez está quedando mucho más maduro el lenguaje y los ports....

Saludos...

Gracias ricard

SimulatorOne wrote:se te echaba de menos en la comunidad Cictec

bienbenido de nuevo

Jejeje, gracias Simu.

CicTec wrote:

necro_vampire wrote:Bloque typedef, eso no me lo esperaba...

En principio no pensaba ponerlo para esta beta, pero el problema de conexion me dejo imposible seguir con el porting a iOS y las mejoras en Mac, asi que para ahorrar tiempo de espera hice esta otra feature.

necro_vampire wrote: Dara un poco de claridad, la posibilidad de separar todos los typedef en un prg aparte...

- un PROCESS puede tener un parametro puntero a un tipo usuario
- una FUNCTION puede tener un parametro o un tipo de retorno a un tipo usuario

entonces los procesos no pueden recibir un typedef como parametro?

Si que puede, pero debe ser puntero, no variable (como muestra el ejemplo)

me referia a que esperaba tener directamente los typedef en cada uno de los bloques (private, gloabal...)
aunque de esta forma le da mas claridad...

me parece curioso que no se pueda usar de la misma manera en ambos casos, tanto pasando el puntero y/o variable

necro_vampire wrote: me referia a que esperaba tener directamente los typedef en cada uno de los bloques (private, gloabal...)
aunque de esta forma le da mas claridad...

Ah, no tendria sentido ponerlos en los bloques private, etc..., porque es una declaracion de tipo, no de dato, se podria permitir el bloque typedef en los procesos, pero no tiene mucho sentido, porque la visibilidad seria solo a nivel de la instancia.

necro_vampire wrote: me parece curioso que no se pueda usar de la misma manera en ambos casos, tanto pasando el puntero y/o variable

Se podria poner tb de variables o de array, no lo he puesto por cuestiones de performance, porque un tipo usuario podria ser muy grande en cuanto a cantidad de datos y hacer el pasaje por copia de eso, supone una gran cantidad de perdida de velocidad en la llamada del proceso/funcion (ademas de la cantidad de memoria necesaria).
Con los punteros solo se pasa un dato de tamaño de la palabra de la maquina y para la gran mayoria de los casos, acceder al dato mediante el puntero es mas que suficiente.

ya me explicareis en un post totalmente nuevo sobre TYPEDEFS y esas cosas, por que no me entero de naaa xDD
de esta feature.
ni se para que uso see le da, yo ya me conformo con la STRUCT, no se.
soy torpe para estas cosas.

Cuando saldra la beta, saldra un post en Documentacion explicandolo detalladamente, aunque basicamente son como las structs, pero mas flexibles, seguramente te haran mucha falta en futuro, especialmente en proyectos largos, asi que sea bueno aprenderlos.

espero que sean mas rapidas en peerformance, y consuman menos memoria ram.
yo aveces uso grandes STRUCTS y pesan mucho. Lolita Land es uno de ellos.

La performance es igual (aunque la nueva beta mejora notablemente la velocidad), el consumo de RAM igual o mayor, dependiendo el numero de declaraciones de datos del tipo.