[bcn-pm] Curso; dudas(regex, substr vs unpack, subrutinas)

Gonzalo Pérez de Olaguer Córdoba gpoc a iies.es
dij abr 11 21:38:05 PDT 2013


Hola Sergio González Rodríguez <sergiogoro86 a gmail.com>
el Thu, 11 Apr 2013 20:09:45 +0200 escribiste:

> 2.1) substr vs unpack
> 
> En el Perl cookbok (cap.1 accessing substrings:
> http://docstore.mik.ua/orelly/perl/cookbook/ch01_02.htm ) dice que podemos
> usar unpack para extraer substrings más rapidamente que con substr.
> 
> Teniendo una $cadena = 'cadena de texto'
> Podemos extraer el 'de' así:
>     substr($cadena, 6, 3);
>     o asi
>     unpack("x7 A2", $cadena);
> 
> He mirado el perldoc de unpack(
> http://perldoc.perl.org/functions/unpack.html ), y otro tutorial(
> http://www.perlmonks.org/?node_id=557655 )
> y no me queda nada claro "de qué va el unpack..." simplemente que es más
> rápido que el substr porque lo dice el cookbook...
> 
> El debate sería: ¿Qué os parece usar el unpack como en este ejemplo frente
> al substr? ¿Lo usáis? ¿Cuando y cuando no?

substr trata la cadena como una lista de caracteres
unpack trata la cadena como una lista de octetos

Sólo son intercambiables si se utiliza un juego de caracteres que
asigne un octeto a cada carácter. No serviría para utf8, por ejemplo.

Yo no lo usaría nunca.

> 2.2) Llamadas a subrutinas
> marine();
> o
> &marine();
> 
> ¿simple cuestión de estilo o tiene alguna otra implicación?

marine() llama a marine con cero argumentos

&marine llama a marine pasándole los argumentos de la función
donde se ejecuta la llamada, de forma que marine verá los mismos
argumentos que dicha función. No es equivalente a marine (@_),
pues en este último caso marine recibe una copia de @_, mientras que
&marine realmente recibe (y puede modificar) los mismos
argumentos que tiene la función donde se llama.

&marine() es una cosa rara que equivale a marine()

> 2.3)Expresiones regulares
> Leyendo de un archivo con líneas que contienen lo siguiente:
> FBtr123;blablabla
> Y
> FBtr123,FBtr567,FBtr120;blabla
> 
> Para almacenar estos match estoy haciendo:
> push(@FBtr, $1) if ($line=~/(FBtr\d+);/ || $line=~/(FBtr\d+,.+);/ )
> #guardar un match si sólo hay uno, y guardarlos todos si sólo
> ¿Es esto lo mejor?

Eso aceptaría, por ejemplo, "FBtr123,esto_no_me_lo_esperaba;blabla"

> ¿o seria mejor así?
> push(@FBtr, $1) if ($line=~/(FBtr\d+);||(FBtr\d+,.+);/ )

push @FBtr, $1 if $line =~ m/^(FBtr\d+(,FBtr\d+)*);/;

> *empecé a descubrir algo de los lookahead,  y pensé que podría
> implementarlo para ver si hay 'un solo fbtr'  o 'más de uno' pero creo que
> también eso sería liar el rizo innecesariamente ¿os parece?

Un lookahead te pillaría FBtr123,FBtr123,FBtr123,... pero no una
línea con FBtr que tuviesen distintos números.

> 2.4) Paso de argumentos a subrutinas
> Pasando por valor, la subrutina se hace una copia interna del argumento,
> así que no podemos devolverlo fuera de la sub (o si lo devolvemos no será
> el modificado dentro de la sub)
> Pasando por referencia, la sub puede modificar dichos argumentos.
> Pero, si quisiera pasar un array, aunque no quiera que lo modifique; ¿
> Debería pasarlo referenciado, por que si no hará la ¿expansión?/flatten del
> array ?
> Es decir
> $marine($a, \@b) #Bien?
> &marine($a, @b) #Mal porque expande @b?

Si la función llamada modifica localmente los argumentos querrás pasar
el valor @b y no la referencia \@b, para que los cambios locales no afecten
al array @b

Si quieres que los cambios locales actúe sobre @b deberás pasar la referencia,
a menos que hagas algo como esto: @b = marine ($a, @b);

Si @b es grande pasar la referencia consumirá mucho menos tiempo
y memoria que pasar por valor, pues en este último caso se está
clonando el array.

Saludos,
Gonzalo.

-- 
Gonzalo Pérez de Olaguer Córdoba <gpoc a iies.es> --- www.gpoc.es
PGP key 2861C704 --- F206 5671 6789 425D 111C  1302 214F 1934 2861 C704
-------------- part següent --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: no disponible
URL: <http://mail.pm.org/pipermail/barcelona-pm/attachments/20130412/9b2a8131/attachment.bin>


Més informació sobre la llista de correu Barcelona-pm