2010-07-06 10 views
12

Por el momento estoy considerando si reescribir un intérprete de lenguaje de programación que mantengo en C++. El intérprete se implementa actualmente en C.¿La implementación primaria de * cualquier * intérprete popular de lenguaje de programación está escrita en C++?

pero me preguntaba, es el principal — aplicación porque, versiones sin duda, la gente ha hecho de muchos intérpretes que utilizan un idioma que no sea el utilizado por los autores originales de cualquier — popular intérprete de lenguaje de programación actualmente en uso hoy escrito en C++?

Y, si no, ¿hay una buena razón para no escribir un intérprete en C++? Tengo entendido que el código C++, si está escrito correctamente, puede ser muy portátil y potencialmente puede compilarse para ejecutarse tan rápido como el código C compilado que hace lo mismo.

+7

Sus carreras intérprete? ¿Es estable? Utilizado por la gente? ¿Por qué reescribirlo todo? –

+8

Si ya tiene una implementación C, esa es una excelente razón para no volver a escribirla en C++. – jalf

+1

Sin duda, mi intérprete se ejecuta, pero hay una serie de problemas, en particular, manejo de símbolos torpes y numerosas pérdidas de memoria. Estos defectos son tales que creo que la mejor manera de abordarlos es volver a escribir el intérprete desde cero. Dado que los dos únicos contendientes reales para el lenguaje de reescritura son C y C++, me pregunto si C++ sería el mejor lenguaje para implementar el intérprete, teniendo en cuenta que proporciona (lo que parece ser) facilidades más intuitivas para la gestión de memoria y la cadena tratamiento. –

Respuesta

8

Escribí un intérprete en C++ (después de muchos en C a lo largo de los años) y creo que C++ es un lenguaje decente para eso. Acerca de la implementación solo retrocedería en el tiempo y cambiaría mi opción de implementar la posibilidad de tener varios intérpretes diferentes ejecutándose al mismo tiempo (cada uno multiproceso) simplemente porque hacía el código más complejo y nunca se usó. Multihilo es bastante útil, pero varias instancias del intérprete no tenía sentido ...

Sin embargo, ahora mi gran pesar es de hecho el mismo hecho escribí que el intérprete porque ahora se utiliza en la producción con bastante cantidad de código escrito y personas capacitadas para ello, y porque el lenguaje es bastante más feo y menos poderoso que el pitón ... pero cambiar a python ahora agregaría costos. No tiene ningún error conocido ... pero es peor que Python y es un error (además del error ya hecho por pagar el costo de escribirlo sin ningún motivo).

simplemente debería haber utilizado inicialmente pitón en lugar (o lua o cualquier otro intérprete ya hecha que puede ser fácilmente integrado y que tiene una concesión de licencias razonable) ... mi única excusa para esto es que yo no sabía nada de pitón o lua en ese momento.

Mientras que escribir un intérprete es algo divertido de hacer como ejercicio de programación, le sugiero que evite escribir el suyo para la producción, especialmente (no lo tome personalmente) si el cuidado que requiere la complejidad de bajo nivel es fuera de su alcance (me parece por ejemplo la presencia de varias fugas de memoria bastante impactantes).

C++ sigue siendo un lenguaje de bajo nivel y al mismo tiempo se puede conseguir un poco de ayuda, por ejemplo, en el lado de manejo de la memoria sigue siendo el hipótesis principal del lenguaje es que su código es 100% correcta como ningún error de ejecución va a ayudar usted (solo daemons de comportamiento indefinido).

Si te perdiste esta suposición del código 100% correcto para C (un lenguaje mucho más simple) entonces no veo cómo puedes estar seguro de que escribirás el código correcto en C++ (un monstruo de complejidad en comparación). Sospecho que terminarás con otro intérprete de errores que tendrás que tirar.

+3

No estoy de acuerdo con escribir error en C++. C++ es tipo seguro (no 'void *' alrededor) y permite modismos como RAII para administrar recursos. Estas 2 características hacen que sea MUCHO más fácil escribir código sin errores en mi opinión. A decir verdad, creo que las características más propensas a errores en realidad provienen de C ... –

+1

Lo siento, pero creo que estás completamente equivocado en esto. El mayor problema de C++ es la complejidad y eso no proviene de C. También un problema grave es que ** puede parecer ** como un lenguaje de alto nivel, mientras que de hecho no lo es, y si no comprende el implicación, entonces vas a sufrir mucho con C++. Es muy fácil escribir código C++ que se ve bien y que en su lugar es solo una bomba de tiempo ... por ejemplo 'v.push_back (v.back());' para agregar a un vector no vacío una copia de el último elemento En C++ existen muchas de esas trampas. Y por supuesto que no es culpa de K & R. – 6502

+0

Bueno, no escribí el intérprete originalmente; Lo "adopté" de otra persona, por lo que muchas de las pérdidas de memoria y otros problemas ya estaban presentes. Logré eliminar algunas, pero en general toda la implementación sigue siendo un gran desastre, no porque el autor original haya sido un mal programador, sino porque el intérprete representa más de diez años de evolución. –

2

Los lenguajes de programación más populares comenzaron a crearse antes de que hubiera muchos buenos compiladores de C++ disponibles. Por lo tanto, los intérpretes primarios de esos idiomas no comenzaron en C++, y una vez que ha puesto mucho trabajo en un intérprete funcional, generalmente no descarta eso solo porque ahora también podría escribirse en C++.

Y si inicia un nuevo proyecto para un intérprete escrito en C++ tiene que recorrer un largo camino para convertirse en la implementación primaria.

+0

Usar LLVM podría ayudar (y eso es C++). – Klaim

+0

@Klaim: Sí, por ejemplo, clang es un compilador serio para C/C++/Objective-C, basado en LLVM y escrito en C++, pero no se puede afirmar que sea el compilador * primario * para esos idiomas ... – sth

+0

Difícilmente podemos afirmar que el compilador * any * para esos idiomas es "primario". – slacker

1

La fundación GNU acaba de anunciar que todas las nuevas versiones de gcc se escribirán en C++.

+0

SRSLY? Eso es interesante. – msandiford

+1

@spongL http://allanmcrae.com/2010/06/gcc-in-cxx/ La adopción/conversión será lenta y no se realizará en "C++ for C++ sake", pero eventualmente sucederá. –

+4

Creo que es el hilo que anunció que han decidido * permitir * C++ en el código GCC, que no * * significa que va a ser reescrito. Eso sería una locura, OMI. – unwind

5

Si escribió la implementación actual y -Como usted dice en su comentario- que tiene:

torpe símbolo de la manipulación y numerosas pérdidas de memoria

A continuación, volver a escribir en C++ no va para ayudarte. Primero, intente comprender por qué la implementación actual falla. Por otro lado, si no eres el desarrollador original, simplemente elige el idioma que conozcas mejor y el puerto.

Actualización: Creo sth's comment explica adecuadamente por qué muchos idiomas se implementan en C en lugar de C++. Sobre el tema de las reescrituras completas, heed the words of Joel Spolsky.

+0

Esa es la cuestión: yo no soy el desarrollador original. El intérprete, tal como está, representa entre 10 y 15 años de evolución, por lo que su código es tan desordenado en algunos lugares. Estoy bastante convencido de que la única manera práctica de abordar todos sus defectos es volver a escribir desde cero en C o C++; pero me pregunto por qué hay, o al menos parece que no, intérpretes populares escritos en C++. Pero luego, por supuesto, siempre hay una primera vez. ;-) –

+0

No pensé que hubieras escrito el original. Actualicé mi respuesta un poco. –

1

Tamarin - El intérprete ECMAScript de Adobe y Mozilla está escrito en C++. Al ser el autor original del lenguaje original, puede considerarse como el principal (IIRC, la implementación de referencia ECMA está escrita en OCaml, pero no se usa realmente excepto como referencia)

2

Google Chrome V8 Javascript Motor Implementa ECMA-262 y es extremadamente rápido. Tal vez podrías reescribirlo en C++ pero deberías pensar en otras características como implementar una especificación de bytecode en lugar de reescribir tus autómatas en C++. Reescribirlo solo ayudará a organizar el código (lo cual es una gran cosa para el trabajo en grupo), pero nada en el rendimiento.

4

Sí, muchos son. IIRC el Hotspot Java VM está escrito en C++, Haskells ghc, ...

Como muchos aquí han notado Deberías echarle un vistazo a LLVM, es un conjunto de herramientas para compilar compiladores, intérpretes y máquinas virtuales. Básicamente haces el trabajo frontend (es decir, analizando tu lenguaje + análisis semántico + codegen en LLVM IR) y LLVM te dará inmediatamente la construcción para diferentes plataformas, jit, optimización, compilación en código nativo, ... También tiene algunas herramientas para el análisis sintáctico y AST, y el manejo y notificación de errores (pero tal vez eso es parte del subproyecto Clang).

+1

ghc está escrito en haskell – hiena

+1

Nota: Todo esto es conocimiento de segunda mano. AFAIK solo una parte, o la implementación de referencia está escrita en Haskell, para generar programas optimizados necesita un backend gcc o LLVM, que luego se escribe en C o C++ respectivamente. Vea aquí: [Fast Haskell usa LLVM] (http://donsbot.wordpress.com/2010/02/21/smoking-fast-haskell-code-using-ghcs-new-llvm-codegen/) –

+0

El compilador de GHC está escrito en Haskell, el sistema de tiempo de ejecución de GHC está escrito en C, no en C++. –

0

La implementación Java de Sun parece estar escrita en C++ en su mayoría.

1

Si las pérdidas de memoria son su único problema con su programa actual, intente valgrind en él. Nunca tuve una pérdida de memoria en mi software que valgrind no pudo localizarme. De hecho, ha salvado mi trasero en tantas ocasiones.

Aquí hay un tutorial

http://www.cprogramming.com/debugging/valgrind.html

+0

Valgrind es una herramienta muy útil, pero en el intérprete que adopté (1) las fugas de memoria requerirían soluciones de gran alcance, "radicales", arreglos que me requerirían reescribir partes del código de todos modos y arriesgarme a estropear partes del programa (potencialmente causando punteros colgantes, etc.), y (2) las pérdidas de memoria no son el único problema; hay un montón de cambios en el manejo de símbolos que quiero hacer y el sistema existente es demasiado complicado para cambiar de forma segura, si tiene sentido. –

0

no creo que pueda (o quiera) para darle a este una manta "sí". Creo que es una cuestión de pragmatismo combinado con las necesidades del lenguaje individual, y también depende de si se trata de un lenguaje compilado (o código de bytes compilado) o interpretado, o ...

Si está tratando de escribir código de plataforma, encontrará que el mínimo común denominador suele ser un compilador de C (debido a las diferentes arquitecturas de CPU, los ensambladores no son adecuados para implementar en muchas plataformas).Dado que C++ se codificó para situarse en la parte superior de la mayoría de la infraestructura C (como usar el nombre de manipulación para adaptar las sobrecargas de tipo en algo que un enlazador C entiende), suele ser el lenguaje de OO de menor denominador común disponible incluso en sistemas integrados. Eso lo convierte en una opción popular para las personas que desean escribir su idioma de una manera fácil de mantener y de alto nivel. También, la mayoría de los lenguajes de programación tienen una razón para existir, quieren resolver problemas de una manera diferente (mejor significa necesariamente diferente, después de todo), lo que significa que tienen necesidades bastante inusuales con respecto a lo que su código necesita para poder hacer. , y no use muchas de las instalaciones de soporte que ofrece otro lenguaje de implementación, porque no tendría suficiente control sobre él. Entonces, dado que querrá volver a implementar una gran cantidad de, por ejemplo, el modelo de objetos y los tipos de datos de todos modos, los aspectos de bajo nivel de C++ en realidad son una ventaja.

Dicho esto, muchos idiomas comienzan con su primera versión escrita en C++, un primer compilador simple por ejemplo, y luego escriben la próxima versión en esa versión simple ("arranque"). Esto tiene la ventaja de que puedes usar tu propio idioma para ampliarlo. Para convertirlo en puerto, luego modifican solo su compilador para realizar una compilación cruzada a la plataforma deseada, luego compilan el compilador con este compilador cruzado y el resultado es una versión nativa del lenguaje completo para la nueva plataforma.

Las lenguas que tienden a no hacer esto por lo general son principalmente los lenguajes de script, que tienden a permanecer como interpretado C++ - implementadas idiomas (Aunque otros han mencionado excepciones populares).

Otra razón común para recoger C++ es la infraestructura existente. P.ej. si desea vincularse a los marcos del sistema existentes, a menudo debe desplegar en C++, o si desea aprovechar los back-ends existentes del compilador (como LLVM, que está escrito en C++), o incluso si solo usan C, a menudo C++ es el lenguaje de implementación de OO más adecuado que puede comunicarse fácilmente con las partes C de un sistema.

Así que la pregunta que desea que preguntarse es probable: ¿Cuáles son mis necesidades, y en qué idioma se adapta mejor a las personas?

Algunas lenguas son simplemente pre-procesadores en otro idioma (C++ y Objective-C, tanto comenzaron como preprocesadores en la parte superior de C). Agregan su propia sintaxis o características, las traducen al lenguaje de implementación y luego compilan ese código modificado utilizando un compilador existente. Si un idioma ya hace todo lo que desea, puede ser un mejor enfoque, y le permite aprovechar la experiencia de los ingenieros que trabajan en ese otro idioma, combinando sus horas de trabajo en más de lo que usted solo podría proporcionar.

Cuestiones relacionadas