dependendo das opções de otimização as variaveis podem não ser zeradas pelo compilador, no caso do gcc lembro vagamente de algo acontecendo em -O3 e -O4 e acho que o ricbit blogou sobre isso no passado.
mas "zerar" um array é responsabilidade do sistema operacional ou não tem nada haver? 2011/2/14 Stanislaw Pusep <[email protected]> > 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 > > -- 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
