Dlaczego nie wywnioskować parametru szablonu z konstruktora?

Moje dzisiejsze pytanie jest dość proste: dlaczego kompilator nie może wywnioskować parametrów szablonu z konstruktorów klas, podobnie jak może to zrobić z parametrów funkcji? Na przykład, dlaczego następujący kod nie mógł być prawidłowy:

template<typename obj>
class Variable {
      obj data;
      public: Variable(obj d)
              {
                   data = d;
              }
};

int main()
{
    int num = 2;
    Variable var(num); //would be equivalent to Variable<int> var(num),
    return 0;          //but actually a compile error
}

Jak mówię, rozumiem, że to nie jest poprawne, więc moje pytanie brzmi: dlaczego tak nie jest? Czy pozwolenie na to stworzyłoby jakieś poważne luki składniowe? Czy istnieje przypadek, w którym nie chciałoby się tej funkcjonalności (gdzie wnioskowanie typu spowodowałoby problemy)? Po prostu próbuję zrozumieć logikę stojącą za zezwalaniem na wnioskowanie z szablonu dla funkcji, ale nie dla odpowiednio skonstruowanych klas.

Myślę, że nie jest to poprawne, ponieważ konstruktor nie zawsze jest jedynym punktem wejścia klasy (mówię o konstruktorze kopiującym i operatorze =). Załóżmy więc, że używasz swojej klasy w następujący sposób:

MyClass m(string s);
MyClass *pm;
*pm = m;

Nie jestem pewien, czy analizator składni wiedziałby, jaki typ szablonu to MyClass pm;

Nie jestem pewien, czy to, co powiedziałem, ma sens, ale możesz dodać komentarz, to interesujące pytanie.

C ++ 17

Przyjmuje się, że C ++ 17 będzie miał dedukcję typu z argumentów konstruktora.

Przykłady:

std::pair p(2, 4.5);
std::tuple t(4, 3, 2.5);

Akceptowany papier .

Nie możesz zrobić tego, o co prosisz, z powodów wskazanych przez inne osoby, ale możesz to zrobić:

template<typename T>
class Variable {
    public: Variable(T d) {}
};
template<typename T>
Variable<T> make_variable(T instance) {
  return Variable<T>(instance);
}

który ze wszystkich zamiarów i celów jest tym samym, o co prosisz. Jeśli kochasz hermetyzację, możesz uczynić make_variable statyczną funkcją składową. Tak ludzie nazywają konstruktora. Więc nie tylko robi to, co chcesz, ale nazywa się to prawie tym, czego chcesz: kompilator wnioskuje parametr szablonu z (nazwanego) konstruktora.

Uwaga: każdy rozsądny kompilator zoptymalizuje tymczasowy obiekt, kiedy napiszesz coś takiego jak

auto v = make_variable(instance);

W oświeconym wieku 2016 roku, gdy mamy dwa nowe standardy od czasu zadania tego pytania i nowy tuż za rogiem, najważniejsze jest to, aby wiedzieć, że kompilatory obsługujące standard C ++ 17 skompilują kod tak, jak jest .

Odliczenie argumentów-szablonów dla szablonów klas w C ++ 17

Tutaj (dzięki uprzejmości redakcji przyjętej odpowiedzi Olzhasa Zhumabka) znajduje się artykuł szczegółowo opisujący odpowiednie zmiany w standardzie.

Rozwiązywanie problemów wynikających z innych odpowiedzi

Aktualnie najwyżej oceniana odpowiedź

Ta odpowiedź wskazuje, że „konstruktor kopiujący i operator=” nie znałby prawidłowych specjalizacji szablonów.

To nonsens, ponieważ standardowy konstruktor kopiujący operator= istnieje tylko dla znanego typu szablonu:

template <typename T>
class MyClass {
    MyClass(const MyClass&) =default;
    ... etc...
};

// usage example modified from the answer
MyClass m(string("blah blah blah"));
MyClass *pm;   // WHAT IS THIS?
*pm = m;

Oto, jak zauważył w komentarzach, nie ma żadnego powodu, aby MyClass *pmbyć deklaracja prawny z lub bez nowej formy wnioskowania: MyClass Nie jest typem (jest to szablon), więc to nie ma sensu, aby zadeklarować wskaźnik z typ MyClass. Oto jeden możliwy sposób naprawienia tego przykładu:

MyClass m(string("blah blah blah"));
decltype(m) *pm;               // uses type inference!
*pm = m;

Tutaj pmjest już właściwego typu, więc wnioskowanie jest banalne. Co więcej, nie można przypadkowo pomieszać typów podczas wywoływania konstruktora kopiującego:

MyClass m(string("blah blah blah"));
auto pm = &(MyClass(m));

Tutaj pmbędzie wskaźnik do kopii m. Tutaj MyClassjest konstruowana na podstawie kopii - mktóra jest typu MyClass<string>(a nie typu nieistniejącego MyClass). Tak więc, w miejscu, gdzie pm„s typ jest wywnioskować, że jest wystarczająca ilość informacji, aby wiedzieć, że szablon-typ m, a zatem szablon-typ pmjest string.

Co więcej, następujące informacje zawsze powodują błąd kompilacji :

MyClass s(string("blah blah blah"));
MyClass i(3);
i = s;

Dzieje się tak, ponieważ deklaracja konstruktora kopiującego nie jest szablonem:

MyClass(const MyClass&);

W tym przypadku typ szablonu argumentu kopiuj-konstruktora jest zgodny z typem szablonu całej klasy; tj. kiedy MyClass<string>jest tworzony, MyClass<string>::MyClass(const MyClass<string>&);jest tworzony z nim, a kiedy MyClass<int>jest tworzony, MyClass<int>::MyClass(const MyClass<int>&);jest tworzony. O ile nie zostanie to jawnie określone lub nie zostanie zadeklarowany konstruktor oparty na szablonie, nie ma powodu, dla którego kompilator MyClass<int>::MyClass(const MyClass<string>&);miałby tworzyć instancję , co oczywiście byłoby niewłaściwe.

Odpowiedź Cătălin Pitiș

Pitis podaje przykład wyciągania Variable<int>i Variable<double>, po czym stwierdza:

Mam tę samą nazwę typu (zmienna) w kodzie dla dwóch różnych typów (zmienna i zmienna). Z mojego subiektywnego punktu widzenia ma to duży wpływ na czytelność kodu.

Jak zauważono w poprzednim przykładzie, Variablesama w sobie nie jest nazwą typu, mimo że nowa funkcja sprawia, że ​​wygląda jak nazwa.

Pitiș pyta następnie, co by się stało, gdyby nie podano konstruktora, który pozwoliłby na odpowiednie wnioskowanie. Odpowiedź brzmi, że żadne wnioskowanie nie jest dozwolone, ponieważ jest ono wyzwalane przez wywołanie konstruktora . Bez wywołania konstruktora nie ma wnioskowania .

Jest to podobne do pytania o wersję foowydedukowaną tutaj:

template <typename T> foo();
foo();

Odpowiedź brzmi, że ten kod jest nielegalny z podanego powodu.

Odpowiedź MSaltera

O ile mi wiadomo, jest to jedyna odpowiedź, która może wzbudzić uzasadnione obawy dotyczące proponowanej funkcji.

Oto przykład:

Variable var(num);  // If equivalent to Variable<int> var(num),
Variable var2(var); // Variable<int> or Variable<Variable<int>> ?

Kluczowe pytanie brzmi: czy kompilator wybiera tutaj konstruktor wywodzący się z typu , czy konstruktor kopiujący ?

Wypróbowując kod, widzimy, że wybrany został konstruktor kopiujący. Aby rozwinąć przykład :

Variable var(num);          // infering ctor
Variable var2(var);         // copy ctor
Variable var3(move(var));   // move ctor
// Variable var4(Variable(num));     // compiler error

Nie jestem pewien, jak to określa propozycja i nowa wersja normy; wydaje się, że określają go „przewodniki po dedukcji”, które są nowym kawałkiem standardu, którego jeszcze nie rozumiem.

Nie jestem też pewien, dlaczego var4odliczenie jest nielegalne; błąd kompilatora z g ++ wydaje się wskazywać, że instrukcja jest analizowana jako deklaracja funkcji.

Wciąż brakuje: sprawia, że ​​następujący kod jest dość niejednoznaczny:

int main()
{
    int num = 2;
    Variable var(num);  // If equivalent to Variable<int> var(num),
    Variable var2(var); //Variable<int> or Variable<Variable<int>> ?
}

Przypuśćmy, że kompilator obsługuje to, o co prosiłeś. Wtedy ten kod jest ważny:

Variable v1( 10); // Variable<int>

// Some code here

Variable v2( 20.4); // Variable<double>

Teraz mam tę samą nazwę typu (zmienna) w kodzie dla dwóch różnych typów (zmienna i zmienna). Z mojego subiektywnego punktu widzenia ma to duży wpływ na czytelność kodu. Posiadanie tej samej nazwy typu dla dwóch różnych typów w tej samej przestrzeni nazw wydaje mi się mylące.

Późniejsza aktualizacja: Kolejna rzecz do rozważenia: częściowa (lub pełna) specjalizacja szablonów.

A co, jeśli specjalizuję się w zmiennej i nie dostarczam konstruktora takiego, jakiego oczekujesz?

Więc miałbym:

template<>
class Variable<int>
{
// Provide default constructor only.
};

Następnie mam kod:

Variable v( 10);

Co powinien zrobić kompilator? Użyj ogólnej definicji klasy Variable, aby wywnioskować, że jest to zmienna, a następnie przekonaj się, że zmienna nie zapewnia jednego konstruktora parametrów?

Standardy C ++ 03 i C ++ 11 nie pozwalają na wyprowadzanie argumentów szablonu z parametrów przekazanych do konstruktora.

Ale jest propozycja "Odliczenie parametrów szablonu dla konstruktorów", więc możesz otrzymać to, o co prosisz wkrótce. Edycja: rzeczywiście, ta funkcja została potwierdzona dla C ++ 17.

Zobacz: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3602.html i http://www.open-std.org/jtc1/sc22/wg21/docs/ dokumenty / 2015 / p0091r0.html

Wiele klas nie zależy od parametrów konstruktora. Istnieje tylko kilka klas, które mają tylko jeden konstruktor i parametryzują na podstawie typów tego konstruktora.

Jeśli naprawdę potrzebujesz wnioskowania z szablonu, użyj funkcji pomocniczej:

template<typename obj>
class Variable 
{
      obj data;
public: 
      Variable(obj d)
      : data(d)
      { }
};

template<typename obj>
inline Variable<obj> makeVariable(const obj& d)
{
    return Variable<obj>(d);
}

Odliczanie typów jest ograniczone do funkcji szablonów w obecnym C ++, ale od dawna zdawano sobie sprawę, że odejmowanie typów w innych kontekstach byłoby bardzo przydatne. Stąd C ++ 0x auto.

Chociaż dokładnie to , co sugerujesz, nie będzie możliwe w C ++ 0x, poniższe pokazują, że możesz być całkiem blisko:

template <class X>
Variable<typename std::remove_reference<X>::type> MakeVariable(X&& x)
{
    // remove reference required for the case that x is an lvalue
    return Variable<typename std::remove_reference<X>::type>(std::forward(x));
}

void test()
{
    auto v = MakeVariable(2); // v is of type Variable<int>
}

Masz rację, kompilator mógł z łatwością odgadnąć, ale o ile wiem, nie ma go w standardzie ani w C ++ 0x, więc będziesz musiał poczekać co najmniej 10 lat (stała szybkość zmian według standardów ISO), zanim dostawcy kompilatorów dodają tę funkcję

Przyjrzyjmy się problemowi w odniesieniu do klasy, którą każdy powinien znać - std :: vector.

Po pierwsze, bardzo częstym zastosowaniem wektora jest użycie konstruktora, który nie przyjmuje parametrów:

vector <int> v;

W tym przypadku oczywiście nie można wnioskować.

Drugim powszechnym zastosowaniem jest utworzenie wektora o ustalonej wielkości:

vector <string> v(100);

Tutaj, jeśli zastosowano wnioskowanie:

vector v(100);

otrzymujemy wektor int, a nie stringów, i przypuszczalnie nie ma rozmiaru!

Na koniec rozważ konstruktory, które pobierają wiele parametrów - z „wnioskiem”:

vector v( 100, foobar() );      // foobar is some class

Którego parametru należy użyć do wnioskowania? Musielibyśmy w jakiś sposób powiedzieć kompilatorowi, że powinien to być ten drugi.

Biorąc pod uwagę wszystkie te problemy dla klasy tak prostej jak wektor, łatwo zrozumieć, dlaczego nie używa się wnioskowania.

Uczynienie z ctora szablonu Zmienna może mieć tylko jedną formę, ale różne ctory:

class Variable {
      obj data; // let the compiler guess
      public:
      template<typename obj>
      Variable(obj d)
       {
           data = d;
       }
};

int main()
{
    int num = 2;
    Variable var(num);  // Variable::data int?

    float num2 = 2.0f;
    Variable var2(num2);  // Variable::data float?
    return 0;         
}

Widzieć? Nie możemy mieć wielu członków Variable :: data.

Aby uzyskać więcej informacji na ten temat, zobacz The C ++ Template Argument Deduction .