Właśnie odkryłem ten stary szkic C ++ 0x o modułach w C ++ 0x.

Pomysł polegał na tym, aby wyjść z obecnego systemu .h / .cpp, zapisując tylko pliki .cpp, które następnie generowałyby pliki modułów podczas kompilacji, które z kolei byłyby używane przez inne pliki .cpp.

To wygląda na naprawdę świetną funkcję.

Ale moje pytanie brzmi: dlaczego usunęli go z C ++ 0x? Czy to z powodu zbyt wielu trudności technicznych? Brak czasu? I czy myślisz, że rozważą pracę nad tym dla dalszej wersji C ++?

Ze stanu C ++ Evolution (wydanego po San Francisco 2008) propozycja modułów została sklasyfikowana jako „Kierunek oddzielnego TR:”

Te tematy są uważane za zbyt ważne, aby czekać na kolejny standard po C ++ 0x przed opublikowaniem, ale są zbyt eksperymentalne, aby można je było sfinalizować na czas do następnego standardu. Dlatego te funkcje zostaną dostarczone w raporcie technicznym przy najbliższej okazji.

Propozycja modułów po prostu nie była gotowa i oczekiwanie na nią opóźniłoby ukończenie standardu C ++ 0x. Tak naprawdę nie został usunięty, po prostu nigdy nie został włączony do dokumentu roboczego.

Projekt modułów C ++ (specyfikacja techniczna po C ++ 17)

Szkic i kilka zaktualizowanych wersji specyfikacji modułu C / C ++ zostało opublikowanych przez WG21 na open-std.org. Podam link tylko do najnowszych dokumentów tutaj:

• Working Draft, Extensions to C ++ for Modules N4610 (październik 2016).
• Czwarta rewizja opublikowana jako P0142R0 (marzec 2016).
• Sformułowanie dla modułów opublikowanych jako P0143R2 (marzec 2016).
• Zespół clang opublikował drugą wersję swoich zmian: P0273R1 (październik 2016).

Poniższe posty na blogu zawierają podsumowanie spotkań normalizacyjnych, aw szczególności podsumowanie aktualnego stanu projektu modułów:

• Raport z podróży: Spotkanie na temat standardów C ++ w Lenexa (maj 2015).
• Raport z podróży: Spotkanie na temat standardów C ++ w Kona (październik 2015).
• Raport z podróży: Spotkanie dotyczące standardów C ++ w Jacksonville (luty 2016).
• Raport z podróży: Spotkanie dotyczące standardów C ++ w Oulu (czerwiec 2016).
• Raport z podróży: Spotkanie dotyczące standardów C ++ w Issaquah (listopad 2016).

Aktualizacja: Jak wyjaśniono w raporcie z podróży Kona, do którego odniosłem się powyżej, obecnie istnieją dwie konkurencyjne oferty, jedna od firmy Microsoft i jedna od Clang. Proponowane rozwiązanie firmy Microsoft nie pozwala na eksport makr, natomiast rozwiązanie zespołu Clang wspierałoby eksportowanie makr. Jak dotąd tylko Microsoft złożył formalnie projekt specyfikacji modułu.

Specyfikacja modułu zgodnie z propozycją firmy Microsoft

Oto krótki przegląd najważniejszych pojęć zawartych w tej propozycji. Ponieważ jest to szkic, może to się jeszcze zmienić. Nowy standard modułów będzie składał się między innymi z:

Słowo modulekluczowe do deklarowania modułu, wiele plików może zadeklarować to, aby zbudować jeden moduł (ale dla każdego modułu tylko jedna jednostka kompilacji może zawierać export {}sekcję):

module M;

importSłów kluczowych modułów importu, zamiast importniego może być również postanowił wykorzystać using modulezamiast, więc można by uniknąć nowego słowa kluczowego import.

import std.io;
import module.submodule;

exportSkładnia, która definiuje publiczne deklaracje , które są częścią tego modułu, bez interfejsu deklaracje , które nie powinny być wywożone w ramach modułu zostaną określone na zewnątrz bloku eksportu. Deklaracje mogą być dowolnymi deklaracjami w C / C ++, czyli nie tylko funkcjami, ale także zmiennymi, strukturami, szablonami, przestrzeniami nazw i klasami:

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

    int foo;

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

void not_exported_function(char* foo);

Ważną zmianą modułów będzie to, że makra i definicje preprocesorów będą lokalne dla modułów i nie będą eksportowane. Dlatego makra nie mają żadnego wpływu na importowane moduły:

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

Należy zauważyć, że zarówno obecny system preprocesora, jak i moduły będą mogły współistnieć, a nagłówki mogą być nadal używane na przykład do dołączania makr.

Aby uzyskać bardziej szczegółowe informacje, proponuję przeczytać projekt.

Moduły Clang

Clang pracuje nad implementacją modułów, którą można znaleźć na stronie modułów clang . Jednak Clang nie implementuje obecnie konkretnej składni dla modułów, to znaczy żadna z wyżej wymienionych składni nie została zaimplementowana przez Clang. Aby to wyjaśnić, strona zawiera następujące oświadczenie:

Obecnie nie ma składni C lub C ++ dla deklaracji importu. Clang będzie śledzić propozycje modułów w komisji C ++. Zobacz sekcję Uwzględnia jako import, aby zobaczyć, jak moduły są dziś importowane.

Główną częścią obecnie wdrażaną przez Clang jest „Język mapy modułów”, który umożliwia pisanie map modułów dla istniejącego kodu, który nadal używa plików nagłówkowych.

Eksport makr z modułów

Jak wspomniano powyżej, nadal nie jest jasne, czy eksport makr będzie częścią ostatecznej wersji TS Modułów . W P0273R1 zaproponowano następującą składnię do eksportu makr:

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

Clang jest pierwszym kompilatorem, który rozpoczął pracę nad modułami jeszcze przed zakończeniem standaryzacji. Nie ma jeszcze wiele dokumentacji, ale przykładowy kod można znaleźć tutaj:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/

Kilka komentarzy od Douglasa Gregora (programisty je wdrażającego):
http://clang-developers.42468.n3.nabble.com/C-modules-td3619936.html

Teoretycznie możesz zdefiniować kilka pomocniczych makr, takich jak begin_module, end_module, import_module, aby uchronić się przed wszelkimi prawdopodobnymi zmianami składni, które nadejdą w przyszłości.

EDYCJA 1:
Douglas Gregor opublikował prezentację na temat swojej implementacji:
http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf?=submit

EDYCJA 2:
Wsparcie modułu w clang zostało udokumentowane tutaj:
http://clang.llvm.org/docs/Modules.html

EDYCJA 3:
Moduły są teraz obsługiwane również w kompilatorze C ++ firmy Microsoft: http://blogs.msdn.com/b/vcblog/archive/2015/12/03/c-modules-in-vs-2015-update-1. aspx

1. Ponieważ jest to bardzo duża zmiana koncepcyjna.
2. Nie ma takiej potrzeby, ponieważ separacja źródeł do h / cpp spełnia swoje zadanie
3. Ponieważ C ++ nie definiuje, w jaki sposób budowane są rzeczywiste biblioteki „modułów”. Pozostawia to deweloperowi kompilatora i konsolidatorowi.
4. „Moduły” są czasami dość zależne od platformy, na przykład biblioteki DLL są zupełnie inne niż obiekty współdzielone. Dlatego połączenie tych pojęć nie jest takie trywialne.