resueltos - ¿Has usado alguno de los intérpretes de C++(no compiladores)?

para que sirve c++

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

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 2

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 que la versión en el repositorio de Ubuntu está escrita en Ruby (sin contar GCC por supuesto), mientras que el último git está en Haskell. :)

Answer 3

Miré usando ch hace un tiempo para ver si podía usarlo para las DLL de pruebas 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 4

También hace mucho tiempo utilicé una llamada de producto Instant C, pero no sé si alguna vez se desarrolló más

Answer 5

Tengo (hace aproximadamente un año) jugué con Ch y descubrí que era bastante bueno.

Answer 6

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 (puede cargar módulos compilados para usar en el intérprete ...)

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

Answer 7

El proyecto de intérprete C ++ de Cern se basa en el clang , es un nuevo enfoque basado en 20 años de experiencia en ROOT cint y es bastante estable y recomendado por los chicos de Cern.

Aquí está el buen Google Talk: Introducing cling, un intérprete de C ++ basado en clang / LLVM .

Answer 8

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

Como estudiante de postgrado en física de partículas que ha usado CINT extensivamente, debo advertirte. Si bien "funciona", está en proceso de eliminación , y aquellos que pasan más de un año en física de partículas generalmente aprenden a evitarlo por varias razones:

1. Debido a sus raíces como intérprete C, no puede 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. El alcance es incompatible con C ++ compilado: es bastante común ver el código de la forma

   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 la correcton ha salido del 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 todavía se use CINT es probablemente 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á escrito 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) toma aproximadamente media hora para 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.