23.08.2010, 02:53
(
Последний раз редактировалось MrDeath537; 23.08.2010 в 03:16.
)
Porque no deberнas crear tus strings con 256 celdas.
por ******, traducciуn MrDeath
Contenidospor ******, traducciуn MrDeath
- Contenidos
- Introducciуn
- Fondo
- їPor quй no deberнas usar 256 celdas?
- Porque es lento
- No lo necesitas (1)
- La mбxima entra es 128
- La mбxima salida es 128
- No lo necesitas (2)
- Uso de apilaciуn
- Strings comprimidos
- їCuбndo deberнa usar 256 celdas?
- SQL
- Lectura de archivos
- Conclusiуn
Las personas tienen muchas visiones distintas sobre los strings en Pawn, mayormente con sus tamaсos. Mucha gente piensa que esos strings no pueden ser mayores a 256, їpor quй?, no lo sй. Pareciera que es un lнmite sin necesidad y en efecto el lнmite no existe. Otras personas piensan que esos strings tienen que tener 256 celdas para sin aparetne razуn. No importa que tan largo crйen el string, el string en PAWN es exactamente lo mismo que cualquier otro array (matrнz), parece que no tienen problemas con otros arrays (matrices)
Nota: la mayorнa de la gente usa ya sea 255 o 256, pero esos son equivalentes como basura como cualquier otro.
Fondo
Un string en Pawn es un array (matrнz) de caracteres, no diferente a cualquier otro array. Los strings son nulos terminados, esto significa que todos ellos tienen el caracter "\0" (nulo) al final (el cуdigo ASCII 0, es diferente a el caracter numйrico 0, el cuбl tiene el cуdigo ASCII 4
. Si tenйs los siguientes strings:pawn Код:
new str[5] = "hola";
pawn Код:
new str[5] = {'h', 'o', 'l', 'a', '\0'};
pawn Код:
new str[5] = {104, 111, 108, 97, 0}; // NO sй si estбn bien los caracteres, intentй escribirlos en base a la lуgica de los que puso ****** en su tutorial.
En PAWN todas las variables son establecidas a 0 cuando son declaradas/creadas, esto significa que cuando hacйs:
pawn Код:
new str[256];
pawn Код:
new str[256];
for (new i = 0; i < 256; i ++)
{
str[i] = 0;
}
їPor quй no usar 256 celdas?
- Es lento
Son optimizadas en el ensamblador de lнnea para hacerlo, no estбn interpretadas en Pawn. Pero esto significa que AMXModX escribiу otro operador, muy similar al "new", el cuбl declara una variable pero no la pone en blanco, para obtener este exacto problema.
[anchor=d1]
- No lo necesitas (1)
Quote:
|
Originally Posted by X_Cutterz
pawn Код:
|
Segъn mi cuenta son 69 caracteres en ese string, 2 de los cuales son "%d" no apareceran en el final del string, entonces son 67 en el final del string. Ya sabemos que tan largo puede ser el nъmero (4 dнgitos). Y sabemos que todos los strings requieren el caracter nulo al final, entonces la longitud del string puede ser esta:
69 - 2 + 4 + 1 = 72
72 celdas, entonces їpor quй usar 256?, es sуlo gastar 184 celdas (736 byes - Ўestб cerca de ser un kilobyte de memoria gastada!)
- La mбxima entrada es 128
- La mбxima salida es 128
- No lo necesitas (2)
pawn Код:
public OnPlayerCommandText(playerid, cmdtext[])
{
new string[256], cmd[256];
cmd = strtok(cmdtext, idx);
if (strcmp(cmd, "/num", true) == 0)
{
format(string, sizeof (string), "Numero aleatorio: %d", random(27));
SendClientMessage(playerid, 0xFF0000AA, string);
}
}
pawn Код:
new string[256], cmd[256];
pawn Код:
new string[256];
Una manera mбs eficiente de esta versiуn serнa.
pawn Код:
public OnPlayerCommandText(playerid, cmdtext[])
{
new string[128]; // cmdtext jamбs serб mayor a 128
string = strtok(cmdtext, idx);
if (strcmp(string, "/num", true) == 0)
{
format(string, sizeof (string), "Numero aleatorio: %d", random(27)); // Sуlo necesitamos 21 caracteres aquн, pero 128 se necesita arriba, entonces el tamaсo de la variable estб justificado.
SendClientMessage(playerid, 0xFF0000AA, string);
}
}
- Strings comprimidos
pawn Код:
new
gVar = 2;
stock StackUse()
{
new
str[9];
format(str, sizeof (str), "gVar = %d", gVar);
SendClientMessageToAll(0xFF0000AA, str);
if (gVar)
{
gVar--;
StackUse();
}
}
Ahora imaginб este cуdigo:
pawn Код:
new
gVar = 2;
stock StackUse()
{
new
str[256];
format(str, sizeof (str), "gVar = %d", gVar);
SendClientMessageToAll(0xFF0000AA, str);
if (gVar)
{
gVar--;
StackUse();
}
}
A alguno de ustedes le ha pasado esto (o algo parecido) cuando compilaban:
Код:
Header size: 216 bytes Code size: 776 bytes Data size: 528 bytes Stack/heap size: 16384 bytes; estimated max. usage: unknown, due to recursion Total requirements: 17904 bytes
Код:
Header size: 200 bytes Code size: 588 bytes Data size: 512 bytes Stack/heap size: 16384 bytes; estimated max. usage=10250 cells (41000 bytes) Total requirements: 17684 bytes
El primer error que postiй significa que estбs intentado usar mбs memoria de la disponible, pero porque allн la funciуn esta auto-usandose el compilador no puede decir exactamente cuando memoria mбs. El compilador no puede saber cuantas veces se usa, como en el ejemplo de arriba podrнan cambiar los nъmeros. El segundo error fue generado por alguna acciуn sin recursiуn.
Esto se aplica a TODOS los arrays, pero los strings tienen mayor culpabilidad.
Strings comprimidos
Una caracterнstica del PAWN raramente usada en SA-MP es comprimir strings. Los strings regulares guardan un caracter por celda y cada una ocupa 4 bytes (haciendo que las celdas de 256 sean 1 kilobyte). Los strings comprimidos guardan 4 caracteres por celda:
Descomprimido:
pawn Код:
new
string[13] = "Hola a todos!"; // 13 celdas, 52 bytes
Comprimido:
pawn Код:
new
string[13 char] = !"Hola a todos!"; // 4 cells, 16 bytes
їCuбndo deberнa usar 256 celdas?
Habiendo dicho esto, en algunos casos usar arrays grandes podria ser ъtil, pero deberнan ser sуlo usados cuando sea necesario.
- SQL
- Lectura de archivos
Conclusiуn
En muy pocos casos son necesitados arrays (matrices) grandes, piensa en determinar cuбnta memoria necesitбs para el array (matrнz) basandote en cuбnto necesitбs para aplicar los strings.
realmente muy utiles para los vagos (x no decir otra cosa) como vos y yo q no se gastan en contar para usar el tamaсo adecuado xD.
digo supongo xq los cmd con parametros uso dcmd :P)
