Чи покладається на неявне перетворення аргументів небезпечним?

У C ++ є функція (я не можу визначити її належну назву), яка автоматично викликає відповідні конструктори типів параметрів, якщо типи аргументів не є очікуваними.

Дуже простий приклад цього виклику функції, яка чекає на std::stringз const char*аргументом. Компілятор автоматично генерує код для виклику відповідного std::stringконструктора.

Мені цікаво, чи це так погано для читабельності, як я думаю, що це?

Ось приклад:

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);

Це просто добре? Або це заходить занадто далеко? Якщо я не повинен цього робити, чи можу я якось змусити Кланг або GCC попередити про це?

Це називається конструктором, що перетворюється (або іноді неявний конструктор або неявне перетворення).

Мені невідомий перемикач часу компіляції, щоб попереджати, коли це відбувається, але це дуже легко запобігти; просто використовуйте explicitключове слово.

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

Що стосується того, чи є хороша ідея перетворення конструкторів: Це залежить.

Обставини, в яких неявна конверсія має сенс:

• Клас досить дешевий, щоб побудувати, що вам все одно, якщо він неявно побудований.
• Деякі класи концептуально схожі на свої аргументи (наприклад, що std::stringвідображають те саме поняття, яке const char *воно може неявно перетворити), тому неявна конверсія має сенс.
• Деякі класи стають набагато неприємнішими для використання, якщо неявна конверсія вимкнена. (Подумайте про необхідність явно викликати std :: string кожного разу, коли ви хочете передати рядковий літерал. Частини Boost схожі.)

Обставини, при яких неявна конверсія має менше сенсу:

• Будівництво дороге (наприклад, ваш приклад "Текстура", який вимагає завантаження та розбору графічного файлу).
• Заняття концептуально дуже відрізняються від своїх аргументів. Розглянемо, наприклад, контейнер, схожий на масив, який приймає його розмір як аргумент:

    клас FlagList
    {
        FlagList (int Initial_size); 
    };

    недійсні SetFlags (const FlagList & flag_list);

    int main () {
        // Тепер це компілюється, хоча це зовсім не очевидно
        // що робить.
        SetFlags (42);
    }

• Будівництво може мати небажані побічні ефекти. Наприклад, AnsiStringклас не повинен неявно будувати з а UnicodeString, оскільки перетворення Unicode в ANSI може втратити інформацію.

Подальше читання:

• ++ FAQ C явних конструкторах
• Керівництво Стилю Google C ++ говорить майже завжди використати наявні конструктор.
• Це питання StackOverflow вказує на більше плюсів і мінусів.

Це скоріше коментар, ніж відповідь, але занадто великий, щоб ставити коментар.

Цікаво, g++що мені це не дозволяють:

#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;
}

Випускає наступне:

$ 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&)

Однак якщо я зміню рядок на:

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

Він виконає конверсію.

Це називається неявною конверсією типу. Взагалі це добре, оскільки гальмує непотрібне повторення. Наприклад, ви автоматично отримуєте std::stringверсію Drawбез необхідності писати додатковий код для неї. Це також може допомогти в дотриманні принципу відкритого закриття, оскільки дозволяє розширити Rendererможливості, не змінюючи Rendererсебе.

З іншого боку, це не позбавлено недоліків. З одного боку, це може ускладнити з'ясування, звідки беруться аргументи. Іноді це може призвести до несподіваних результатів в інших випадках. Ось для чого це explicitключове слово. Якщо ви помістите його на Textureконструктор, він відключить використання цього конструктора для неявного перетворення типу. Мені невідомий метод глобального попередження про неявне перетворення типів, але це не означає, що метод не існує, лише те, що gcc має незрозуміло велику кількість варіантів.