Usou algum dos intérpretes c++ (não Compiladores)? [fechado]

Nota: o que se segue é bastante específico do CINT, mas dado que é provavelmente o interpretador de C++ mais usado pode ser válido para todos eles.

Como estudante de física de partículas que usou o CINT extensivamente, devo avisá-lo. Enquanto ele faz "trabalho", ele está em processo de eliminação gradual, e aqueles que passam mais de um ano em física de partículas normalmente aprendem a evitá-lo por algumas razões:

1. Devido à sua roots as A C interpretator, it fails to interprete some of the most critical components of C++. Modelos, por exemplo, nem sempre funcionam, então você será desencorajado de usar coisas que tornam C++ tão flexível e utilizável.

2. É mais lento (pelo menos por um fator de 5) do que o C++minimamente otimizado.

3. As mensagens de depuração são muito mais crípticas do que as produzidas pelo g++.

4. Escopo é inconsistente com C++ compilado: é bastante comum ver código do formulário

   if (energy > 30) { 
       float correction = 2.4;
   }
   else {
       float correction = 6.3;
   }
   
   somevalue += correction; 
   

   Enquanto qualquer compilador de C++ que funcione se queixaria que correcton tenha saído do escopo, o CINT permite isso. O resultado é que o código CINT não é realmente C++, apenas algo que se parece com ele.

Resumindo, o CINT não tem nenhuma das vantagens do C++, e todas as desvantagens mais algumas.

O facto de o CINT continuar a ser utilizado é provavelmente mais um acidente histórico devido à sua inclusão no quadro de base. Quando foi escrito (20 anos atrás), havia uma necessidade real de uma linguagem interpretada para plotting / ajuste interativo. Agora há muitos pacotes que preenchem esse papel, muitos que têm centenas de desenvolvedores ativos.

Nenhum destes está escrito em C++. Por quê? Muito simplesmente, C++ não é para ser interpretado. A digitação estática, por exemplo, Compra grandes ganhos em otimização durante a compilação, mas serve principalmente para confundir e sobrecarregar o seu código se o computador só é permitido vê-lo em tempo de execução. Se você tem o luxo de ser capaz de usar uma linguagem interpretada, aprender Python ou Ruby, o tempo que leva você a aprender será menor do que o que você perde tropeçando sobre CINT, mesmo que você já conhece C++.

Na minha experiência, os investigadores mais antigos que trabalham com o ROOT (o pacote que tem de instalar para executar o CINT) acabam por compilar as bibliotecas ROOT em executáveis c++ normais para evitar o CINT. Aqueles na geração mais jovem ou seguem esta liderança ou usam Python para scripting.

A propósito, ROOT (e, portanto, CINT) leva cerca de meia hora para compilar em um computador bastante moderno, e ocasionalmente falham com versões mais recentes do gcc. É um pacote que serviu um propósito importante há muitos anos, mas agora mostra claramente a sua idade. Olhando para o código fonte, você vai encontrar centenas de moldes de estilo C depreciados, enormes buracos na segurança do tipo, e uso pesado de variáveis globais.

Se vais escrever C++, escreve C++ como deve ser escrito. Se você absolutamente deve ter um interpretador de C++, CINT é provavelmente uma boa aposta.

Há agarram-se do Cern projeto do C++ intérprete com base em clang - é nova abordagem com base em 20 anos de experiência em RAIZ cint e é bastante estável e recomendado pelo Cern caras.

Aqui está nice Google Talk:introdução de cling, um interpretador de C++ baseado em clang / LLVM .

O Cint é o processador de comando para o pacote de análise física de partículas ROOT. Uso-o regularmente, e funciona muito bem para mim.

É bastante completo e se dá bem com o código compilado (você pode carregar módulos compilados para uso no interpretador...)

Edição tardia:: copiado de uma duplicata posterior porque o cartaz sobre as perguntas não parecia querer publicar aqui: igcc . Nunca tentei pessoalmente, mas a página web parece promissor.

Eu tenho (cerca de um ano atrás) brincado com {[[2]}Ch e achei que era muito bom.

Há muito tempo, usei um interpretador de C++ chamado CodeCenter. Foi muito bom, embora não conseguisse lidar com coisas como bitfields ou manjar ponteiros. As duas coisas legais sobre isso foram que você poderia assistir quando as variáveis mudaram, e que você poderia avaliar o código C/C++ na hora de depuração. Hoje em dia, acho que um depurador como o GDB é basicamente tão bom quanto isso.

Também há muito tempo usei um produto chamado instantâneo C, mas não sei se alguma vez se desenvolveu mais.

Eu olhei para usar ch um tempo atrás para ver se eu poderia usá-lo para testes de caixa preta DLLs por que eu sou responsável. Infelizmente, não consegui descobrir como fazê-lo carregar e executar funções a partir de DLLs. Por outro lado, eu não estava assim tão motivado e pode muito bem haver uma maneira.

Existe um programa chamado C-repl que funciona compilando repetidamente o seu código em bibliotecas partilhadas usando o GCC, Carregando depois os objectos resultantes. Parece estar evoluindo rapidamente, considerando a versão no repositório do Ubuntu é escrita em Ruby( sem contar com o GCC, é claro), enquanto o último git está em Haskell. :)