Se sim, onde e por que você o usaria?
Se não, forneça uma explicação sobre por que C não é aceitável para você.
Se sim, onde e por que você o usaria?
Se não, forneça uma explicação sobre por que C não é aceitável para você.
Respostas:
Eu usaria C se implementasse alguns drivers de harware. E eu usaria C se implementasse meu próprio kernel do sistema operacional ou minha própria máquina virtual.
É uma linguagem muito boa para fazer coisas de baixo nível se você precisar lidar com hardware ou APIs de SO de baixo nível para API do Windows, Linux, Mac OS X, Solaris e assim por diante ... Os sistemas embarcados geralmente oferecem um bom suporte para C com um compilador + kit de desenvolvimento.
Sim, claro. Eu usaria C para escrever partes críticas do sistema ou partes de comunicação de baixo nível. Por exemplo, eu usaria C para escrever NIFs no projeto Erlang apenas porque é a ferramenta certa (tm) para esse tipo de trabalho. Ou eu usaria C para escrever partes semelhantes (XS) no projeto Perl.
Uso C profissionalmente, quase todos os dias. De fato, C é o idioma de nível mais alto no qual eu programa regularmente.
Onde uso C: escrevo código de biblioteca de baixo nível que exige ser o mais eficiente possível. Meu código de cola é escrito em C, os loops computacionais internos são escritos em assembly.
Por que eu uso C: É muito mais simples lidar com estruturas de argumentos complexas e condições de erro do que na montagem, e a sobrecarga de desempenho para esse tipo de verificação de condição antes de iniciar o cálculo real é geralmente insignificante. Como C é uma linguagem simples e bem especificada, é fácil trabalhar com a equipe do compilador trabalhando para melhorar a geração de código sempre que vejo código compilado com riscos inaceitáveis de desempenho.
A portabilidade é outra grande virtude do C. Meu código de cola é compartilhado em várias implementações específicas de hardware das bibliotecas nas quais trabalho, o que realmente simplifica a criação de suporte para novas plataformas. A maioria das plataformas não possui uma máquina virtual ou intérprete para o sabor do idioma do mês. Algumas plataformas não possuem um bom compilador C ++. Existem muito poucas plataformas que não possuem um compilador C utilizável (e, como eu tenho um bom relacionamento de trabalho com nossa equipe de compiladores, normalmente não tenho dificuldade em obter o suporte necessário).
Sim, eu usaria C em um sistema incorporado severamente restrito por recursos. Eu vez disso, posso usar o C ++ porque facilita a promoção de interfaces fortes entre os componentes de software, mas apenas se todos os engenheiros que trabalham no projeto entenderem que o C ++ é fácil de usar indevidamente, causando inchaço no tamanho do código (funções e modelos virtuais são exemplos de coisas a serem evitadas )
Também vi um programador em C ++ tentando criar um objeto de 10K em uma pilha de 1K, o que não é uma boa ideia.
virtual
funções são boas, pois seguem o princípio "você não paga pelo que não usa", mas, em ambiente com memória restrita, convém desativar as exceções e o RTTI.
Eu trabalho principalmente com o hipervisor Xen, as diversas bibliotecas que ele apresenta e o kernel do Linux. Na ocasião, tenho que escrever um driver de dispositivo (ou reescrever um driver para que as máquinas virtuais nxx possam compartilhar um único dispositivo, como um HRNG). C é minha língua principal e estou muito feliz com isso.
Eu tentaria escrever um programa de planilha usando-o? De jeito nenhum. Cada ferramenta tem suas aplicações e estou feliz por ter muitas ferramentas.
Eu amo C, mas não tento bater nos parafusos com um martelo.
Se C é uma escolha sensata para um novo projeto, com certeza. Caso contrário, usarei outra coisa.
Eu faria para alguns projetos. Definitivamente, se eu tivesse que implementar um sistema embarcado, digamos, para o controlador de uma aeronave autônoma. Pode até diminuir o nível em algumas peças com montagem.
Se ele se encaixa no projeto, não tenho nenhum problema.
Se você deseja desenvolver um aplicativo Web, hmm, provavelmente não (ou eu precisaria ver uma justificativa muito forte e apoiada em fatos).
Eu também o usaria de outros projetos desenvolvidos principalmente com outros idiomas quando um gargalo foi claramente identificado e uma otimização pode ser implementada usando código nativo. Por exemplo, uma solução Java que precisa realizar cálculos intensivos para algumas renderizações avançadas (por exemplo, um mecanismo de renderização ou algo assim). Você pode usar como padrão uma implementação Java se não for uma plataforma suportada, mas fornecer uma implementação compilada nativamente do C para algumas plataformas suportadas e obter um bom aumento de desempenho.
Cada idioma tem um nicho de uso decente. Frequentemente, eu me pego implementando coisas em linguagens de nível superior e, gradualmente, trazendo-as para o C-land, se eu precisar delas com desempenho superior ou simplesmente mais portáteis. Existem compiladores C para quase tudo o que existe e, se você escrever em uma API universalmente disponível (como POSIX), ela poderá ser muito útil.
O que digo frequentemente às pessoas que estão interessadas em aprender programação hoje é garantir que, em algum momento, aprendam C e se sintam confortáveis com ela. Você pode se encontrar em circunstâncias em que precisa. Em mais de uma ocasião, eu tive que compilar um pequeno programa de "reinicialização rápida" estaticamente vinculado e usar o scp para colocá-lo em um disco RAM em um servidor onde o subsistema de disco foi completamente desativado. (Servidores baratos e baratos, sem redundância online e apenas a capacidade de carregar um pequeno programa? C é o caminho a seguir.)
Além disso, aprender a trabalhar em C sem dar um tiro no pé pode contribuir significativamente para a capacidade de escrever com eficiência em outros idiomas e ambiente. Pelo menos essa tem sido a minha experiência.
Embora eu certamente não o use para tudo, ou mesmo para a maioria das coisas, ele tem o seu lugar e é praticamente universal: então sim, eu o usei no passado e o usarei no futuro (embora não o faça saber quando no momento).
Sim, eu faço isso o tempo todo.
Se você não chamar nenhuma biblioteca, o código gerado a partir de C não precisará de suporte do SO. Também oferece controle fino sobre a linguagem de máquina gerada. Portanto, é ótimo para escrever drivers ou outro código que mora nos espaços do kernel e outras situações restritas, como muitos tipos de sistemas incorporados funcionam. É também o idioma principal para projetos de código aberto com os quais trabalho, como X Windows, GTK + e Clutter.
Enquanto você pode fazer tudo em C em C ++, os mecanismos do C ++ tornam mais rápido e fácil a criação de código. Adoro OOP e a maneira como as classes C ++ encapsulam a funcionalidade e adoro RAII. O uso cuidadoso da invocação automática de destruidor quando um objeto fica fora do escopo elimina a maioria dos vazamentos de memória e recursos que são prejudiciais à programação em C. O STL é basicamente uma biblioteca gigante de algoritmos e estruturas de dados altamente otimizados; se você quiser usá-los em C, precisará escrevê-los ou comprá-los em algum lugar.
Infelizmente, por razões que não entendi, o sistema de tempo de execução no Linux requer uma biblioteca de objetos compartilhados especial (equivalente a DLL no Windows, dylib no Mac) para executar qualquer C ++, e não é encontrado quando você executa um programa em C. Portanto, não posso fazer um dos meus truques favoritos para Mac e Windows, que é escrever um objeto compartilhado baseado em C ++ com uma API baseada em C e chamá-lo em um programa em C.
Então, aqui está o meu processo de tomada de decisão:
Uma coisa boa é que, como o C ++ pode compilar C, se você realmente precisar de controle refinado sobre o código gerado para uma situação específica, basta escrever C para isso e C ++ para o restante e compilar tudo com o compilador C ++ .
se tem que ser ambos
então eu uso C. Talvez C ++.
Sim, de fato eu tenho recentemente!
Gosto de programar em C. Faço a maior parte da minha programação em python, mas há momentos em que preciso de código rápido e realmente aprecio a elegância que advém da simplicidade da linguagem.
O projeto no qual estou trabalhando agora é um banco de dados que, como você pode imaginar, é crítico para o desempenho. No momento, estou usando C e algum python, mas acabará sendo predominantemente, se não inteiramente C.
Sim. Passei a maior parte da minha carreira programando C ++, mas agora escrevo a maior parte do meu código em Ruby e, se precisar de desempenho ou acesso a coisas de baixo nível, escrevo uma extensão em C. É o futuro, cara!
Eu usaria C se estivesse escrevendo um sistema operacional. Como isso não vai acontecer nos próximos vinte anos, a menos que eu chegue à loteria e não tenha mais nada a fazer além de fazer minha própria incrível distribuição Linux, provavelmente vou me ater a C #, Java, Python, etc, etc. usei C há muito tempo, mas sempre gostei de usá-lo; Eu acho que, atualmente, minha cabeça está tão enrolada em torno de OO se eu tiver que voltar para isso, levaria um pouco para rolar novamente.
O C ++ é portátil em plataformas e dispositivos incorporados, como microcontroladores. (C ++ pode ser compilado em C, portanto, microcontroladores.)
C é até portátil (como funções estrangeiras) para outros idiomas. Portanto, se eu programar bibliotecas de baixo nível, desejo mais compatibilidade que C ++.
Haskell é portátil em várias plataformas (o ARM será lançado em breve), mas NÃO dispositivos incorporados, como microcontroladores. Sua velocidade é comparável a C e C ++; mas, por ser funcional, usa um coletor de lixo em vez de uma pilha de tempo de execução; portanto, pode ser mais rápido e mais lento que C em momentos diferentes (coleta de lixo) e em diferentes situações (continuações em vez de chamadas sub-rotineiras).
Eu escolhi a linguagem mais abstrata possível, porque a velocidade do programa não difere, mas o tempo de desenvolvimento e a taxa de erros. C e C ++ diferem muito, mas não do ponto de vista de Haskell.
Eu não prefiro outras línguas, mesmo sabendo que uma ou duas mãos estão cheias. ... exceto em alguns casos, bem, festança .
Os sistemas embarcados freqüentemente não têm mais do que alguns kilobytes de RAM e talvez algumas dúzias de kilobytes de flash, com uma taxa de clock do processador de alguns MHz. C é a única opção que faz sentido em um ambiente tão bare-metal.