CRTP i rodzaj widoczność

Question

mam zagadkę który próbuję rozwiązać, i zasadniczo sprowadza się do następującego przykładu:

template <typename CT> 
struct A 
{ 
    typedef typename CT::VALUE_T FOO; // FOO is dependent on CT 
}; 

template <typename CT> 
struct B 
{ 
    typedef typename CT::BAR BAR; 

    BAR foo() {} 
}; 

template <typename DT> 
struct C : B<C<DT> > 
{ 
    typedef DT VALUE_T; 

    typedef typename A<C>::FOO BAR; 
}; 

int main() { 
    C<int> c; 
} 

mogę spróbować wyjaśnić powyższe (próbowałem około trzy razy i usunięty tekst), ale w zasadzie wymagania są:

1. C musi dziedziczyć z B wpisane z C (wydobywająca CRTP), tj B<C<>>
2. C jest jedynym, który może utworzyć wystąpienie A (tj. A musi być wpisany z C)
3. A jest jedynym, który może określić FOO (FOO jest zależna od rodzaju CT, związek jest bardziej skomplikowana niż przedstawiony)

Problem (jak można patrz powyższy kod) jest to, że typ BAR jest dostępny tylko w zakresie C i jest niekompletny, gdy B jest utworzony, dlatego B nie widzi typu BAR z argumentem szablonu CT (C<int>). Niestety w zakresie B, typ BAR jest używany jako argumenty funkcji i typy zwracane (to znaczy nie tylko ograniczone do zakresu funkcji - w rezultacie nie mogę po prostu przenieść zakresu typedef do funkcji).

Czy istnieje sposób obejścia tego? Nie mogę złamać wyżej wymienionych związków (chyba że w ostateczności). Przypuszczalnie przy pomocy C++ 11, mógłbym użyć auto i obejść potrzebę posiadania BAR typedef w B, jednak obecnie nie jest to jeszcze opcja.

EDYCJA: podążanie za komentarzem @bitmasks, trochę więcej informacji.

1. Kod w A i B służy się w kilku plików binarnych w różnych sytuacjach, tylko wyjątkowa sytuacja w tym przypadku jest to, że C wywodzi B, w pozostałych przypadkach C posiada instancję czegoś pochodzącego z B.
2. Argumenty szablonu można zmienić (w A i B), o ile mogą być domyślnie ustawione na wartości, które nie wymagają zmiany istniejących zastosowań A i B. Ten sam zestaw typów musi być dostępny jako domyślny parametr szablonu lub inny mechanizm.

Używam szablonów po prostu dlatego, że wymagam ścisłego sprzężenia i potrzebuję elastyczności, aby użyć kodu w różnych sytuacjach.

Opisy elementów:

• A najlepiej można opisać jako kontener i FOO naprawdę jest iterator, co zawiera określony jest przez typedef parametru szablonu
• B najlepiej można opisać jako klasa podstawowa, która zawiera zestaw funkcji, które są wywoływane przez niektóre komponenty posiadane przez instancję C. W poprzednich przypadkach składniki te zostały przekazane jako odniesienie do rzeczy pochodzących z B (i te rzeczy są również własnością C), w tym przypadku, zapewniam odwołanie do samej C.

Głównym powikłaniem wynika z dostępu do pojemnika A wcześniej związek między B i C że Cma instancję z B, ale teraz Cjest instancją z B - ta zmiana semantyki przerw sposób w jaki typy są wstrzykiwane do klas.

Answer 1

Myślę, że możesz walczyć z wymogiem cyklicznym typedef z domyślnymi parametrami szablonu. Poniższe działa zgodnie z przeznaczeniem (o ile dobrze rozumiem pytanie) i pozostawia się (prawie) wszystkie wolnościami oryginalnego kodu:

template <typename CT, typename CTVALUE_T = typename CT::VALUE_T> 
struct A 
{ 
    //typedef typename CT::VALUE_T FOO; // FOO is dependent on CT 
    typedef CTVALUE_T FOO; // FOO is dependent on CT 
}; 

template <typename CT, typename CTBAR = typename CT::BAR> 
struct B 
{ 
    //typedef typename CT::BAR BAR; 
    typedef CTBAR BAR; 

    BAR foo() {return 0;} 
}; 

template <typename DT> struct VALUE_T__from__DT { 
    typedef DT VALUE_T; 
}; 

template <typename DT, template <class T> class _C_ > struct BAR__from__DT { 
    typedef typename A<_C_<DT> , typename VALUE_T__from__DT<DT>::VALUE_T >::FOO BAR; 
}; 

template <typename DT> 
struct C : B<C<DT>, typename BAR__from__DT<DT, C >::BAR > 
{ 
    //typedef DT VALUE_T; 

    //typedef typename A<C>::FOO BAR; 
}; 

int main() { 
    C<int> c; 
    int x = c.foo(); 
    (void)x; 
    return 0; 
} 

nazwiskami pomocnika rodzaje szablonów są straszne, być może można znaleźć lepsze nazwy.

Podstawową sztuczką jest to, że definicja problematyczna typedef s jest umieszczana w oddzielnym metakontenerie (tj. Pojemniku na cechy), tak że można tam nadal wykonywać dowolny voodoo.

Skomentowałem niepotrzebne typy (ale zostawiłem je, abyś miał większą szansę na zorientowanie się, co tu robię).

Czy to pasuje do twoich potrzeb?