Можно ли в C++ перезагрузить оператор уже существующего класса?

Question

[Никита]

Например:

///////////////////
//////////////////
std::vector<int> a = {9, 8, 7};
std::vector<int> b = {1, 3, 4};
std::vector<int> c = a + b;
for (int i = 0; i < c.size(); i = i + 1) {
    std::cout << c[i] << " ";
}
//10 11 11//

Answer 1

[Армянское Радио]

В описанном вами случае - можно, написав внешнюю функцию суммирования.

std::vector<int> operator + (std::vector<int> a, const  std::vector<int>& b)
{
    if(a.size()!=b.size())
    {
        throw std::range_error("sizes mismatch!");
    }
    for(size_t i=0;i!=a.size();++i)
    {
         a[i]+=b[i];
    } 
    return a;
}

Comments

[Wataru]

Простите за nitpicking, на я бы завел вектор для ответа и возвращал его. Не помню, параметры функции подвергаются ли RVO? По-моему, нет.

В любом случае, такой вариант будет быстрее, ибо тут нет лишнего копирования данных одного вектора:

std::vector<int> operator + (const std::vector<int> &a, const std::vector<int> &b)
{
    if(a.size()!=b.size())
    {
        throw std::range_error("sizes mismatch!");
    }
    vector<int> result;
    result.reserve(a.size());
    for(size_t i=0; i < a.size(); ++i)
    {
         result.push_back(a[i] + b[i]);
    } 
    return result;
}

[Армянское Радио]

Wataru,

Копирования вектора лишний раз не будет, будет перемещение. Так что произойдет три new и три delete (см дизасм).

Что касается того, что быстрее, сначала скопировать, потом суммировать, или просто суммировать, здесь тоже есть нюанс - если данные сначала скопировать, их локальность будет выше при последующем суммировании.

(По крайней мере, мой вариант порождает более короткий выхлоп в машинном коде)

[Армянское Радио]

Более того, использование push_back создает для компилятора две интересные беды (см. бенч)
1) На каждый push_back он будет вынужден делать проверку, а не кончилось ли место в векторе.
2) Будет труднее применить оптимизацию при помощи векторных инструкций процессора.



Желтый столбик - это вариант с push_back и он очень сильно болен
Синий столбик - это ваш исправленный вариант, в котором убран push_back
Розовый - мой вариант, как в ответе.

[Wataru]

Армянское Радио, Да, фигню я сморозил - про push_back не подумал.

[Армянское Радио]

Wataru, после починки push_back вариант без result все равно оказывается чуточку быстрее, несмотря на, казалось бы, лишнее копирование - за счет лучшей локальности данных, как я понимаю.

Впрочем, это уже сильно зависит от того, что хранится в векторе.

[Wataru]

Армянское Радио, Не, ну без push_back там инициализация нулями, которая не быстрее копирования будет.
Правда почему оно на 10% медленнее вашего варианта - я пока не понимаю.

[Армянское Радио]

Wataru, resize() не делает никакой инициализации в данном случае. В листинге это видно в том числе.

[Wataru]

Армянское Радио, Как же не делает никакой инициализации? Он же конструктор по умолчанию вызывает. Ах, да, вот почему оно, похоже, медленее. Если оптимизация не догадывается сделать memset с 0, то это точно будет медленее memcpy который происходит в вашем варианте.

В листинге это видно в том числе

В каком?

[Армянское Радио]

Wataru, Вот тут.

Там действительно есть вызов memset, но это какая-то гадость - если делать ресайз, будет делаться это зануление бестолковое, а если не делать ресайз, будет трудно воспользоваться векторизацией.

[Евгений Шатунов]

Армянское Радио, я тоже залезу со своим советом. :)
Общая форма внешней перегрузки оператора сложения выглядит как T operator+(const T &a, const T2 &b);.
Принимает две константные ссылки и возвращает значение. Нарушать эту форму трансляторы позволяют, но читатели такого кода в восторге не будут, особенно от содержимого оператора.

Семантическая прозрачность кода - это то, чему надо учиться с самого начала и учить с самого начала других. В этом плане я бы рекомендовал прививать студенту навык писать код исключительно в рамках стандарта.

std::vector<int> operator + ( const std::vector<int>& left, const std::vector<int>& right )
{
    if( left.size() != right.size() )
    {
        throw std::range_error("sizes mismatch!");
    }

    std::vector<int> result{ left };
    for( size_t index = 0; index < right.size(); ++index )
    {
         result[ index ] += right[ index ];
    } 
    return result;
}

Суть не поменялась, скорость тоже. А понятность - в разы выросла. Вопросов меньше, а удобства чтения - больше.

[Армянское Радио]

Евгений Шатунов, К сожалению, GCC настолько глуп, что не может ваш вариант оптимизировать и заинлайнить (мой - может)

[Евгений Шатунов]

Армянское Радио, а clang 12 при всех ухищрениях не может заинлайнить твой вариант. Как быть? :)
Мой инлайнится без труда.

[Армянское Радио]

Евгений Шатунов, остается только пожелать разработчикам стандарта и компиляторов дальнейших творческих успехов.

P.S. И выдать медаль в виде чугунного люка изоборетателю std::numeric_limits::min() - за самую неинтуитивную и веселую подставу от C++ в моей личной истории:

For floating-point types with denormalization, min returns the minimum positive normalized value. Note that this behavior may be unexpected, especially when compared to the behavior of min for integral types. To find the value that has no values less than it, use numeric_limits::lowest.

[Евгений Шатунов]

Армянское Радио, на деле, в своем коде я стараюсь придерживаться именно стандарта. GCC много раз был уличен в вольности трактовок правил стандарта. Поэтому я исключил его из поддержки своими продуктами еще в 2016 году. NDK у Android пошли тем же путем. Потом GCC уже исправился и убрал свои вольности, но "осадочек", как говорится, остался.
Я это не к тому что GCC плохо и его надо сжечь. Я к тому, что лучше свой код выражать всегда в терминах стандарта просто потому что с каждым годом трансляторы все больше и больше следуют именно ему, отказываясь от своих вольных трактовок. Даже cl от майков идет этой дорогой.
Статься может так, что завтра твой вариант инлайниться перестанет и на GCC тоже, а мой - начнет.

По поводу std::numeric_limits::min() можно сказать только то, что FLT_MIN даже в C означает ровно то же самое.

[Мирон]

стандарт хорошо, а вот внедрение сверки размеров до выполнения инструкции "call" лучше

[Армянское Радио]

Мирон, сверка размеров в релизе подлежит отключению - незачем отапливать атмосферу.

[Мирон]

Армянское Радио,
you didn't read right
if( left.size() != right.size() )
{
throw std::range_error("sizes mismatch!");
}
will remain, but its intent, really, is to be performed before "call", not after.
These checks should be part of a contract, not execution steps inside function body.
Point is, innovations running ahead of "standards" are needed. Whoever gets those right drives standard forward.