GCC vai aceitar (com restrições) código em C++ na sua implementação
Agora é oficial: o compilador GCC está mudanod para uma implementação em C++. “Tenho o prazer de informar que o GCC Steering Committee e a FSF aprovaram o uso de C++ no GCC em si. Claro, não há razão para usar características do C++ só porque podemos. O objetivo é ter um melhor compilador para os usuários, não uma base de código em C++ para benefício próprio”. O próximo passo é definir um conjunto de padrões de codificação em C++ limitando as características da linguagem C++ que poderão ser usadas.
Mais: https://lwn.net/Articles/390016/ (via noticiaslinux.com.br)
• Publicado por Augusto Campos em
2010-06-02
@brlinuxblog
Feed RSS
Ehehe, será uma maravilha dar suporte/manutenção em código híbrido. Pois, quem acha que será respeitado um padrão de codificação?
FUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU :(
Run Forrest, Run!
Pressão de compiladores concorrentes? llvm/clang?
Não, Tenchi. É só a vergonha na cara voltando à face dos desenvolvedores do GCC :-D Tava na hora já…
Se é melhor para o projeto, tudo bem, mas espero que usem o C++ com moderação.
Espero que incluam algum tipo de destrutor de estruturas. Facilitaria muito a liberação de memória :)
Putz, eu não consigo ver isso com bons olhos. Para mim, se coisas de C++ são benéficas, pq não usar C++?
Não estou dizendo que X é melhor q Y ou que Y é pior que X. Só acho que se existe um compilador C++ e os recursos dele são desejáveis, pq não usar C++ então?
Pra c# é um pulo.
Bom, mas eles tem que tomar cuidado pra não abusar de orientação a objetos nesse caso. Embora eu goste de orientação a objetos, no nivel de um compilador pode ser prejudicial, o custo da chamada de uma função, caracteristica do encapsulamento, pode deixar o código mais lento. Além de outras caracteristicas de que ouvi falar, mas n sou especialista.
Não acho que irão incluir C# algum dia no GCC, ainda mais que o GCC não inclui um compilador C# (a não ser que tenham incluído um sem eu tomar conhecimento). Mas seria bom se criassem um “GCJ do C#” tal qual existe para o Java, permitindo compilação nativa de programas C#. Mas tem que verificar direitinho quais são as patentes atadas ao C# e ao .NET direitinho para implementar nesse “GCJ do C#” só o que não é coberto pelas patentes (e nem precisa implementar nada patenteado, já que não iria ser 100% compatível com o C# original mesmo, ainda mais que terá extensões GNU tal qual ocorre com o GCJ normal, que permite linkar código Java com código C++ de maneira não coberta pela especificação Java.
Onde eu disse “Não acho que irão incluir C# algum dia no GCC”, eu quis dizer “Não acho que irão incluir C# algum dia no CÓDIGO-FONTE do GCC”
@Allan,
Existe um projeto para um backend do gcc que produza o mesmo bytecode do C#. Isso permitiria extender o compilador de C++ para operar com managed c++.
A especificação do C# e da sua máquina virtual são cobertas pelos padrões ECMA 334 e 335. Ano passado a MS colocou ambos sob a comunity promisse, que é um acordo com valor legal que garante acesso a todas patentes dela necessárias para implementá-los. Ou seja, é mais seguro que as demais linguagens do GCC quanto a processos por patentes vindos da MS.
Quanto a usar C++ no GCC. Pode ajudar bastante a tornar o código mais fácil de modificar, mas tem o custo extra da gigantesca lentidão entre compilar C e C++.
Relembrando o velho ditado:
Programar em C é como brincar com facas…
Programar em C++ é como fazer malabarismo com serras elétricas!!!
Vale ressaltar que uma coisa é o compilador usar C++ outra é o programa.
Mesmo que o processo de compilação seja mais lento, se ele conseguir gerar um código de maquina mais eficiente, então tudo bem.
Prefiro perder 10s de compilação e ganhar 10% de desempenho.
O GCC é um excelente projeto, porém perde feio em desempenho para alguns compiladores por ai, como os da intell. Se o C++ vai reduzir a complexidade da manutenção do GCC o suficiente para que possa gerar códigos melhores, ok.
De fato, o que importa é a qualidade do código compilado.
@Danilo André: o que tem a ver o overhead do código OO usado para construir o compilador com o código gerado por ele????????
Censuraram o meu comentário sobre C#? E os outros 10 que vieram depois, não foram moderados? Olha a hipocrisia, pessoal.
Seu comentário não foi censurado, e sim moderado. E não foi por citar o C#, e sim por incitar um flame ou coisa do tipo (nem sei direito por que moderaram, e eu não fui um dos que moderaram).
OFF-TOPIC: E eu não achei justo a moderação. E já cliquei no “+” em seus dois comentários moderados. Mas é preciso que mais pessoas façam isso para que a moderação de seu código seja retirada. Acho sem noção boa parte das moderações realizadas por aqui. Ao meu ver, essa ferramenta de moderação está sendo bem útil nas mãos dos trolls presentes no BR-Linux… deprimente…
@Marcos: na verdade, a FSF apóia uma implementação em SL do padrão C#: o DotGNU. Pena que não tem muita gente codificando nele…
Cê-mais-mais ! Não existe alguma linguagem mais moderna e que esse pessoal pudesse usar no compilador e que resolva os problemas de lentidão para compilar desse C++? Ele herdou da C a lentidão e acrescentou sua própria carga (pesada).
Esse comentário vai ser moderado em 10 segundos. (9, 8, 7…)
20 anos depois o pessoal do Linux aprendeu C++.
@NaN
O problema é que o C++ tem alguns recursos que apesar de facilitarem o desenvolvimento tornam o resultado final uma porcaria de tão lento, um exemplo disso é template code, facilita sua vida, mas os resultados são ridículos.
O engraçado é que muitas vezes o código C++ é mais usado como fachada de programação e acesso, o que significa que fazem toda a bagaça em C/Assembly e deixam algumas fachadas em C++ que já carregam tudo de forma simplificada, de fato é negativo fazer um sistema totamente em C++ usando todos os recursos “modernos” de C++.
Sinceramente acho mais vantagem trabalhar com Vala que com C++.
Além do mais de fato código OO só funciona direito sendo código gerenciado, acho meio que perda de tempo fazer um código totalmente OO em nativo, neste caso é preferível combinar o melhor dos dois mundos e se abdicar dos template codes de C++ e alguns outros recursos gordos do mesmo.
@Allan Taborda dos Santos
Já existe uma linguagem nativa similar, chamada Vala, atualmente ela esta na mesma condição do g++ gerando código C a partir de uma linguagem de mais alto nível.
@teobaldo, ninguém “aprendeu” nada, isso ainda é um chamado. Eles estão solicitando que a comunidade discuta e defina os padrões do que será aproveitado dentro do GCC.
@tercio, acho que este projeto eclipsou o dotgnu, infelizmente.
Sugestão para o Augusto:
de fato, acho que alguns comentários nessa thread foram moderados injustamente. Eles acrescentam uma pitada de humor à discussão – o que é muito bom – mas isso não chega a ser flame.
eu não sei atualmente quantos votos negativos são necessários para moderar um comentário, mas sugiro que sejam experimentados valores mais elevados para esse limiar. (ou, como no slashdot, permitir que o leitor regule o seu próprio limiar – isso seria ótimo!)
Cê-mais-mais ! Não existe alguma linguagem mais moderna e que esse pessoal pudesse usar no compilador e que resolva os problemas de lentidão para compilar desse C++? Ele herdou da C a lentidão e acrescentou sua própria carga (pesada).
Hehehe, o pessoal da moderação não tá dando folga neste tópico, não é??
Sinto muito decepcioná-los, mas meu comentário anterior, apesar de provocativo, não era flame. Eu realmente queria saber de vocês quais linguagens compiladas alternativas que pudessem fazer frente ao C++. O @Heaven citou Vala, mas essa vai compilar o código para C, ou seja, piora a velocidade de compilação. Na verdade eu já tinha uma sugestão de linguagem alternativa, a D.
Quanto a dizer que C e C++ são lentos para compilar, querem que eu diga o quê, que minta??? Vcs têm que tomar conciência dos problemas, assim algum dia quem sabe tentam resolvê-los, ou fazem a coisa caminhar na direção da resolução, ou mesmo deixam como está (lento ao compilar não quer dizer lento ao executar), mas esconder problemas em baixo do tapete (da moderação) não resolve nada.
Só para citar uma coisa que deixa a compilação lenta, é no passo do pré-processamento dos includes. Cada arquivo normalmente inclui algumas dessas diretivas includes, os arquivos incluidos por sua vez incluirão outros e por aí vai. Assim compilar um arquivo, na prática, significa abrir e analisar, digamos, uma dezena de outros arquivos, se o projeto têm 50 arquivos, significará o acesso a uns 500 arquivos, repetidos na sua maioria. Não parece muito inteligente incluir diversas vezes o arquivo stdio.h/iostream para submeter ao compilador, não é?
- Ah! mas o include não faz parte da linguagem!
- Quer enganar quem? Essa estrátegia é usada por todos programadores C/C++. É como se o include fizesse parte da linguagem, pois os programadores em 99,999% dos casos a utilizam.
- Solução?
- Sei lá, que tal acrescentar na linguagem uma palavra como use/import para importar um módulo/biblioteca, certamente seria mais inteligente que incluir um arquivo completo e fazer a análise léxica e sintática centenas de vezes sem precisão.
- Mas esse import não vai funcionar como um include?
- O include não é inteligente, o import pode ser inteligente, embora eu não saiba como implementá-lo, mas é só olhar como Java, Ada, Modula, D, etc. fazem isso, aposto que elas fazem de modo mais inteligente que simplesmente incluir um arquivo texto dentro de outro e compilar.
@Heaven
Concordo com você.
@Tabela2
A linguagem D é de código gerenciado, acho que o ideal seria GO, entretanto seria uma mudança grande de paradigma.
O import em Java,Vala e C# diferente do include, ele faz uma chamada a algum código em tempo de execução, ao contrário do include que inclui um código em tempo de compilação, por essa razão apesar dessa diretiva ser usada por 99,999% dos programados de C/C++ a mesma faz parte apenas do compilar sem ter qualquer relação com a linguagem, já vi compiladores permitir formas diferentes de inclusão de diretivas, a realidade o pessoal só mantém assim para evitar um absurdo maior de confusão, entretanto o código geralmente ficar preso a um determinado compilador por causa de tais diretivas.
Seria uma boa se C++ usasse um import de tempo de execução, assim dariamos adeus a aqueles arquivos *.h.