Por que o C ++ possui 'comportamento indefinido' (UB) e outras linguagens como C # ou Java não?

Esta publicação do Stack Overflow lista uma lista bastante abrangente de situações em que a especificação da linguagem C / C ++ declara ser 'comportamento indefinido'. No entanto, quero entender por que outras linguagens modernas, como C # ou Java, não têm o conceito de 'comportamento indefinido'. Isso significa que o designer do compilador pode controlar todos os cenários possíveis (C # e Java) ou não (C e C ++)?

O comportamento indefinido é uma daquelas coisas que foram reconhecidas como uma péssima idéia apenas em retrospecto.

Os primeiros compiladores foram grandes conquistas e elogiaram com júbilo as melhorias em relação à alternativa - programação em linguagem de máquina ou linguagem de montagem. Os problemas com isso eram bem conhecidos e as linguagens de alto nível foram inventadas especificamente para resolver esses problemas conhecidos. (O entusiasmo na época era tão grande que as HLLs eram às vezes aclamadas como "o fim da programação" - como se de agora em diante tivéssemos que escrever apenas trivialmente o que queríamos e o compilador faria todo o trabalho real.)

Não foi até mais tarde que percebemos os problemas mais recentes que vieram com a abordagem mais recente. Estar distante da máquina real em que o código é executado significa que há mais possibilidade de as coisas silenciosamente não fazerem o que esperávamos que elas fizessem. Por exemplo, alocar uma variável normalmente deixaria o valor inicial indefinido; isso não foi considerado um problema, porque você não alocaria uma variável se não quisesse manter um valor nela, certo? Certamente não era demais esperar que programadores profissionais não esquecessem de atribuir o valor inicial, não é?

Aconteceu que, com as bases de código maiores e as estruturas mais complicadas que se tornaram possíveis com sistemas de programação mais poderosos, sim, muitos programadores de fato cometiam tais omissões de tempos em tempos, e o comportamento indefinido resultante se tornava um grande problema. Ainda hoje, a maioria dos vazamentos de segurança de pequeno a horrível é o resultado de um comportamento indefinido de uma forma ou de outra. (O motivo é que, geralmente, o comportamento indefinido é realmente muito definido pelas coisas do próximo nível inferior na computação, e os atacantes que entendem esse nível podem usar essa sala de manobra para fazer com que um programa não faça apenas coisas não intencionais, mas exatamente as coisas eles pretendem.)

Desde que reconhecemos isso, houve um esforço geral para banir o comportamento indefinido de linguagens de alto nível, e o Java foi particularmente completo sobre isso (o que foi relativamente fácil, pois ele foi projetado para rodar em sua própria máquina virtual especificamente projetada). Idiomas antigos como C não podem ser facilmente adaptados dessa maneira sem perder a compatibilidade com a enorme quantidade de código existente.

Edit: Como apontado, a eficiência é outro motivo. Comportamento indefinido significa que os escritores do compilador têm muita margem de manobra para explorar a arquitetura de destino, de modo que cada implementação consiga a implementação mais rápida possível de cada recurso. Isso foi mais importante nas máquinas com pouca potência de ontem do que com hoje, quando o salário do programador costuma ser o gargalo para o desenvolvimento de software.

Basicamente, porque os designers de Java e linguagens semelhantes não queriam um comportamento indefinido em sua linguagem. Isso foi uma troca - permitir que comportamentos indefinidos tenham o potencial de melhorar o desempenho, mas os projetistas de idiomas priorizaram mais a segurança e a previsibilidade.

Por exemplo, se você alocar uma matriz em C, os dados são indefinidos. Em Java, todos os bytes devem ser inicializados para 0 (ou algum outro valor especificado). Isso significa que o tempo de execução deve passar sobre a matriz (uma operação O (n)), enquanto C pode executar a alocação em um instante. Portanto, C sempre será mais rápido para essas operações.

Se o código que utiliza a matriz irá preenchê-lo de qualquer maneira antes de ler, isso é basicamente um esforço desperdiçado para Java. Mas no caso em que o código é lido primeiro, você obtém resultados previsíveis em Java, mas resultados imprevisíveis em C.

O comportamento indefinido permite uma otimização significativa, dando latitude ao compilador para fazer algo estranho ou inesperado (ou mesmo normal) em certos limites ou outras condições.

Consulte http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Uso de uma variável não inicializada: Isso é comumente conhecido como fonte de problemas em programas C e existem muitas ferramentas para capturá-las: de avisos do compilador a analisadores estáticos e dinâmicos. Isso melhora o desempenho ao não exigir que todas as variáveis ​​sejam zero inicializadas quando entram no escopo (como Java faz). Para a maioria das variáveis ​​escalares, isso causaria pouca sobrecarga, mas as matrizes de pilha e a memória malloc incorreriam em um conjunto intermediário de armazenamento, o que poderia ser bastante caro, principalmente porque o armazenamento geralmente é sobrescrito por completo.

Estouro de número inteiro assinado: se a aritmética em um tipo 'int' (por exemplo) estourar, o resultado será indefinido. Um exemplo é que "INT_MAX + 1" não é garantido como INT_MIN. Esse comportamento permite certas classes de otimizações importantes para algum código. Por exemplo, saber que INT_MAX + 1 está indefinido permite otimizar "X + 1> X" para "true". O conhecimento da multiplicação "não pode" exceder (porque isso seria indefinido) permite otimizar "X * 2/2" para "X". Embora isso possa parecer trivial, esse tipo de coisa geralmente é exposta por expansão interna e macro. Uma otimização mais importante que isso permite é "<=" loops como este:

for (i = 0; i <= N; ++i) { ... }

Nesse loop, o compilador pode assumir que o loop irá iterar exatamente N + 1 vezes se "i" for indefinido no estouro, o que permite uma ampla variedade de otimizações de loop. Por outro lado, se a variável estiver definida como encapsular em excesso, o compilador deve assumir que o loop é possivelmente infinito (o que acontece se N for INT_MAX) - que desabilita essas importantes otimizações de loop. Isso afeta particularmente as plataformas de 64 bits, pois muitos códigos usam "int" como variáveis ​​de indução.

Nos primeiros dias de C, havia muito caos. Compiladores diferentes trataram o idioma de maneira diferente. Quando houvesse interesse em escrever uma especificação para a linguagem, essa especificação precisaria ser razoavelmente compatível com o C em que os programadores estavam confiando com seus compiladores. Mas alguns desses detalhes não são portáteis e não fazem sentido em geral, por exemplo, assumindo uma disposição ou disposição de dados específica. O padrão C, portanto, reserva muitos detalhes como comportamento indefinido ou especificado pela implementação, o que deixa muita flexibilidade para os escritores do compilador. O C ++ se baseia no C e também apresenta um comportamento indefinido.

O Java tentou ser uma linguagem muito mais segura e muito mais simples que o C ++. Java define a semântica da linguagem em termos de uma máquina virtual completa. Isso deixa pouco espaço para comportamento indefinido, por outro lado, exige requisitos que podem ser difíceis para uma implementação Java (por exemplo, que as designações de referência devem ser atômicas ou como os números inteiros funcionam). Onde o Java suporta operações potencialmente inseguras, elas geralmente são verificadas pela máquina virtual em tempo de execução (por exemplo, algumas transmissões).

As linguagens JVM e .NET são fáceis:

1. Eles não precisam trabalhar diretamente com o hardware.
2. Eles só precisam trabalhar com sistemas modernos de desktop e servidor ou dispositivos razoavelmente semelhantes, ou pelo menos dispositivos projetados para eles.
3. Eles podem impor a coleta de lixo para toda a memória e a inicialização forçada, obtendo segurança de ponteiro.
4. Eles foram especificados por um único ator que também forneceu a implementação definitiva única.
5. Eles escolhem a segurança ao invés do desempenho.

Existem bons pontos para as escolhas:

1. A programação de sistemas é um jogo totalmente diferente, e a otimização intransigente da programação de aplicativos é razoável.
2. É certo que há menos hardware exótico o tempo todo, mas pequenos sistemas embarcados estão aqui para ficar.
3. O GC não é adequado para recursos não fungíveis e comercializa muito mais espaço para um bom desempenho. E a maioria (mas não quase todas) das inicializações forçadas pode ser otimizada.
4. Existem vantagens para mais concorrência, mas comitês significam comprometimento.
5. Todos desses limites verificações não se somam, embora a maioria pode ser otimizado de distância. As verificações de ponteiro nulo podem ser feitas bloqueando o acesso para zero sobrecarga, graças ao espaço de endereço virtual, embora a otimização ainda seja inibida.

Onde as hachuras de escape são fornecidas, elas convidam o comportamento indefinido completo a voltar. Mas pelo menos elas geralmente são usadas apenas em alguns trechos muito curtos, que são, portanto, mais fáceis de verificar manualmente.

Java e C # são caracterizados por um fornecedor dominante, pelo menos no início de seu desenvolvimento. (Sun e Microsoft, respectivamente). C e C ++ são diferentes; eles tiveram várias implementações concorrentes desde o início. C também rodou em plataformas de hardware exóticas. Como resultado, houve variação entre as implementações. Os comitês da ISO que padronizaram C e C ++ poderiam concordar com um grande denominador comum, mas nos limites em que as implementações diferem, os padrões deixam espaço para a implementação.

Isso ocorre também porque a escolha de um comportamento pode ser cara em arquiteturas de hardware tendenciosas em relação a outra opção - endianness é a escolha óbvia.

A verdadeira razão se resume a uma diferença fundamental na intenção entre C e C ++, por um lado, e Java e C # (por apenas alguns exemplos), por outro. Por razões históricas, grande parte da discussão aqui fala sobre C e não sobre C ++, mas (como você provavelmente já sabe) C ++ é um descendente bastante direto de C, então o que diz sobre C se aplica igualmente a C ++.

Embora eles sejam amplamente esquecidos (e sua existência às vezes até negada), as primeiras versões do UNIX foram escritas em linguagem assembly. Grande parte (se não apenas) do objetivo original de C era a porta UNIX da linguagem assembly para uma linguagem de nível superior. Parte da intenção era escrever o máximo possível do sistema operacional em um idioma de nível superior - ou examiná-lo de outra direção, para minimizar a quantidade que precisava ser escrita em linguagem assembly.

Para conseguir isso, C precisava fornecer quase o mesmo nível de acesso ao hardware que a linguagem assembly. O PDP-11 (por exemplo) mapeou os registros de E / S para endereços específicos. Por exemplo, você leu um local de memória para verificar se uma tecla foi pressionada no console do sistema. Um bit foi definido nesse local quando havia dados aguardando para serem lidos. Você leu um byte de outro local especificado para recuperar o código ASCII da tecla que foi pressionada.

Da mesma forma, se você quiser imprimir alguns dados, verifique outro local especificado e, quando o dispositivo de saída estiver pronto, escreva seus dados em outro local especificado.

Para oferecer suporte à gravação de drivers para esses dispositivos, C permitiu especificar um local arbitrário usando algum tipo de número inteiro, convertê-lo em um ponteiro e ler ou gravar esse local na memória.

Obviamente, isso tem um problema muito sério: nem todas as máquinas na Terra têm sua memória distribuída de forma idêntica a um PDP-11 do início dos anos 70. Portanto, quando você pega esse número inteiro, converte-o em um ponteiro e, em seguida, lê ou escreve através desse ponteiro, ninguém pode fornecer nenhuma garantia razoável sobre o que você obterá. Apenas para um exemplo óbvio, a leitura e a gravação podem mapear para separar os registros no hardware; portanto, você (ao contrário da memória normal) se escreve algo e tenta lê-lo novamente, o que lê pode não corresponder ao que escreveu.

Eu posso ver algumas possibilidades que restam:

1. Defina uma interface para todo o hardware possível - especifique os endereços absolutos de todos os locais que você pode querer ler ou gravar para interagir com o hardware de qualquer forma.
2. Proibir esse nível de acesso e decretar que quem quiser fazer essas coisas precisa usar a linguagem assembly.
3. Permita que as pessoas façam isso, mas deixe que leiam (por exemplo) os manuais do hardware que eles estão alvejando e escreva o código para se ajustar ao hardware que estão usando.

Destes, 1 parece suficientemente absurdo que dificilmente vale mais discussão. 2 é basicamente jogar fora a intenção básica da linguagem. Isso deixa a terceira opção como essencialmente a única que eles poderiam razoavelmente considerar.

Outro ponto que aparece com bastante frequência é o tamanho dos tipos inteiros. C assume a "posição" que intdeve ter o tamanho natural sugerido pela arquitetura. Portanto, se estou programando um VAX de int32 bits, provavelmente deve ter 32 bits, mas se estou programando um Univac de 36 bits, intprovavelmente deve ter 36 bits (e assim por diante). Provavelmente não é razoável (e talvez nem seja possível) gravar um sistema operacional para um computador de 36 bits usando apenas tipos que garantem múltiplos de 8 bits. Talvez eu esteja apenas sendo superficial, mas parece-me que se eu estivesse escrevendo um sistema operacional para uma máquina de 36 bits, provavelmente desejaria usar uma linguagem que suporte um tipo de 36 bits.

Do ponto de vista da linguagem, isso leva a um comportamento ainda mais indefinido. Se eu pegar o maior valor que caberá em 32 bits, o que acontecerá quando eu adicionar 1? No hardware típico de 32 bits, ele será rolado (ou possivelmente causará algum tipo de falha no hardware). Por outro lado, se estiver rodando em hardware de 36 bits, apenas adicionará um. Se o idioma oferecer suporte à escrita de sistemas operacionais, você não poderá garantir nenhum dos dois comportamentos - basta permitir que o tamanho dos tipos e o comportamento do estouro variem de um para outro.

Java e C # podem ignorar tudo isso. Eles não pretendem oferecer suporte a sistemas operacionais de gravação. Com eles, você tem algumas opções. Uma é fazer com que o hardware suporte o que eles exigem - já que eles exigem tipos de 8, 16, 32 e 64 bits, apenas construa um hardware que suporte esses tamanhos. A outra possibilidade óbvia é que o idioma seja executado apenas em cima de outro software que forneça o ambiente desejado, independentemente do hardware subjacente.

Na maioria dos casos, isso não é realmente uma opção de escolha. Em vez disso, muitas implementações fazem um pouco de ambos. Você normalmente executa o Java em uma JVM em execução no sistema operacional. Na maioria das vezes, o sistema operacional é escrito em C e a JVM em C ++. Se a JVM estiver sendo executada em uma CPU ARM, é bem provável que a CPU inclua as extensões Jazelle da ARM, para adaptar o hardware mais de perto às necessidades de Java, portanto, menos precisa ser feito em software e o código Java é executado mais rapidamente (ou menos de qualquer maneira).

Sumário

C e C ++ têm comportamento indefinido, porque ninguém definiu uma alternativa aceitável que lhes permita fazer o que pretendem fazer. C # e Java adotam uma abordagem diferente, mas essa abordagem se encaixa mal (se é que existe) com os objetivos de C e C ++. Em particular, nenhum deles parece fornecer uma maneira razoável de escrever software de sistema (como um sistema operacional) na maioria dos hardwares escolhidos arbitrariamente. Ambos geralmente dependem das instalações fornecidas pelo software do sistema existente (geralmente escrito em C ou C ++) para realizar seus trabalhos.

Os autores do Padrão C esperavam que seus leitores reconhecessem algo que consideravam óbvio e aludido na justificativa publicada, mas não disseram abertamente: o Comitê não deveria precisar solicitar que os redatores de compiladores atendessem às necessidades de seus clientes, já que os clientes devem conhecer melhor que o Comitê quais são suas necessidades. Se é óbvio que se espera que os compiladores para certos tipos de plataformas processem uma construção de uma certa maneira, ninguém deve se importar se o Padrão diz que essa construção invoca o Comportamento Indefinido. O fracasso da Norma em exigir que os compiladores em conformidade processem um pedaço de código útil de forma alguma implica que os programadores estejam dispostos a comprar compiladores que não o fazem.

Essa abordagem para o design de idiomas funciona muito bem em um mundo onde os escritores de compiladores precisam vender seus produtos a clientes pagantes. Ele se desfaz completamente em um mundo onde os escritores de compiladores são isolados dos efeitos do mercado. É duvidoso que existam condições adequadas de mercado para orientar um idioma da maneira como haviam dirigido o que se tornou popular na década de 1990, e ainda mais duvidoso que qualquer designer de linguagem sã desejasse confiar nessas condições de mercado.

C ++ e c têm padrões descritivos (as versões ISO, pelo menos).

Que existem apenas para explicar como os idiomas funcionam e para fornecer uma única referência sobre o que é o idioma. Normalmente, fornecedores de compiladores e escritores de bibliotecas lideram o caminho e algumas sugestões são incluídas no principal padrão ISO.

Java e C # (ou Visual C #, que suponho que você queira dizer) têm padrões prescritivos . Eles informam o que há no idioma definitivamente antes do tempo, como ele funciona e o que é considerado comportamento permitido.

Mais importante que isso, o Java realmente tem uma "implementação de referência" no Open-JDK. (Acho que Roslyn conta como a implementação de referência do Visual C #, mas não conseguiu encontrar uma fonte para isso.)

No caso de Java, se houver alguma ambiguidade no padrão, e o Open-JDK faz isso de uma certa maneira. A maneira como o Open-JDK faz isso é o padrão.

O comportamento indefinido permite ao compilador gerar código muito eficiente em uma variedade de arquiteturas. A resposta de Erik menciona otimização, mas vai além disso.

Por exemplo, transbordamentos assinados são um comportamento indefinido em C. Na prática, esperava-se que o compilador gerasse um código de operação simples de adição assinada para a CPU executar, e o comportamento seria o que essa CPU específica fizesse.

Isso permitiu que C tivesse um desempenho muito bom e produzisse um código muito compacto na maioria das arquiteturas. Se o padrão tivesse especificado que números inteiros assinados tinham que transbordar de uma certa maneira, as CPUs que se comportassem de maneira diferente precisariam de muito mais código gerado para uma simples adição assinada.

Essa é a razão para grande parte do comportamento indefinido em C e por que coisas como o tamanho de intvariam entre sistemas. Intdepende da arquitetura e geralmente é selecionado para ser o tipo de dados mais rápido e eficiente que é maior que a char.

Quando C era novo, essas considerações eram importantes. Os computadores eram menos potentes, geralmente com velocidade e memória limitadas de processamento. C foi usado onde o desempenho realmente importava, e os desenvolvedores deveriam entender como os computadores funcionavam bem o suficiente para saber quais seriam esses comportamentos indefinidos em seus sistemas específicos.

Linguagens posteriores, como Java e C #, preferiram eliminar o comportamento indefinido do que o desempenho bruto.

Em certo sentido, o Java também o possui. Suponha que você forneceu um comparador incorreto para Arrays.sort. Pode lançar exceção do que detecta. Caso contrário, ele classificará uma matriz de alguma maneira que não é garantida como particular.

Da mesma forma, se você modificar variáveis ​​de vários threads, os resultados também serão imprevisíveis.

O C ++ foi além para tornar mais indefinidas situações (ou melhor, o java decidiu definir mais operações) e ter um nome para ela.