¿Ha utilizado alguno de los intérpretes de C ++ (no compiladores)?

NOTA: lo que sigue es más bien específico de CINT, pero dado que es probablemente el intérprete más ampliamente utilizado C++, puede ser válido para el centro comercial.

Como estudiante de posgrado en física de partículas que ha usado CINT de forma extensiva, debería advertirle que se vaya. Si bien "funciona", está en proceso de ser eliminado , y los que pasan más de un año en física de partículas aprenden a evitarlo por varias razones:

1. Debido a sus raíces como interpretador de C, no logra interpretar algunos de los componentes más críticos de C++. Las plantillas, por ejemplo, no siempre funcionan, por lo que no se recomienda usar cosas que hacen que C++ sea tan flexible y utilizable.

2. Es más lento (por lo menos un factor de 5) que C++ mínimamente optimizado.

3. Los mensajes de depuración son mucho más crípticos que los producidos por g ++.

4. El alcance no es coherente con C++ compilado: es bastante común ver el código del formulario

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

   mientras que cualquier compilador de C++ en funcionamiento se quejaría de que correcton ha quedado fuera de alcance, CINT lo permite. El resultado es que el código CINT no es realmente C++, solo algo que se parece a eso.

En resumen, CINT no tiene ninguna de las ventajas de C++, y todas las desventajas más algunas.

El hecho de que CINT todavía se use en absoluto es probablemente un accidente histórico debido a su inclusión en el marco ROOT. Cuando se escribió (hace 20 años), existía la necesidad real de un lenguaje interpretado para el trazado/ajuste interactivo. Ahora hay muchos paquetes que cumplen ese rol, muchos de los cuales tienen cientos de desarrolladores activos.

Ninguno de estos está escrito en C++. ¿Por qué? En pocas palabras, C++ no debe interpretarse. La escritura estática, por ejemplo, le brinda grandes ganancias en optimización durante la compilación, pero principalmente sirve para saturar y sobre restringir su código si la computadora solo puede verlo en tiempo de ejecución. Si tiene el lujo de poder usar un lenguaje interpretado, aprenda Python o Ruby, el tiempo que le tomará aprender será menor que el que perdió en el CINT, incluso si ya conoce C++.

En mi experiencia, los investigadores más antiguos que trabajan con ROOT (el paquete que debe instalar para ejecutar CINT) terminan compilando las bibliotecas ROOT en ejecutables normales de C++ para evitar el CINT. Los de la generación más joven siguen este ejemplo o usan Python para las secuencias de comandos.

Por cierto, ROOT (y por lo tanto CINT) toma aproximadamente media hora para compilar en una computadora bastante moderna, y ocasionalmente fallará con las versiones más recientes de gcc. Es un paquete que cumplió un propósito importante hace muchos años, pero ahora muestra claramente su edad. Buscando en el código fuente, encontrará cientos de modelos desechados de estilo C, enormes agujeros en la seguridad de tipos y un uso intensivo de variables globales.

Si va a escribir C++, escriba C++ como debe escribirse. Si es absolutamente necesario tener un interpretador de C++, CINT es probablemente una buena apuesta.

Hay cling Proyecto del Cern del intérprete de C++ basado en clang - it nuevo enfoque basado en 20 años de experiencia en ROOT cint y es bastante estable y recomendado por los chicos del Cern.

Aquí está Nice Google Talk: Introducción a cling, un intérprete de C++ basado en clang/LLVM .

cint es el procesador de comandos para el paquete de análisis de física de partículas RAÍZ . Lo uso regularmente, y funciona muy bien para mí.

Es bastante completo y se lleva bien con el código compilado (puede cargar módulos compilados para su uso en el intérprete ...)

edición tardía :: Copiado de un duplicado posterior porque el cartel de las preguntas no parece querer publicar aquí: igcc =. Nunca lo intenté personalmente, pero la página web parece prometedora.

He jugado (hace aproximadamente un año) con Ch y me ha parecido bastante bueno.

Hace mucho tiempo, usé un intérprete de C++ llamado CodeCenter. Era bastante agradable, aunque no podía manejar cosas como campos de bits o destrozos de punteros elegantes. Las dos cosas interesantes de esto fueron que usted podía ver cuándo cambiaban las variables, y que podía evaluar el código C/C++ sobre la marcha mientras realiza la depuración. En estos días, creo que un depurador como GDB es básicamente tan bueno.

También hace mucho tiempo usé un producto llamado Instant C, pero no sé si alguna vez se desarrolló más.

Hay un programa llamado c-repl que funciona al compilar repetidamente su código en bibliotecas compartidas utilizando GCC, y luego cargar los objetos resultantes. Parece que está evolucionando rápidamente, considerando la versión en el repositorio de Ubuntu está escrito en Ruby (sin contar GCC, por supuesto), mientras que el último git está en Haskell. :)

Miré a usar ch hace un tiempo atrás para ver si podía usarlo para los DLL de prueba de caja negra de los que soy responsable. Desafortunadamente, no pude descubrir cómo cargar y ejecutar funciones desde DLL. Por otra parte, no estaba tan motivado y podría haber una manera.