Abhängige Typen: Vorlagenargumentabzug fehlgeschlagen

8

In meinem Code verwende ich eine Template-Bildklasse Image<T> in Kombination mit std::shared_ptr . Diese Bildzeiger sollen an verschiedene Bildverarbeitungsfunktionen übergeben werden, von denen einige unabhängig vom Bildtyp sind. Betrachten Sie die folgende Definition von Image<T> und zwei Verarbeitungsfunktionen function1() und function2() .

%Vor%

Während function1() und function2() effektiv die gleiche Signatur haben, ist function1() einfacher zu lesen und verbirgt die Details, wie der Zeiger realisiert wird. Ich habe jedoch Probleme, function1() aufzurufen, ohne den Vorlagentyp explizit anzugeben. Betrachten Sie den folgenden Code:

%Vor%

Wo der erste Aufruf zum Kompilierungsfehler führt:

%Vor%

Meine Frage lautet wie folgt: Ist es möglich, die Signatur von function1() zu verwenden, ohne das Vorlagenargument manuell angeben zu müssen? Was verursacht den Compilerfehler?

Ich vermute, dass das Problem durch die Tatsache verursacht wird, dass Image<T>::Ptr ein abhängiger Typ ist. Daher kann der Compiler die genaue Definition dieses Felds zur Kompilierungszeit nicht kennen. Ist es möglich, dem Compiler mitzuteilen, dass dieses Feld im Sinne des Schlüsselworts typename , das dem Compiler erklärt, dass ein Feld ein Typ ist, keine Spezialisierungen dieses Feldes enthält?

    
crazypeter 21.07.2015, 13:49
quelle

1 Antwort

7
  

Was verursacht den Compilerfehler?

Sie verwenden (ausschließlich) T in einem nicht-abgeleiteten Kontext: nested-name-specifier s. Das heißt, Sie setzen T in einen Namen, der lediglich angibt, wo der Typ liegt. Der Compiler kann Ihre tatsächliche Absicht nicht verstehen und müsste viele T s ausprobieren.

  

Ist es möglich, die Signatur von function1() zu verwenden, ohne das Vorlagenargument manuell angeben zu müssen?

Nicht wirklich. Wenn Sie einen präziseren Verweis auf einen Smart-Zeiger auf ein Image wünschen, können Sie dennoch eine Alias-Vorlage verwenden:

%Vor%

Und schreibe function1 soly:

%Vor%     
Columbo 21.07.2015, 13:56
quelle