Moduli C ++: perché sono stati rimossi da C ++ 0x? Torneranno più tardi?


110

Ho appena scoperto questa vecchia bozza C ++ 0x sui moduli in C ++ 0x.

L'idea era di uscire dall'attuale sistema .h / .cpp scrivendo solo file .cpp che avrebbero poi generato file di modulo durante la compilazione, che a loro volta sarebbero stati usati dagli altri file .cpp.

Questa sembra davvero una grande caratteristica.

Ma la mia domanda è: perché l'hanno rimosso da C ++ 0x? È stato a causa di troppe difficoltà tecniche? Mancanza di tempo? E pensi che prenderanno in considerazione la possibilità di lavorarci per un'ulteriore versione di C ++?

Risposte:


70

Da State of C ++ Evolution (Post San Francisco 2008) , la proposta Modules è stata classificata come "Intestazione per un TR separato:"

Questi argomenti sono ritenuti troppo importanti per attendere un altro standard dopo C ++ 0x prima di essere pubblicati, ma troppo sperimentali per essere finalizzati in tempo per il prossimo Standard. Pertanto, queste caratteristiche saranno fornite da un rapporto tecnico il prima possibile.

La proposta dei moduli semplicemente non era pronta e l'attesa avrebbe ritardato la fine dello standard C ++ 0x. Non è stato realmente rimosso, semplicemente non è mai stato incorporato nel documento di lavoro.


89

Bozza dei moduli C ++ (Specifiche tecniche dopo C ++ 17)

Una bozza e diverse revisioni aggiornate per la specifica del modulo C / C ++ sono state pubblicate da WG21 su open-std.org. Mi collegherò solo agli ultimi documenti qui:

  • Bozza di lavoro, estensioni a C ++ per i moduli N4610 (ottobre 2016).
  • Quarta revisione pubblicata come P0142R0 (marzo 2016).
  • Formulazione per moduli pubblicata come P0143R2 (marzo 2016).
  • Il team di clang ha pubblicato una seconda revisione delle modifiche: P0273R1 (ottobre 2016).

I seguenti post del blog contengono un riepilogo delle riunioni sugli standard e in particolare un riepilogo dello stato attuale della bozza dei moduli:

Aggiornamento: come spiegato nel report di viaggio di Kona che ho collegato sopra, ci sono attualmente due proposte concorrenti, una di Microsoft e una di Clang. La soluzione proposta da Microsoft non consente di esportare macro, mentre la soluzione del team Clang supporterebbe l'esportazione di macro. Finora solo Microsoft ha presentato formalmente una bozza per una specifica del modulo.

Specifica del modulo proposta da Microsoft

Ecco una rapida panoramica dei concetti più importanti contenuti in questa proposta. Poiché è una bozza, questo potrebbe ancora cambiare. Il nuovo standard dei moduli sarà tra l'altro composto da quanto segue:

Una moduleparola chiave per dichiarare un modulo, più file possono dichiararla per costruire un modulo (ma per ogni modulo solo un'unità di compilazione può contenere una export {}sezione):

module M;

Si potrebbe anche decidere di utilizzare una importparola chiave per importare i moduli, in modo da evitare una nuova parola chiave di importazione.importusing module

import std.io;
import module.submodule;

Una exportsintassi, che definisce le dichiarazioni pubbliche che fanno parte di questo modulo, le dichiarazioni non di interfaccia che non dovrebbero essere esportate come parte del modulo verranno definite al di fuori del blocco di esportazione. Le dichiarazioni possono essere qualsiasi tipo di dichiarazione in C / C ++, ovvero non solo funzioni ma anche variabili, strutture, modelli, spazi dei nomi e classi:

export {
    int f(int);
    double g(double, int);

    int foo;

    namespace Calc {
         int add(int a, int b);
    }        
}

void not_exported_function(char* foo);

Un cambiamento importante dei moduli sarà che le macro e le definizioni del preprocessore saranno locali nei moduli e non verranno esportate. Pertanto le macro non hanno alcun impatto sui moduli importati:

#define FILE "my/file"
import std.io;   //will not be impacted by the above definition

È importante notare che sia il sistema del preprocessore corrente che i moduli saranno in grado di coesistere e le intestazioni possono ancora essere utilizzate, ad esempio, per includere macro.

Per informazioni più dettagliate suggerisco di leggere la bozza.

Moduli Clang

Clang ha lavorato su un'implementazione dei moduli che può essere trovata nella pagina dei moduli clang . Tuttavia, clang attualmente non implementa una sintassi concreta per i moduli, ovvero nessuna delle sintassi sopra menzionate è stata implementata da Clang. Per spiegare questo la pagina contiene la seguente dichiarazione:

Al momento, non esiste una sintassi C o C ++ per le dichiarazioni di importazione. Clang terrà traccia della proposta dei moduli nel comitato C ++. Vedere la sezione Include come importazioni per vedere come i moduli vengono importati oggi.

La parte principale attualmente implementata da Clang è il "Module Map Language" che consente di scrivere mappe dei moduli per il codice esistente che utilizza ancora i file di intestazione.

Esportazioni di macro da moduli

Come accennato in precedenza, non è ancora chiaro se le esportazioni di macro faranno parte dei moduli TS finali . In P0273R1 è stata proposta la seguente sintassi per l'esportazione delle macro:

#export define MAX(A,B) ((A) > (B)) ? (A) : (B);

2
Aggiornamento dal 2018 Rapperswil, c'è la proposta fusa di Gabriel dos Reis e Richard Smith, p1103r0. botondballo.wordpress.com/2018/06/20/…
Dwayne Robinson,

32

Clang è il primo compilatore ad iniziare a lavorare sui moduli anche prima che la standardizzazione sia completa. Non c'è ancora molta documentazione, ma il codice di esempio può essere trovato qui:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/

Alcuni commenti di Douglas Gregor (lo sviluppatore che li implementa):
http://clang-developers.42468.n3.nabble.com/C-modules-td3619936.html

In teoria, puoi definire un gruppo di macro di supporto come begin_module, end_module, import_module per proteggerti da eventuali modifiche alla sintassi che verranno in futuro.

EDIT 1:
Douglas Gregor ha rilasciato una presentazione sulla sua implementazione:
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

EDIT 2:
Il supporto del modulo in clang è stato documentato qui:
http://clang.llvm.org/docs/Modules.html

EDIT 3: i
moduli sono ora supportati anche nel compilatore C ++ di Microsoft: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1. aspx


-39
  1. Perché è un cambiamento concettuale molto grande.
  2. Non ce n'è davvero bisogno poiché la separazione dei sorgenti in h / cpp fa il lavoro
  3. Perché C ++ non definisce come vengono costruite le librerie "moduli" effettive. Lo lascia allo sviluppatore del compilatore e al linker.
  4. I "moduli" a volte sono abbastanza dipendenti dalla piattaforma, ad esempio le DLL abbastanza diverse dagli oggetti condivisi. Quindi non è così banale fondersi tra questi concetti.

78
C'è sicuramente una necessità. .h / .cpp è una soluzione alternativa ridicolmente brutta e antiquata. Un sistema di moduli sarebbe un grande cambiamento, ma è quello che apparentemente il comitato standard considera importante.
jalf

13
Il modello di build dell'intestazione è il problema che i moduli devono risolvere, non la soluzione. Inoltre i moduli non sostituiscono le DLL / SO.
bames53

5
Questo è sbagliato: 1. La proposta del modulo si prende cura di garantire la retrocompatibilità con il sistema di intestazione esistente, quindi nulla si interrompe quando i moduli verranno introdotti in futuro. 2. La necessità di ridurre la complessità del tempo di compilazione del modulo di intestazione da una complessità O (M * N) a O (M + N) è molto ben documentata. 3. Lo standard del modulo non determinerà la modalità di compilazione e collegamento dei moduli, ma aggiunge una chiara semantica per separare l'API privata e pubblica di un modulo. 4. Il formato binario delle DLL o degli oggetti condivisi non è influenzato dallo standard.
lanoxx

3
"Non ce n'è davvero bisogno in quanto la separazione delle sorgenti per h / cpp fa il lavoro" così fa la motosega da un dito iniettato ma ciò non significa che non sia un problema! Basta guardare .NET o qualsiasi altra lingua più recente, dover ordinare le cose in un certo modo solo in modo che possano effettivamente essere visibili o costruite correttamente è un enorme fardello che deve andare via.
paulm
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.