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

Question

Tengo curiosidad por saber si alguien ha usado UnderC, Cint, Cling, Ch o cualquier otro intérprete de C++ y podría compartir su experiencia.

Answer 1

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

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

editar tarde :: Copiado de un duplicado más tarde porque el cartel en que se las preguntas no parecían querer publicar aquí: igcc. Nunca lo intenté personalmente, pero la página web parece prometedora.

Answer 2

Hace mucho tiempo, utilicé un intérprete de C++ llamado CodeCenter. Era bastante agradable, aunque no podía manejar cosas como campos de bit o puntería de fantasía. Las dos cosas geniales fueron que se podía ver cuando cambiaban las variables, y que se podía evaluar el código C/C++ sobre la marcha mientras se depuraba. En estos días, creo que un depurador como GDB es básicamente igual de bueno.

Answer 3

también hace mucho tiempo que utiliza una llamada de producto C instantánea, pero no sé que se haya desarrollado más

Answer 4

tengo (hace un año) jugó con Ch y nos pareció que estaba bastante bien.

Answer 5

Miré hace un tiempo para ver si podía usarlo para las DLL de prueba de caja negra de las que soy responsable. Desafortunadamente, no pude entender cómo cargar y ejecutar funciones desde archivos DLL. Por otra parte, no estaba tan motivado y puede que haya una manera.

Answer 6

Hay un programa llamado c-repl que funciona compilando repetidamente su código en bibliotecas compartidas usando GCC, y luego cargando los objetos resultantes. Parece estar evolucionando rápidamente, teniendo en cuenta the version en el repositorio de Ubuntu está escrito en Ruby (sin contar GCC por supuesto), mientras que el latest git está en Haskell. :)

Answer 7

NOTA: lo que sigue es más bien CINT específico, pero dado que es probablemente el más widely used intérprete en C++, puede ser válido para todos.

Como estudiante de posgrado en física de partículas que ha utilizado CINT extensivamente, debo advertirte. Mientras lo hace el "trabajo", que is in the process of being phased out, y aquellos que pasan más de un año en la física de partículas suelen aprender a evitarlo por varias razones:

1. Debido a sus raíces como un intérprete 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 te animarás a usar cosas que hagan que C++ sea tan flexible y utilizable.

2. Es más lento (por lo menos en 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. de alcance es incompatible con C compilado ++: es bastante común ver código del formulario

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

   mientras que cualquier compilador C trabajando ++ se queja de que correcton ha ido fuera de su alcance, CINT lo permite. El resultado es que el código CINT no es realmente C++, simplemente 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 se siga utilizando en absoluto probablemente sea más 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 esa función, muchos de los cuales tienen cientos de desarrolladores activos.

Ninguno de estos están escritos en C++. ¿Por qué? Simplemente, C++ no está destinado a ser interpretado. La tipificación estática, por ejemplo, le permite obtener grandes ganancias en la optimización durante la compilación, pero sobre todo sirve para saturar y sobre restringir su código si la computadora solo puede verlo en tiempo de ejecución. Si puedes darte el lujo de poder utilizar un lenguaje interpretado, aprender Python o Ruby, el tiempo que tardes en aprender será menor que el que pierdas al tropezar con CINT, incluso si ya conoces 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 CINT. Aquellos en la generación más joven o siguen este ejemplo o usan Python para scripting.

Incidentalmente, ROOT (y por lo tanto CINT) tarda aproximadamente media hora en compilarse en una computadora bastante moderna, y ocasionalmente fallará con las versiones más nuevas de gcc. Es un paquete que cumplió un propósito importante hace muchos años, pero ahora muestra claramente su edad. Al examinar el código fuente, encontrará cientos de versiones obsoletas del estilo c, enormes agujeros en la seguridad del tipo y un uso intensivo de las variables globales.

Si va a escribir C++, escriba C++ como debe escribirse. Si absolutamente debe tener un intérprete de C++, CINT es probablemente una buena opción.

Answer 8

Hay proyecto cling del CERN de C++ intérprete basado en clang - es nuevo enfoque basado en 20 años de experiencia en cint RAÍZ y es bastante estable y recomendado por los chicos del CERN.

Aquí está el Google Talk: Introducing cling, a C++ Interpreter Based on clang/LLVM.