2010-11-06 5 views
12

Betrachten wir die Klasse foo mit zwei Konstrukteuren wie folgt definiert:Warum gibt es eine implizite Typkonvertierung von Zeigern nach bool in C++?

class foo 
{ 
public: 
    foo(const std::string& filename) {std::cout << "ctor 1" << std::endl;} 
    foo(const bool some_flag = false) {std::cout << "ctor 2" << std::endl;} 
}; 

die Klasse mit einem String-Literal instanziiert, und erraten, welche Konstruktor aufgerufen wird?

foo a ("/path/to/file"); 

Ausgang:

Ctor 2

Ich weiß nicht, über Sie, aber ich finde nicht, dass das intuitive Verhalten in der Programmierung der Geschichte. Ich wette, es gibt einen klugen Grund dafür, und ich würde gerne wissen, was das sein könnte?

+2

möglich Duplikat von [Warum wählt der Compiler bool over string für die implizite Typumwandlung von L ""?] (Http://stackoverflow.com/questions/316181/why-does-the-compiler-choose-bool-over -string-for-implicitype -cast-of-l) – Hasturkun

+2

Noch eine ähnliche Frage: [Funktion/Methode Überladung C++: Datentyp Verwirrung?] (http://stackoverflow.com/questions/1636181/function-method-overloading- c-data-type-confusion) – Athari

+0

Entschuldigung. Ich habe gesucht (da ich dachte, dass es eine FAQ wäre), aber ich habe keine Fragen mit einem Titel gefunden, der andeutete, dass die Frage so war. – Oystein

Antwort

9

Es ist sehr üblich in C diese

void f(T* ptr) { 
    if (ptr) { 
     // ptr is not NULL 
    } 
} 

Sie schreiben sollte einen const char* Konstruktor machen.

+7

Sicher meinst du 'if (! Ptr) return;'? :) Wir möchten nicht, dass unsere gesamte Funktion mehr als nötig in Blöcke eingebettet wird. – GManNickG

+3

@GMan: Ich musste diese Art von Return-Statement eigentlich * verteidigen *, weil die Mächte, die entschieden haben, dass mehrere Return-Statements von Natur aus verwirrend und schwer zu befolgen waren, und diesen Glauben an die Coding-Standards festschrieben. – Cascabel

+2

Ich würde dies aufheben, wenn es nicht einen 'char *' Parameter empfehlen würde:/ –

1

Sie verwechseln zwei Probleme. Eine davon ist, dass "blah" implizit in eine string konvertiert werden kann und die andere ist, dass implizit in einen booleschen Wert konvertiert werden kann. Es ist sehr logisch zu sehen, dass der Compiler zur impliziten Konvertierung übergeht, was die Gesamtanzahl der erforderlichen Konvertierungen minimiert.

+0

Ich gab nur ein Beispiel, von dem ich dachte, dass es üblich wäre, darauf zu stoßen - meine Frage war _why_ die implizite Typumwandlung in 'bool' geschieht mit Zeigern. – Oystein

2

Sie übergeben ein char * an den foo-Konstruktor. Dies kann implizit in einen booleschen (wie alle Zeiger) oder in einen std :: string konvertiert werden. Aus Sicht des Compilers ist die erste Konvertierung "näher" als die zweite, da sie Standardkonvertierungen (d. H. Zeiger auf bool) gegenüber vom Benutzer bereitgestellten Konvertierungen (der Konstruktor std :: string (char *)) begünstigt.

Verwandte Themen