[SP-pm] [OFF-TOPIC] Masturbações Mentais sobre Undefined Behavior

[Stanislaw Pusep]

Good point!
"Undefined" é muito forte; considerando os seus argumentos, "unexpected" é
mais apropriado (até por que considera o fator humano). Por outro lado, a
ordem de keys(%hash) é perfeitamente "expected", pois as chaves iguais
produzem hashes iguais. Sendo assim, a única coisa totalmente "unexpected"
que conheço é rand(), e olha lá :P

ABS()



2011/2/14 Eden Cardim <edencardim em gmail.com>

> >>>>> "Stanislaw" == Stanislaw Pusep <creaktive em gmail.com> writes:
>
>    Stanislaw> Olha, não sei quanto aos outros participantes da lista,
>    Stanislaw> mas eu simplesmente não consigo me ater a todos esses
>    Stanislaw> detalhes :( Então nunca uso esse operador que me confunde
>    Stanislaw> (PARA MIM, é um "Undefined Behavior"), preferindo fazer
>    Stanislaw> "à moda antiga" (última coluna). Enfim, sou desses caras
>    Stanislaw> que enchem qqer operação de ()'s, tipo: ((($x / $y) - $z)
>    Stanislaw> > 0).  Enfim, o que quero dizer é que o Perl tem um
>    Stanislaw> imenso potencial de produzir código cheio de
>    Stanislaw> Pseudo-undefined Behavior;
>
> Acho que você está distorcendo o significado de "undefined", que
> significa "não definido". O operador ~~ tem uma semântica bastante
> complexa sim, mas o comportamento dele *é definido* para todo e qualquer
> caso onde ele for utilizado, o que significa que se ele comporta-se
> diferentemente da definição presente na documentação, existe um bug na
> implementação. A noção de "pseudo-undefined behaviour" não faz o menor
> sentido, na verdade o que você queria dizer era "behaviour
> unknown/ignored by myself". Se o comportamento não fosse definido, nem
> os parênteses te salvadoriam.
>
> Os dois casos de undefined behaviour em perl que eu consigo lembrar
> nesse exato momento são:
>
> keys(%hash) - não define a ordem de retorno das chaves, devido a um
> corolário da definição de hash maps.
>
> $i++ + ++$i - assim como em C, usar operadores de incremento/decremento
> mais de uma vez na mesma variável, no mesmo statement, resulta em
> undefined behaviour.
>
> Sim, perl te dá corda suficiente pra você se enforcar, mas qualquer
> linguagem com uma determinada margem de flexibilidade também. C, por
> exemplo, permite que você escreva em pontos arbitrários da memória (e
> quem vai reclamar com você é o kernel em questão). Porém, isso é um
> assunto ortogonal à definição de comportamento.
>
>    Stanislaw> por que ninguém tem obrigação de saber todas as faces de
>    Stanislaw> todos os operadores; isso sem contar as L<perlvar>.
>
> Pra poder afirmar que existe um "undefined behaviour" dentro de uma
> discussão formal sem mentir ou se equivocar, você precisa sim, no
> mínimo, conhecer todas as definições existentes.
>
> --
> Eden Cardim
> Software Engineer
> +55 73 9986-3963
> edencardim.com
> =begin disclaimer
>   Sao Paulo Perl Mongers: http://sao-paulo.pm.org/
>  SaoPaulo-pm mailing list: SaoPaulo-pm em pm.org
>  L<http://mail.pm.org/mailman/listinfo/saopaulo-pm>
> =end disclaimer
>
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20110215/48ba27df/attachment.html>