Se não me engano, zerar as variáveis locais tem mais a ver com a arquitetura do sistema do que especificação do compilador. Já programei em C (não C++) para Solaris em x86 (atrocidade!!!), e não me lembro dele zerar nada sozinho. Sendo que C (e, em menor grau, C++) é o mais "genérico" possível, nada mais justo do que deixar certas coisas "em aberto". Agora, existir operador ',' em algumas implementações e outras não, aí é sacanagem!
ABS() 2011/2/14 Blabos de Blebe <[email protected]> > No gcc alguns undefined behaviors resultam em segmentation fault, como > é o caso da divisão por zero. Já outros podem ou não emitir warnings > conforme você especificar durante a compilação. > > Os compiladores normalmente fazem um bom trabalho ao escolher o que > fazer com um undefined behavior. > > Mas o ponto é: > > Uma coisa é você desconhecer como funciona a feature, outra é a > linguagem especificar que ela não faz idéia do que pode acontecer. > > Isso sim é bizarro, na minha opinião. > > Abraços > > 2011/2/14 Tiago Peczenyj <[email protected]>: > > E se o compilador jogasse um warning quando estamos usando algo que > > claramente tem undefined behavior (como alguns casos tabelados) ? > > Seria o melhor dos dois mundos: ou o programador sabe com certeza o que > esta > > fazendo ou o compilador/interpretador/etc avisa "hum... danadinho..." > > > > 2011/2/14 Blabos de Blebe <[email protected]> > >> > >> >> Enfim, o que quero dizer é que o Perl tem um imenso potencial de > >> >> produzir > >> >> código cheio de Pseudo-undefined Behavior; por que ninguém tem > >> >> obrigação de > >> >> saber todas as faces de todos os operadores; isso sem contar as > >> >> L<perlvar>. > >> > >> Este email também tem potencial pra produzir undefined behavior. > >> Deveríamos parar de escrever emails por causa disso? > >> > >> Opa, espere um momento. Como assim um programador não deve saber > >> exatamente o que ele está usando? > >> > >> É claro que o programador *tem* sim que conhecer exatamente como > >> funciona cada token que ele está usando, senão é melhor ir vender água > >> de coco na praia. > >> > >> É por isso que certas empresas abrem certas falhas de segurança em > >> certos servidores de produção. > >> > >> O problema é que Perl é uma linguagem muito abrangente e concordo com > >> vc que é praticamente impossível memorizar todos os operadores. Mas se > >> vc *usa*, vc é obrigado a saber. > >> > >> O ponto aliás nem é esse. Desconhecer, não implica em undefined > >> behavior. Implica em não obter o resultado que era esperado, logo a > >> falha está em não ser competente o suficiente para usar esta > >> ferramenta da linguagem. > >> > >> Já em C por exemplo, existem construções que *produzem* undefined > >> behavior, ou seja fica a cargo de quem implementou o compilador > >> resolver. Se ele quiser formatar seu disco ao atingir um ponto desses, > >> ele é livre pra isso. > >> > >> Por exemplo, o padrão C não define se variáveis automáticas (alocadas > >> na pilha) são ou não inicializadas automaticamente. Daí, num > >> compilador do Solaris (o Fernando pode confirmar), todas as variáveis > >> automáticas são inicializadas automaticamente (zero para inteiros). Já > >> no gcc não (mantém-se o valor que já estava na memória). Então, você > >> escreve um código no Solaris, compila, testa, homologa e ok. Aí você > >> leva esse código, que está dentro do padrão, para compilar no gcc e ao > >> rodar na nova plataforma ele quebra. > >> > >> Isso sim é um problema. O mesmo código, estritamente dentro do padrão, > >> apresentando comportamentos diferentes dependendo da situação. > >> > >> Oras, o programador experiente tem que conhecer bem a linguagem pra > >> não cair nessas armadilhas. Se não conhece, não deveria codificar > >> *profissionalmente*. > >> > >> É como se eu pegasse uma faca e saísse dizendo que sou cirurgião, só > >> porque sei cortar carne. E aí, posso fazer uma neurocirugia em você? > >> Eu tenho potencial pra ser um ótimo cirurgião :) > >> > >> As pessoas tem que ter mais responsabilidade. Hoje qualquer mané que > >> mal consegue encadear uma idéia, aprende um if e um for, copia e cola > >> Perl 3 do forum ultra hacker e sai falando que é Analista Programador. > >> É foda viu! > >> > >> De qualquer forma eu acho ótimo esse debate com pontos de vistas > >> diferentes. Ninguém é dono da verdade. > >> > >> Abraços > >> > >> 2011/2/14 Stanislaw Pusep <[email protected]>: > >> > Aliás, o que explode o meu cérebro é a frase "These rules look > >> > complicated, > >> > but usually they will do what you want.", a respeito do "given/when", > >> > também > >> > em L<perlsyn> ;) > >> > > >> > ABS() > >> > > >> > > >> > > >> > 2011/2/14 Stanislaw Pusep <[email protected]> > >> >> > >> >> Ehehe, vou tentar contextualizar a minha lembrança... Tomo como > exemplo > >> >> a > >> >> "tabela-verdade" do operador ~~ ("smart matching", L<perlsyn>): > >> >> > >> >> $a $b Type of Match Implied Matching Code > >> >> ====== ===== ===================== ============= > >> >> Any undef undefined !defined $a > >> >> > >> >> Any Object invokes ~~ overloading on $object, or > dies > >> >> > >> >> Hash CodeRef sub truth for each key[1] !grep { > >> >> !$b->($_) } > >> >> keys %$a > >> >> Array CodeRef sub truth for each elt[1] !grep { > >> >> !$b->($_) } > >> >> @$a > >> >> Any CodeRef scalar sub truth $b->($a) > >> >> > >> >> Hash Hash hash keys identical (every key is found > in > >> >> both hashes) > >> >> Array Hash hash slice existence grep { exists > >> >> $b->{$_} } @$a > >> >> Regex Hash hash key grep grep /$a/, keys > >> >> %$b > >> >> undef Hash always false (undef can't be a key) > >> >> Any Hash hash entry existence exists $b->{$a} > >> >> > >> >> Hash Array hash slice existence grep { exists > >> >> $a->{$_} } @$b > >> >> Array Array arrays are comparable[2] > >> >> Regex Array array grep grep /$a/, @$b > >> >> undef Array array contains undef grep !defined, > >> >> @$b > >> >> Any Array match against an array element[3] > >> >> grep $a ~~ $_, > >> >> @$b > >> >> > >> >> Hash Regex hash key grep grep /$b/, keys > >> >> %$a > >> >> Array Regex array grep grep /$b/, @$a > >> >> Any Regex pattern match $a =~ /$b/ > >> >> > >> >> Object Any invokes ~~ overloading on $object, or > >> >> falls > >> >> back: > >> >> Any Num numeric equality $a == $b > >> >> Num numish[4] numeric equality $a == $b > >> >> undef Any undefined !defined($b) > >> >> Any Any string equality $a eq $b > >> >> > >> >> 1 - empty hashes or arrays will match. > >> >> 2 - that is, each element smart-matches the element of same > >> >> index > >> >> in the > >> >> other array. [3] > >> >> 3 - If a circular reference is found, we fall back to > >> >> referential > >> >> equality. > >> >> 4 - either a real number, or a string that looks like a > number > >> >> > >> >> Olha, não sei quanto aos outros participantes da lista, mas eu > >> >> simplesmente não consigo me ater a todos esses detalhes > >> >> :( > >> >> Então nunca uso esse operador que me confunde (PARA MIM, é um > >> >> "Undefined > >> >> Behavior"), preferindo fazer "à moda antiga" (última coluna). Enfim, > >> >> sou > >> >> desses caras que enchem qqer operação de ()'s, tipo: ((($x / $y) - > $z) > >> >> > 0). > >> >> Enfim, o que quero dizer é que o Perl tem um imenso potencial de > >> >> produzir > >> >> código cheio de Pseudo-undefined Behavior; por que ninguém tem > >> >> obrigação de > >> >> saber todas as faces de todos os operadores; isso sem contar as > >> >> L<perlvar>. > >> >> > >> >> ABS() > >> >> > >> >> > >> >> > >> >> 2011/2/14 Blabos de Blebe <[email protected]> > >> >>> > >> >>> Oras, isso me lembra > >> >>> > >> >>> http://www.ioccc.org/1987/wall.c > >> >>> > >> >>> Uma coisa é você usar isso em um golf, outra é usar em código de > >> >>> produção. > >> >>> > >> >>> Tem gente que empeteca o código com meia dúzia de regexp e se ahca > 'O > >> >>> Hackerzão'. > >> >>> > >> >>> A maior parte dos bugs (com os quais estou lidando agora, por > >> >>> exemplo), teria sido evitada se fossem respeitados os padrões > mínimos > >> >>> de boas práticas. Coisa que qualquer estagiário *deveria* sair da > >> >>> escolinha sabendo. > >> >>> > >> >>> Abraços > >> >>> > >> >>> 2011/2/14 Stanislaw Pusep <[email protected]>: > >> >>> > Não sei pq, mas lembrei da seguinte sintaxe, compilável em Perl: > >> >>> > > >> >>> > -f>@+?*<.-&'_:$#/%! > >> >>> > > >> >>> > ABS() > >> >>> > > >> >>> > > >> >>> > > >> >>> > 2011/2/14 Blabos de Blebe <[email protected]> > >> >>> >> > >> >>> >> Bom dia, > >> >>> >> > >> >>> >> Sem querer entrar em flames, ou no mérito da discussão, que tomo > >> >>> >> apenas como exemplo. > >> >>> >> > >> >>> >> A thread abaixo é uma discussão que está acontecendo na principal > >> >>> >> lista de C++ brasileira, sobre undefined behavior. > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > >> >>> >> > http://groups.google.com/group/ccppbrasil/browse_thread/thread/9b9a7be45917095e# > >> >>> >> > >> >>> >> Notem como o Undefined behavior deste exemplo em particular pode > >> >>> >> ser > >> >>> >> resolvido com 'codificação elegante'. Ok, o assunto era outro e > foi > >> >>> >> só > >> >>> >> um exemplo rápido, mas levantou a discussão que está acontecendo > >> >>> >> até > >> >>> >> agora. > >> >>> >> > >> >>> >> A maioria dos 'Undefined Behaviors' das linguagens de programação > >> >>> >> que > >> >>> >> conheço (não são muitos) são casos específicos, incomuns, bem > >> >>> >> documentados, bem avisados, normalmente abertos por 'depender da > >> >>> >> implementação' e invocados por código porco de programadores > >> >>> >> meia-boca > >> >>> >> (não que este caso de *exemplo* seja um). > >> >>> >> > >> >>> >> É claro, nenhuma linguagem é perfeita (exceto lisp), mas elas > >> >>> >> possuem > >> >>> >> especificações, mais abrangentes ou menos abrangentes. Por isso, > >> >>> >> não > >> >>> >> importa a linguagem, ou você se aprofunda e aprende, ou mais cedo > >> >>> >> ou > >> >>> >> mais tarte, vai acabar caindo em alguma dessas asrmadilhas. > >> >>> >> > >> >>> >> Na minha opinião, C tem mais armadilhas e/ou hacks que precisam > de > >> >>> >> um > >> >>> >> pouco mais de conhecimento de arquitetura de computadores para > >> >>> >> escapar > >> >>> >> do que Perl, enquanto Perl tem outros tipos de armadilhas. > >> >>> >> > >> >>> >> Entenda armadilha aqui como "algo que eu imaginava de um jeito, > mas > >> >>> >> aconteceu de outro", independente da expectativa ser razoável ou > >> >>> >> não. > >> >>> >> > >> >>> >> O negócio é que como Perl é mais fácil de lidar do que C, você > >> >>> >> alcança > >> >>> >> as armadilhas de Perl mais cedo do que conseguiria caminhar em C > >> >>> >> para > >> >>> >> alcançar as suas, logo, Perl parece mais imprevisível. > >> >>> >> > >> >>> >> Abraços > >> >>> >> =begin disclaimer > >> >>> >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>> >> SaoPaulo-pm mailing list: [email protected] > >> >>> >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >> >>> >> =end disclaimer > >> >>> > > >> >>> > > >> >>> > =begin disclaimer > >> >>> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>> > SaoPaulo-pm mailing list: [email protected] > >> >>> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >> >>> > =end disclaimer > >> >>> > > >> >>> > > >> >>> =begin disclaimer > >> >>> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> >>> SaoPaulo-pm mailing list: [email protected] > >> >>> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >> >>> =end disclaimer > >> >> > >> > > >> > > >> > =begin disclaimer > >> > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> > SaoPaulo-pm mailing list: [email protected] > >> > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >> > =end disclaimer > >> > > >> > > >> =begin disclaimer > >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > >> SaoPaulo-pm mailing list: [email protected] > >> L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > >> =end disclaimer > > > > > > > > -- > > Tiago B. Peczenyj > > Linux User #405772 > > > > http://pacman.blog.br > > > > =begin disclaimer > > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > > SaoPaulo-pm mailing list: [email protected] > > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > > =end disclaimer > > > > > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
