principales - ¿El lenguaje D tiene múltiples bibliotecas estándar y problemas con GC?
librerias dev c++ pdf (6)
Me pregunto cuán madura y estable es D, y si podría ser un buen reemplazo para C / C ++.
Desconfiaba el uso de cualquier lenguaje que aún no estuviera respaldado por un organismo de estándares como ANSI, ISO o ECMA. Ese es quizás un indicador de madurez. Dicho esto, por ejemplo, Java y Delphi caerían en esa categoría y, si bien no uso esos lenguajes, probablemente podrían describirse como "maduros".
Otra medida podría ser el número y la calidad de los libros y artículos escritos para el idioma. Hay un libro para D que conozco de Andrei Alexandrescu. También ha escrito un largo article sobre el lenguaje para el Dr. Dobbs, donde se ocupa específicamente del problema de la biblioteca estándar.
Me pregunto cuán madura y estable es D, y si podría ser un buen reemplazo para C / C ++.
Sé que actualmente hay dos bibliotecas estándar (Phobos y Tango). ¿Sigue siendo el caso que no hay una biblioteca estándar unificada?
Además, hace tiempo escuché que los idiomas tienen problemas en los límites del código GCed / no GCed. No pude encontrar ninguna referencia al respecto en el sitio web de D, ¿es este problema todavía cierto?
Sé que actualmente hay dos bibliotecas estándar (Phobos y Tango), así que supongo que podría haber personas que intenten unificarlas.
La "unificación" es extremadamente improbable debido a las diferencias en las licencias. Cuando el Tango sea portado a D 2.0, podrá usarlo junto con Phobos, lo que no es (fácilmente) posible en D 1.0.
Además, hace tiempo escuché que los idiomas tienen problemas en los límites del código GCed / no GCed. No pude encontrar ninguna referencia al respecto en el sitio web de D, ¿es este problema todavía cierto?
Creo que solo hay problemas si no tienes cuidado con la forma en que administras la memoria. Si todas las referencias a un objeto asignado por GC se almacenan fuera de las regiones de memoria marcadas como raíces de GC, el GC considerará el objeto sin referencia y lo eliminará.
Si tuviera que elegir D como reemplazo de C hoy, ¿qué D (v 1.0 o v 2.0) y qué biblioteca estándar sugeriría?
Fobos y Tango van en direcciones algo diferentes. Phobos (en D 2.0) se relaciona estrechamente con las nuevas características de D2. Tango tiene más funciones y contiene módulos que no están presentes en Phobos, por ejemplo, soporte de cliente HTTP / FTP, varias clases de criptografía, etc. También siguen diferentes filosofías de diseño (Phobos es más imperativo / meta-programación-ish, mientras que El tango es muy estrictamente similar a OOP, y por lo tanto similar a Java en ese sentido).
He tenido una buena experiencia escribiendo un juego pequeño en D1 con Phobos y SDL, pero fue un proyecto bastante pequeño.
En mi opinión, D carece de:
- un foro web oficial donde las personas pueden obtener ayuda y buscar respuestas (NO grupos de noticias)
- un repositorio oficial para muchos SDK convertidos a D (por ejemplo, SDL, Gtk, etc. A menudo son difíciles de encontrar y usar, cuando existen).
La versión 1 de D es madura y estable, y definitivamente hay gente que la usa para un trabajo real. Phobos es la única biblioteca estándar que D ha tenido o probablemente tendrá alguna vez, pero Phobos de D1 carece lo suficiente como para crear varias bibliotecas de terceros para llenar los vacíos. El tango es el más grande de estos y es la biblioteca de terceros más utilizada (de ahí que a menudo se la llame una segunda biblioteca estándar aunque no lo sea, y Walter Bright se apresurará a señalar que no lo es). Sin embargo, Tango y Phobos en D1 no se mezclan muy bien (IIRC porque el Tango reemplaza algunas cosas estándar como el recolector de basura), por lo que es muy probable que alguien que programe en D1 use Tango sin Phobos. Además, D1 es compatible con varios compiladores, además del compilador principal de Digital Mars, incluidos LDC y gdc.
La versión 2 de D acaba de alcanzar la madurez y la estabilidad. Han dejado de realizar cambios importantes en el idioma, por lo que, por lo general, no tiene que preocuparse por todo lo que le sucede con una actualización del compilador, como sucedió en el pasado, mientras aún estaban eliminando el idioma. De hecho, ahora es lo suficientemente maduro como para que Andrei Alexandrescu lanzara The D Programming Language como un recurso definitivo sobre el lenguaje que debería seguir siendo válido, salvo los errores en el texto (y es uno de los mejores libros de lenguaje de programación que también he leído). Sin embargo, todavía hay una gran cantidad de correcciones de errores, por lo que es muy posible encontrar un error que le cause un poco de irritación a su aplicación en particular. Definitivamente es lo suficientemente maduro y lo suficientemente estable como para hacer un trabajo real con él, pero ten en cuenta que es muy posible encontrar errores.
El tango aún no se ha trasladado a D2, por lo que no es realmente una opción al programar en D2. Sin embargo, Phobos está saliendo bastante bien ahora. Se le están agregando muchas novedades (¡en realidad tiene contenedores ahora! - la falta de contenedores en Phobos es una razón importante para usar Tango en D1 en lugar de Phobos), y tiene algunas cosas realmente poderosas - stal.algorithm es particularmente agradable La forma en que D maneja las funciones lambda, las funciones anidadas y los punteros de función hace que las funciones pasadas a algoritmos de años luz sean más fáciles de lo que es en el estándar actual de C ++. Además, se ha corregido en D2 para que el recolector de basura y algunas otras cosas centrales que Tango estaba duplicando ahora estén separados de Phobos. Por lo tanto, una vez que Tango se haya trasladado a D2, podrá combinar el código de Phobos y el código de Tango, aunque como se señaló anteriormente, Phobos y Tango utilizan filosofías de diseño bastante diferentes (el Tango es muy similar a Java y Phobos usando plantillas y metaprogramas con tecleado en lugar de interfaces, así que no sé qué tan bien se mezclarán desde ese punto de vista.
Actualmente, creo que dmd es el único compilador que está actualizado con respecto a la especificación para D2, pero creo que se está trabajando en los compiladores gdc y LDC D (aunque cuán activo es ese trabajo, no se) Además, Walter Bright está trabajando actualmente en el puerto de 64 bits de dmd, por lo que pronto tendremos una compilación nativa de 64 bits.
En general, diría que D2 está listo para su uso, pero debe tener en cuenta que todavía hay mucho trabajo por hacer con respecto a las correcciones de errores y similares. Entonces, D2 definitivamente está listo para el uso de pasatiempos y potencialmente para un uso serio en el trabajo, pero si realmente necesitas estabilidad (como si Boeing y un error significan muerte), D1 probablemente todavía sea una mejor opción. Por supuesto, lo más importante que hay que recordar acerca de D2 es que tiene muchas características que D1 no tiene, así que, a menos que realmente necesite una estabilidad sólida como una roca, entonces D2 es probablemente el camino a seguir. Afortunadamente, continúa madurando y estabilizándose, por lo que definitivamente se acerca el momento en que no habrá dudas de que usar D2 sería mejor.
En cualquier caso, tanto D1 como D2 son buenos reemplazos para C y C ++ en el caso general. Pueden hacer lo que C y C ++ hacen, y (especialmente en el caso de D2) probablemente pueden hacerlo mejor. El lugar principal en el que D podría quedarse atrás es en qué tan bien está optimizado. Hay un montón de código que será tan rápido en D como en C o C ++, pero aún hay mucho trabajo por hacer en D, por lo que hay mucho espacio para optimizarlo aún más, y algunas veces se quedará atrás de C y C ++ por eficiencia . Entonces, en general, D es eficiente, pero si realmente necesitas tanta eficiencia como puedas, puede que aún no sea lo suficientemente bueno para lo que necesitas (aunque está llegando). Además, hay muchas bibliotecas C y C ++ maduras por ahí, mientras que D no tiene el mismo nivel de código flotante para trabajar. Cualquier código C podría usarse con D, ya que las funciones de C pueden llamarse desde D, y algunos de los códigos C ++ podrían serlo (aunque existen algunas restricciones al mezclar código C ++ con D), por lo que no sería necesariamente demasiado Un impedimento, pero es algo a tener en cuenta. El lugar principal donde falta es las bibliotecas GUI. Hay algunos para D1, y se está trabajando en las bibliotecas GUI para D2, pero no creo que ninguno de ellos sea particularmente maduro en este momento.
Entonces, al igual que con todo, el idioma que debes usar depende de lo que estés haciendo. D hará la mayoría de las cosas y las hará bien. Pero no lo hace todo, y sigue madurando. Personalmente, en este punto, uso D a menos que necesite usar otra cosa para un proyecto en particular, que no suele ser a menos que el proyecto ya esté escrito en otra cosa, y no tiene sentido portarlo en este momento. Por lo tanto, sugiero encarecidamente que uses D, pero tendrás que estudiarlo y usarlo para ver si realmente hará lo que quieres en este momento.
No creo que la cuestión de reemplazar C sea sobre si un reemplazo potencial es lo suficientemente "bueno" o "maduro" en un nivel teórico, sino más bien sobre consideraciones prácticas y el hecho de que C es "lo suficientemente bueno" para lo que se utiliza. . A menos que un idioma tenga entornos nativos completos de compilación y tiempo de ejecución para todos los sistemas operativos principales que existen, no es realmente práctico para qué se utiliza C. El hecho de que C sea el lenguaje de POSIX es una parte importante de todo el problema.
Seguramente otros lenguajes de nivel medio bajo como D podrían tener excelentes aplicaciones en campos especializados. Pero es poco probable que vea un software multiplataforma importante (servidores web, servidores de bases de datos, procesadores de texto, navegadores web, etc.) escrito en D porque ningún sistema operativo principal (y mucho menos todos) viene con una compilación D o un entorno de tiempo de ejecución.
Recomiendo usar D2 con Phobos. Es en el punto donde el lenguaje es lo suficientemente agradable y estable como para compensar las frustraciones ocasionales causadas por problemas de implementación.