Czy poleganie na niejawnej konwersji argumentów jest uważane za niebezpieczne?

C ++ ma funkcję (nie potrafię ustalić jej właściwej nazwy), która automatycznie wywołuje pasujące konstruktory typów parametrów, jeśli typy argumentów nie są oczekiwanymi.

To bardzo prosty przykład jest to wywołanie funkcji, która spodziewa się std::stringz const char*argumentem. Kompilator automatycznie wygeneruje kod w celu wywołania odpowiedniego std::stringkonstruktora.

Zastanawiam się, czy to jest tak złe dla czytelności, jak mi się wydaje?

Oto przykład:

class Texture {
public:
    Texture(const std::string& imageFile);
};

class Renderer {
public:
    void Draw(const Texture& texture);
};

Renderer renderer;
std::string path = "foo.png";
renderer.Draw(path);

Czy to w porządku? Czy to idzie za daleko? Jeśli nie powinienem tego zrobić, czy mogę w jakiś sposób zmusić Clanga lub GCC do ostrzeżenia?

Nazywa się to konstruktorem konwertującym (lub czasem niejawnym konstruktorem lub niejawną konwersją).

Nie znam przełącznika czasu kompilacji, który ostrzega, kiedy to nastąpi, ale bardzo łatwo jest temu zapobiec; wystarczy użyć explicitsłowa kluczowego.

class Texture {
public:
    explicit Texture(const std::string& imageFile);
};

To, czy konwersja konstruktorów jest dobrym pomysłem: zależy.

Okoliczności, w których domniemana konwersja ma sens:

• Klasa jest na tyle tania, że ​​można ją skonstruować tak, aby nie obchodziło ją, czy jest skonstruowana w sposób dorozumiany.
• Niektóre klasy są pojęciowo podobne do swoich argumentów (takie jak std::stringodzwierciedlenie tego samego pojęcia, z const char *którego można niejawnie przekonwertować), więc konwersja niejawna ma sens.
• Niektóre klasy stają się o wiele bardziej nieprzyjemne w użyciu, jeśli niejawna konwersja jest wyłączona. (Pomyśl o konieczności jawnego wywoływania std :: string za każdym razem, gdy chcesz przekazać literał ciągu. Części wzmocnienia są podobne.)

Okoliczności, w których domniemana konwersja ma mniej sensu:

• Budowa jest droga (na przykład przykładowa tekstura, która wymaga załadowania i parsowania pliku graficznego).
• Klasy są koncepcyjnie bardzo odmienne od swoich argumentów. Rozważmy na przykład kontener podobny do tablicy, który przyjmuje swój argument jako argument:

    klasa FlagList
    {
        FlagList (int rozmiar_ początkowy); 
    };

    void SetFlags (const FlagList & flag_list);

    int main () {
        // Teraz to się kompiluje, nawet jeśli wcale nie jest to oczywiste
        // co robi.
        SetFlags (42);
    }

• Budowa może mieć niepożądane skutki uboczne. Na przykład AnsiStringklasa nie powinna niejawnie konstruować z a UnicodeString, ponieważ konwersja Unicode na ANSI może spowodować utratę informacji.

Dalsza lektura:

• C ++ FAQ na jawnych konstruktorów
• Google C ++ Style Guide mówi prawie zawsze używać jawnych konstruktorów.
• To pytanie StackOverflow dotyczy więcej zalet i wad.

To jest bardziej komentarz niż odpowiedź, ale zbyt duży, aby można go było wstawić.

Co ciekawe, g++nie pozwala mi tego zrobić:

#include <iostream>
#include <string>

class Texture {
        public:
                Texture(const std::string& imageFile)
                {
                        std::cout << "Texture()" << std::endl;
                }
};

class Renderer {
        public:
                void Draw(const Texture& texture)
                {
                        std::cout << "Renderer.Draw()" << std::endl;
                }
};

int main(int argc, char* argv[])
{
        Renderer renderer;
        renderer.Draw("foo.png");

        return 0;
}

Wytwarza następujące:

$ g++ -o Conversion.exe Conversion.cpp 
Conversion.cpp: In function ‘int main(int, char**)’:
Conversion.cpp:23:25: error: no matching function for call to ‘Renderer::Draw(const char [8])’
Conversion.cpp:14:8: note: candidate is: void Renderer::Draw(const Texture&)

Jeśli jednak zmienię wiersz na:

   renderer.Draw(std::string("foo.png"));

Dokonuje tej konwersji.

Nazywa się to konwersją typu niejawnego. Ogólnie rzecz biorąc, jest to dobra rzecz, ponieważ hamuje niepotrzebne powtarzanie. Na przykład automatycznie otrzymujesz std::stringwersję Drawbez konieczności pisania dla niej dodatkowego kodu. Może również pomóc w przestrzeganiu zasady otwartego zamknięcia, ponieważ pozwala rozszerzyć Renderermożliwości bez modyfikacji Renderer.

Z drugiej strony nie jest to pozbawione wad. Może z jednej strony utrudnić ustalenie, skąd pochodzi argument. Czasami może przynieść nieoczekiwane wyniki w innych przypadkach. Po to explicitjest słowo kluczowe. Jeśli umieścisz go w Texturekonstruktorze, spowoduje to wyłączenie tego konstruktora do niejawnej konwersji typu. Nie znam metody globalnego ostrzegania przed niejawną konwersją typów, ale to nie znaczy, że metoda nie istnieje, tylko że gcc ma niezrozumiale dużą liczbę opcji.