2017-09-28 16 views
16

czytałem o modułach i chciałem zrobić coś takiego:Czy wszystko po wyeksportowaniu przestrzeni nazw nie jest eksportowane?

a.cpp

module foo.a; 

export namespace foo { 
    struct A { 
     void doA(); 
    }; 
} 

import foo.b; 
void foo::A::doA() { 
    B{}.doB(); 
} 

b.cpp

module foo.b; 

export namespace foo { 
    struct B { 
     void doB(); 
     void start(); 
    }; 
} 

import foo.a; 
import std.io; 
void foo::B::doB() { 
    std::cout << "Stuff done!" << std::endl; 
} 

void foo::B::start() { 
    A{}.doA(); 
} 

main.cpp

import foo.b; 

int main() { 
    foo::B{}.start(); 
} 

Ponieważ interfejsy modułów nie mogą używać się nawzajem, aby to działało, wszystko po wyeksportowaniu ed przestrzeń nazw nie może być częścią interfejsu. Czy powyższe informacje są prawidłowe zgodnie z aktualnymi TS? W przypadku zależności cyklicznej w implementacji wymagane jest podzielenie jej na inny plik?

+0

Niewłaściwie oznaczono twój kod jako c/C++. Proszę oznaczyć ją jako Maszynopis. – StarShine

+4

@StarShine - O czym ty mówisz? – StoryTeller

+0

moduł, import i składnia, takie jak A {}. DoA(), według mojej wiedzy nie są prawidłowe C++. – StarShine

Odpowiedz

2

Z Working Draft, Extensions to C++ for Modules (znajdujący się w Experimental C++ Features), strona 13, §10.7.2 3:

Moduł M1 ma zależność interfejsu, modułu M2 jeżeli moduł interfejs M1 zawiera moduł -import-deklaracja nominująca M2. Moduł nie może mieć zależności interfejsu przechodniego od siebie.

Przykład:

// Interface unit of M1 
export module M1; 
import M2; 
export struct A { }; 

// Interface unit of M2 
export module M2; 
import M3; 

// Interface unit of M3 
export module M3; 
import M1; // error: cyclic interface dependency M3 -> M1 -> M2 -> M3 

Q: "Na okrągłej uzależnienia w realizacji, jest to konieczne, aby podzielić go do innego pliku"

O: Tak.


P: "Czy powyższe informacje odpowiadają aktualnym TS?"

A: Nie.

W kodzie masz błąd, ponieważ foo.a i foo.b tworzą cykliczną zależność interfejs.

+0

Interfejs jest więc całym plikiem, a nie tylko eksportowanym materiałem. Ciekawy. Chyba dlatego, że cała jednostka interfejsu musi zostać skompilowana w celu utworzenia pliku binarnego interfejsu. –

+0

@GuillaumeRacicot: Nie, _interface_ to tylko wyeksportowane elementy (\ [dcl.module.interface]/1). Jednak interfejs _unit_ jest ograniczony. –

+0

@ DavisHerring ah tak, to właśnie miałem na myśli. Nadal nie używam tych wszystkich nowych warunków! –

1

Tak, musisz użyć oddzielnego pliku implementacji dla co najmniej jednego z modułów (ten, który jest koncepcyjnie "niższy poziom"). W PDTS'S [dcl.module.import]/3 mówi

Moduł M1 ma zależność interfejsu na module M2 czy interfejs moduł M1 zawiera modułowy import zgłoszenia mianowanie M2 . Moduł nie może mieć zależności interfejsu przechodniego od siebie.

ta obowiązuje niezależnie od położenia modułu-Import-deklaracji, ponieważ export może pojawić się wszędzie i wielokrotnie w jednostce Interface Module. Reguła ma zapobiegać pojawianiu się typów i szablonów z każdego z dwóch modułów w interfejsie drugiego, ponieważ wtedy nie można zaimportować "pierwszego".

+1

Czy chciałbyś podać odpowiednie informacje z PDTS? To sprawi, że odpowiedź będzie bardziej kompletna. –

+0

@GuillaumeRacicot: OK, gotowe; nie, że gsamaras nie zrobił tego pierwszy. –

+0

W porządku. W rzeczywistości dodajesz informacje, których brakowało w drugiej odpowiedzi. Sprawia, że ​​rzeczy stają się jeszcze bardziej wyraźne. Nie myślałem o ponownym otwarciu eksportu. Dzięki! –

Powiązane problemy