todas - ¿Cómo debo escribir mi C++ para estar preparado para los módulos C++?

programacion en c++ (2)

Ya hay dos compiladores que admiten módulos C ++:

Al comenzar un nuevo proyecto ahora, ¿a qué debo prestar atención para poder adoptar la función de módulos cuando finalmente se lance en mi compilador?

¿Es posible utilizar módulos y mantener la compatibilidad con compiladores más antiguos que no lo admiten?

¿Es posible utilizar módulos y mantener la compatibilidad con compiladores más antiguos que no lo admiten?

No, no es posible. Podría ser posible usando algo de magia #ifdef como esta:

#ifdef CXX17_MODULES ... #else #pragma once, #include "..." etc. #endif

pero esto significa que aún necesita proporcionar soporte .h y así perder todos los beneficios, además de que su base de código se ve bastante fea ahora.

Si desea seguir este enfoque, la forma más fácil de detectar " CXX17_MODULES " que acabo de inventar es compilar un pequeño programa de prueba que use módulos con un sistema de compilación de su elección, y definir un global para que todos vean si la compilación tuvo éxito o no.

Al comenzar un nuevo proyecto ahora, ¿a qué debo prestar atención para poder adoptar la función de módulos cuando finalmente se lance en mi compilador?

Depende. Si su proyecto es empresarial y le da comida en el plato, esperaría unos años una vez que se lance en los establos para que se adapte ampliamente. Por otro lado, si su proyecto puede permitirse ser innovador, utilice todos los módulos.

Básicamente, es la misma historia que con Python3 y Python2, o menos relevante, PHP7 y PHP5. Debe encontrar un equilibrio entre ser un buen programador actualizado y no molestar a las personas en Debian ;-)

Ya hay dos compiladores que admiten módulos C ++

clang: http://clang.llvm.org/docs/Modules.html MS VS 2015: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1.aspx

El enfoque de Microsoft parece ser el que está ganando más tracción, principalmente porque Microsoft está invirtiendo muchos más recursos en su implementación que cualquiera de la gente clang actualmente. Vea https://llvm.org/bugs/buglist.cgi?list_id=100798&query_format=advanced&component=Modules&product=clang para lo que quiero decir, hay algunos errores importantes en los módulos para C ++, mientras que los módulos para C o especialmente Objective C se ven mucho más utilizable en código del mundo real. El cliente más grande e importante de Visual Studio, Microsoft, está presionando mucho por los Módulos porque resuelve un montón de problemas de escalabilidad de compilación interna, y el código interno de Microsoft es uno de los C ++ más difíciles de compilar en cualquier lugar para que no pueda lanzar ningún compilador que no sea MSVC (p. ej., buena suerte para obtener el sonido metálico o GCC para compilar funciones de línea de 40k). Por lo tanto, los trucos de compilación de clang utilizados por Google, etc., no están disponibles para Microsoft, y tienen una gran necesidad de solucionarlo lo antes posible.

Esto no quiere decir que no haya fallas de diseño serias con la propuesta de Microsoft cuando se aplica en la práctica a grandes bases de código del mundo real. Sin embargo, Gaby es de la opinión de que debería refactorizar su código para Módulos, y aunque no estoy de acuerdo, puedo ver de dónde viene.

Al comenzar un nuevo proyecto ahora, ¿a qué debo prestar atención para poder adoptar la función de módulos cuando finalmente se lance en mi compilador?

En la medida en que se espera que el compilador de Microsoft implemente Módulos, debe asegurarse de que su biblioteca sea utilizable en todas estas formas:

Biblioteca dinámica
Biblioteca estática
Biblioteca de solo encabezado

Algo muy sorprendente para muchas personas es que los módulos C ++ como se espera que se implementen actualmente mantienen esas distinciones, por lo que ahora obtienes una variante del módulo C ++ para los tres anteriores, y el primero se parece más a lo que la gente espera que sea un módulo C ++, y el último que parece un encabezado precompilado más útil. La razón por la que debería admitir esas variantes es porque puede reutilizar la mayoría de la misma maquinaria de preprocesador para admitir también módulos C ++ con muy poco trabajo adicional.

Un Visual Studio posterior permitirá la vinculación del archivo de definición del módulo (el archivo .ifc) como un recurso en las DLL. Esto finalmente eliminará la necesidad de la distinción .lib y .dll en MSVC, simplemente proporciona una única DLL al compilador y todo "simplemente funciona" en la importación del módulo, no se necesitan encabezados ni nada más. Por supuesto, esto huele un poco a COM, pero sin la mayoría de los beneficios de COM.

¿Es posible usar módulos en una única base de código y aún mantener la compatibilidad con compiladores más antiguos que no lo admiten?

Asumiré que te referías al texto en negrita insertado arriba.

La respuesta es generalmente sí con aún más diversión macro de preprocesador. #include <someheader> puede convertirse en un import someheader dentro del encabezado porque el preprocesador aún funciona como de costumbre. Por lo tanto, puede marcar encabezados de bibliotecas individuales con soporte de módulos C ++ a lo largo de algo como estas líneas:

// someheader.hpp #if MODULES_ENABLED # ifndef EXPORTING_MODULE import someheader; // Bring in the precompiled module from the database // Do NOT set NEED_DEFINE so this include exits out doing nothing more # else // We are at the generating the module stage, so mark up the namespace for export # define SOMEHEADER_DECL export # define NEED_DEFINE # endif #else // Modules are not turned on, so declare everything inline as per the old way # define SOMEHEADER_DECL # define NEED_DEFINE #endif #ifdef NEED_DEFINE SOMEHEADER_DECL namespace someheader { // usual classes and decls here } #endif

Ahora en tu main.cpp o lo que sea, simplemente haces:

#include "someheader.hpp"

... y si el compilador tenía / experimental: modules / DMODULES_ENABLED, entonces su aplicación usa automáticamente la edición de Módulos C ++ de su biblioteca. Si no es así, obtienes inclusión en línea como siempre lo hemos hecho.

Creo que estos son el conjunto mínimo posible de cambios en su código fuente para que su código esté listo para los módulos ahora. Notarán que no he dicho nada sobre los sistemas de compilación, esto se debe a que todavía estoy depurando las herramientas de cmake que he escrito para que todo esto "simplemente funcione" sin problemas y espero que lo esté depurando durante algunos meses todavía. Espere verlo tal vez en una conferencia de C ++ el próximo año o al año siguiente :)