Я работаю над проектом, который должен иметь универсальную оболочку C ++ для библиотек большого числа и, если библиотека предоставляет функции в стиле C, например:
//assignment
lib_set(lib_type data, lib_type input);
lib_set_si(lib_type data, long input);
lib_set_ui(lib_type data, unsigned long input);
//addition
lib_add(lib_type data, lib_type input);
lib_add_ui(lib_type data, unsigned long input);
Чтобы избежать создания временных объектов, когда в этом нет особой необходимости, я получил что-то вроде этого:
class wrapper
{
private:
lib_type data;
public:
wrapper()
{
lib_set_ui(this->data, 0UL);
}
wrapper (const wrapper &input)
{
lib_set(this->data, input.data);
}
wrapper (const long input)
{
lib_set_si(this->data, input);
}
wrapper (const unsigned long input)
{
lib_set_ui(this->data, input);
}
wrapper &operator+= (const wrapper &input)
{
lib_add(this->data, input.data);
return *this;
}
wrapper &operator+= (const unsigned long input)
{
lib_add_ui(this->data, input);
return *this;
}
};
К сожалению, если я сделаю это:
wrapper x(2);
x += -2;
компилятор (GCC / VS2010) даже не выдаст предупреждение о том, что я пытаюсь int
в unsigned long
неявно, и это определенно не то, что я хочу получить …
Итак, в этом случае, как бы я перегружать операторы для wrapper
класс, такой, что мне не нужно создавать временный wrapper
объект, когда он не нужен? Если я удалю wrapper &operator+= (const unsigned long input)
перегрузка, тогда я должен был бы использовать что-то вроде этого:
wrapper x(2);
x += wrapper(-2);
x += -2;//implicitly casts -2 to wrapper
но я не думаю, что могу положиться на тот факт, что компилятор может оптимизировать лишний объект …
Я не знаю, как отключить неявное преобразование, как вы описываете. Однако вы можете, по крайней мере, заставить компилятор выдавать предупреждение об этом.
Если вы используете GNU Mingw / GCC, просто передайте -Wconversion
а также -Wsign-conversion
при компиляции. Вы должны получить предупреждение сейчас по вышеуказанному коду.
Для MSVC, /Wall
или же /W4
должен получить вам то же самое.
Других решений пока нет …