Quando a avaliação de curto-circuito é ruim?

Para ser um pouco mais claro, afirmo que passei muito tempo com idiomas diferentes. Mas até agora, tem sido, ou será usado o tempo todo ou não será compatível.

Agora, o trabalho me iniciou em projetos que exigem o VB.net, e vejo que ele fornece as duas maneiras em termos de AND e ANDALSO . O primeiro não provoca um curto-circuito e o segundo não.

Então isso me leva a pensar por quê? Como configurá-lo assim parece implicar que surgiria com bastante frequência que alguém desejaria mudar de modo. Mas não consigo pensar em nenhuma situação em que seria ruim usar o Short Circuit .

Eu sei que isso poderia muito bem se tornar mais uma opção, então se eu precisar colocar isso em algum outro lugar, diga-me onde.

Embora eu esteja esperando que haja pelo menos uma resposta oficial, por que ter as duas opções seria melhor do que sempre fazer um curto-circuito , quando disponível.

Alguns termos em uma expressão lógica podem ter efeitos colaterais. Às vezes, é necessário garantir que todos os efeitos colaterais ocorram na ordem estabelecida e que nenhum seja ignorado, e é o resultado da avaliação que guia a lógica:

if not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

Em outros casos, você não deseja avaliar nenhum dos termos restantes se uma avaliação anterior retornar falsa.

if IsAirborne() and not (PushAirPlane(thrust) and TurnAirplane(vector)), SimulateCrash(severity)

Alguns argumentaram que confiar no comportamento de curto-circuito no segundo exemplo é uma forma ruim, mas isso está entrando no estilo de codificação e nos sistemas de crenças. Existem muitos bits muito bons de código no mundo que dependem de quase todos os recursos que uma linguagem fornece, e é exatamente assim.

O ANDALSO da VB é preciso e parece ser uma tentativa de tornar a prática mais aceitável.

Como JimmyJames aponta em sua resposta, pode haver implicações mensuráveis ​​de desempenho em torno da avaliação de curto-circuito. Os idiomas que não fornecem o mecanismo, sempre avaliam todos os termos da expressão, enquanto os que o fornecem, podem gerar instruções de ramificação extras. De qualquer forma, depende muito do número de etapas de processamento necessárias para avaliar cada um dos termos e também das arquiteturas do compilador e da CPU. Normalmente, você não se importaria com essas coisas até ter um gargalo medido no código e precisar descobrir como aliviá-lo. Qualquer regra de "faça ou não" em relação à permissão de avaliação de curto-circuito em seu código teria uma chance praticamente igual de causar código mais lento e otimizar antecipadamente pode ser uma perda total de tempo; portanto, sempre meça e otimize.

Aparentemente, sua pergunta não é sobre o curto-circuito ser bom ou ruim em geral, mas sobre por que o VB.NET fornece aos operadores com e sem isso. Com isso em mente, a resposta para

quando é ruim a avaliação de curto-circuito?

é simplesmente: quando viola a compatibilidade com versões anteriores .

Ok, agora você pode dizer que o VB.NET não é muito compatível com o VB6 ou VBA antigo, no entanto, pelo menos algumas partes do idioma são. A decisão da Microsoft de manter a antiga semântica AND e OR (sem curto-circuito) reduziu a probabilidade de ocorrer uma categoria enorme de erros ao transportar programas VB antigos para o VB.NET.

Por outro lado, os designers de linguagem do VB.NET provavelmente compartilharam sua opinião sobre o curto-circuito ser uma coisa boa. Quando me lembro corretamente, as primeiras versões de pré-lançamento do VB.NET forneceram aos operadores AND ou OR um curto-circuito, mas o feedback do desenvolvedor deve ter sido tão ruim que a Microsoft retirou essa decisão antes que o VB.NET 1.0 aparecesse. Assim, os designers decidiram implementá-lo em termos de novas palavras ANDALSO- chave e ORELSEcomo uma troca entre compatibilidade e utilidade anteriores.

IMHO esta foi uma boa decisão. Eu tive que portar vários programas mais antigos na última década, e não ter que fazer uma análise de impacto pesado para todas as expressões lógicas, incluindo AND e / ou OR (trocadilhos), tornaram essa tarefa muito mais fácil e econômica. Por outro lado, sempre que tenho que escrever uma nova expressão lógica no VB.NET, minha opção padrão para os operadores são as formas de curto-circuito, é com isso que estou acostumado a partir de C, C ++, C # etc., e isso permite para escrever vários idiomas de forma mais concisa (mesmo que o ANDALSO precise de mais 4 caracteres para digitar).

Se você não está convencido, recomendo ler o excelente artigo de Joel Spolsky sobre os fones de ouvido marcianos , que explica por que as decisões iniciais de design no desenvolvimento de software não podem ser facilmente revogadas depois que o componente, idioma ou API em jogo alcançou uma base de usuários de um determinado tamanho .

quando é que a avaliação de curto-circuito é ruim?

Eles ficam ruins , assim que você começa a contar com os efeitos colaterais das expressões que espera executar na avaliação de um resultado geral booleano.

Advertência : Isso é um pouco esotérico, pois em quase todos os casos, os desenvolvedores não devem se preocupar com isso. Mas ... pode haver um impacto no desempenho devido à avaliação condicional, pois cria ramificação na execução. Uma operação sem curto-circuito não se ramifica e é mais previsível.

A razão pela qual isso raramente importa é que o custo geralmente é pequeno e também geralmente supera o custo da avaliação da segunda (ou terceira) condição. Isso só será importante em rotinas computacionalmente caras quando for necessário alto desempenho e ainda não será importante.

Pascal não definiu se AND e OR usam ou não a avaliação de curto-circuito, oferecendo o pior dos dois mundos.

C e C ++ têm operações bit a bit & e | que na prática oferecem operações sem curto-circuito. E os compiladores são livres para avaliar como quiserem, se isso não fizer uma diferença observável.