Por que os sistemas operacionais fazem coisas de baixo nível em C e C ++? Por que não apenas C ++?

Na página da Wikipedia para Windows , ele afirma que o Windows está escrito em Assembly para o carregador de inicialização e o alternador de tarefas, e C e C ++ para rotinas de kernel.

IIRC, você pode chamar funções C ++ a partir de um extern "C"bloco. Posso usar o C para as funções do kernel, para que aplicativos C puros possam usá-los (assim printfou não), mas se eles podem ser agrupados em um extern "C "bloco, então por que codificar em C?

É principalmente por razões históricas. Algumas partes do kernel do Windows foram originalmente escritas em C, porque em 1983, há mais de três décadas, quando o Windows 1.0 foi lançado, o C ++ mal foi lançado. Agora, essas bibliotecas C permanecerão lá "para sempre", porque a Microsoft tornou a compatibilidade com versões anteriores um ponto de venda e a reescrita de uma versão compatível com erros das peças C em C ++ exige muito esforço, sem benefício efetivo.

Como a maioria das pessoas apontou, as razões são de longe históricas, mas há algo mais que ninguém está mencionando e acredito que é a razão pela qual as pessoas ainda escrevem código C para baixo nível.

C é uma linguagem pequena no sentido de que a especificação é (relativamente) curta. C ++ é enorme e isso é um eufemismo. Isso pode não importar muito para o programador (embora eu ache que sim), mas é extremamente importante se você deseja fazer a verificação formal . Além disso, existem ferramentas estabelecidas para análise de código C, que podem ajudar a evitar bugs, etc.

E isso é muito importante no software incorporado, onde o custo de um bug implantado é extremamente alto em relação ao restante do setor (compare a Web, onde você pode aplicar um patch imediatamente a todos os usuários). Sem mencionar software de missão crítica e material médico.

Houve tentativas de deslocar C de seu lugar dominante na programação de baixo nível com linguagens ainda melhores nisso, como o BitC, mas elas não tiveram sucesso até agora.

1. O tempo de execução C é muito menor.
2. A tradução de C ++ em construções de nível inferior é menos transparente que em C. (Veja referências e vtables, para dois exemplos rápidos)
3. C geralmente tem um ITB estável. C ++ geralmente não. Isso significa que, no mínimo, a interface de chamada do sistema deve ser do estilo C. Além disso, se você quiser algum tipo de módulo dinâmico, ter uma ABI consistente ajuda muito.

Os motivos não são técnicos. Um pouco de montagem é inevitável, mas eles não são forçados a usar o C ocasional, eles querem . Minha empresa usa seu próprio kernel proprietário, escrito quase inteiramente em C ++, mas não precisamos suportar uma interface C para o kernel como quase todos os outros, porque nosso kernel incorporado é compilado monoliticamente com nossos aplicativos C ++. Quando você tem uma interface C, geralmente é mais fácil escrever o código da interface em C, mesmo que seja possível usá extern "C"-lo em C ++.

Até temos um número considerável de arquivos C, principalmente devido ao código de terceiros. O código de baixo nível de terceiros é quase sempre fornecido em C, porque é muito mais fácil incorporar o código C em um aplicativo C ++ do que o contrário.

Os desenvolvedores de kernel geralmente são o tipo de pessoa que se sente mais feliz, quando é imediatamente evidente a partir da fonte, o que o código realmente faz.

O C ++ possui muito mais recursos, que escondem o que o código faz mais do que o simples código C o oculta: sobrecargas, métodos virtuais, modelos, referências, lançamentos ... O C ++ também possui muito mais sintaxe que você precisa dominar para entender o C ++ código usando-o.

Eu acho que o poder do C ++ é uma ferramenta muito poderosa para criar bibliotecas e estruturas, o que torna o desenvolvimento de aplicativos fácil. Muitas vezes, o desenvolvedor de aplicativos C ++ ficava totalmente perdido nas entranhas cheias de modelos de uma biblioteca, mesmo quando ele é muito competente na criação de aplicativos usando essa biblioteca. E escrever corretamente uma biblioteca C ++ é uma tarefa de programação muito desafiadora e realizada apenas para fornecer uma ótima estrutura para o benefício do desenvolvedor de aplicativos. As bibliotecas C ++ não são internamente simples, são (ou podem ser ...) apenas poderosas, mas simples do ponto de vista dos programadores de aplicativos.

Porém, a API do kernel não pode ser uma API C ++, deve ser uma API independente da linguagem; portanto, a maioria das coisas boas do C ++ não seria diretamente utilizável nessa interface. Além disso, o kernel não é realmente dividido em partes de "biblioteca" e "aplicativo" desenvolvidas de forma independente, com mais esforço logicamente em uma biblioteca, para facilitar a criação de uma massa de aplicativos.

Além disso, a segurança e a estabilidade são mais críticas dentro de um kernel, e os métodos virtuais são muito mais dinâmicos e, portanto, muito mais difíceis de isolar e verificar do que os retornos de chamada simples ou outros mecanismos do tipo C.

Resumindo, embora você possa, naturalmente, escrever qualquer programa em C, incluindo um kernel como C ++, a maior parte do poder do C ++ não é bem usado no kernel. E muitos argumentam que as ferramentas de programação devem impedir que você faça coisas que não deve fazer. C ++ não faria.

Bjarne Stroustrup, em entrevista em julho de 1999 :

Nenhuma dessas línguas era radicalmente diferente ou dramaticamente melhor que outras línguas contemporâneas. Eles eram, no entanto, bons o suficiente e os beneficiários de sorte e fatores sociais

C é uma linguagem de nível muito baixo, por seu design. Está a um passo do montador; conhecendo o chipset que você está alvejando, você poderia, com um pouco de conhecimento, "compilar" manualmente o C no ASM. Esse tipo de linguagem "próxima ao metal" é essencial para altos níveis de otimização (desempenho, eficiência de memória etc.). No entanto, por ser tão próximo do metal, você não ganha muito de graça com esse idioma; é uma linguagem processual, não orientada a objetos, e, portanto, trabalhar com essas construções envolve muito código padrão para criar e consumir construções com vários valores na memória.

C ++ é "C one better", adicionando uma série de recursos fáceis de usar, como alocação dinâmica de memória, organização interna da estrutura, uma grande biblioteca de códigos predefinidos, etc., à custa de algumas perdas de eficiência (ainda muito melhores ambientes de tempo de execução gerenciado). Para o codificador médio, as vantagens superam as desvantagens em áreas da base de código que não precisam de controle retentivo anal da alocação de memória, etc.

A combinação dos dois é bem tradicional; você usa C para escrever as áreas mais críticas em termos de desempenho e com eficiência de memória da base de código, com as quais você pode trabalhar de uma maneira mais abstrata por meio de chamadas de método do código C ++, que podem ser mais elegantemente organizadas e projetadas do que o desempenho superior , código C super otimizado.

Pode ser que, com C, você gaste a maior parte do tempo pensando no problema em questão e em como codificar a solução. Em C ++, você acaba pensando em C ++ e sua infinidade de recursos, funções e sintaxe obscura.

Também em muitas lojas C ++, seu código é monitorado pela "polícia da moda", fascinada pelo último conjunto de padrões de design ou pelos últimos pronunciamentos ininteligíveis do grande deus Stroustrup. O código bonito se torna mais valorizado do que o código em funcionamento, admirar o uso do conjunto mais recente de modelos Boost é mais do que encontrar uma solução funcional para os negócios.

Minha experiência é que, para todos os recursos inteligentes e a pureza OO do C ++, a codificação em C simples faz o trabalho com mais rapidez e eficácia.

É possível que as partes C não sejam portáveis ​​para o compilador C ++ usado para as partes C ++. Talvez o código C seja amigável com o compilador C de maneiras que rompem com o compilador C ++.

Se você possui um compilador C ++ de qualidade, quase não há razão para misturar C e C ++ em um projeto. Quase.

A única razão seria que o seu projeto compartilha o código C com outros projetos, o código não é compilado como C ++ e você não deseja manter uma bifurcação em C ++ desse código.

Eu acho que você tem o contrário - o extern "C"bloco garante que as convenções de chamada C sejam usadas para todas as funções dentro do bloco. Portanto, você pode chamar funções C puras do C ++, e não as funções C ++ do C. Independentemente, imagino que a razão pela qual as pessoas usem C e C ++ seja porque muitas bibliotecas de baixo nível são escritas usando C, e é mais fácil usar algo que já existe (e é presumivelmente depurado e otimizado) do que escrever o seu próprio. OTOH, C ++ oferece muitos recursos agradáveis ​​de alto nível com os quais as pessoas preferem trabalhar, então usam isso para o resto.

Existem vários níveis de plataformas incorporadas usando C como linguagem de programação (é claro que é sua liberdade usar a linguagem assembly a qualquer momento)

Para 'Level', estou falando do nível de recurso SRAM e ROM interno de um sistema.

Essas plataformas às vezes têm recursos limitados (por exemplo, algumas plataformas 8051 possuem apenas 128 bytes de SRAM do usuário).

Não faz sentido oferecer suporte à alocação dinâmica de memória com uma quantidade tão pequena de RAM. (novo / excluir) ou até malloc em C.

Uma das principais melhorias de C para C ++ é o paradigma orientado a objetos. C ++ é adequado em software com maior espaço de memória

mas não no firmware incorporado com limitação de tamanho de até 32 KB. (por exemplo, em uma placa MCU de 16 bits)

Não há necessidade de ter um compilador C ++ que geralmente é mais complicado que o compilador C. (pelo menos os provedores de SDK não se incomodam em fazer isso).

Na verdade, mal consigo encontrar um compilador C ++ em uma plataforma ARM7 de 32 bits.

Simplesmente não vale a complexidade

Em alguns 8051 (8 bits): 1MB ROM, 128B RAM

TI MSP430 (16 bits): ROM de 32 KB, RAM de 4KB

Núcleo da CPU ST Microelectronics ARM Cortex ™ -M3 de 32 bits (STM32F103T4): 16 ou 32 Kbytes de memória Flash 6 ou 10 Kbytes de SRAM

Vejo algumas razões possíveis:

• C é um pouco mais eficiente se comparado ao equivalente em C ++.
• Algumas bibliotecas usadas são escritas em C.
• Eles usam algumas partes do kernel do Linux, escritas em C.

Editado: Como se vê, o terceiro argumento não é verdadeiro (ver comentários).

Porque C é sem dúvida uma linguagem melhor que C ++. E porque parte do código foi escrito antes do C ++ se tornar popular e as pessoas não tiveram um motivo para substituí-lo.

E como o C ++ possui muitos recursos que podem quebrar seu código, se você não tomar cuidado ao usá-lo em um kernel.