Избыточное копирование объекта при реализации оператора умножения и оператора присваивания

Evg · Регистрация: 30.03.2009

Студворк — интернет-сервис помощи студентам

Есть класс работы с матрицами. Есть операция умножения матриц, описанная как оператор класса. В данном коротком примере я просто моделирую ситуацию. Реальное наполнение класса принципиальной разницы не играет, нужно просто понимать, что оператор умножения будет иметь большой код, оператор присваивания в реализации тоже будет не пустым. Эти места в примере засвечены комментариями

C++
#include <cstdio>
 
class Matrix
{
  private:
    // внутренние данные матрицы
 
  public:
    Matrix ();
    Matrix (const Matrix&);
    ~Matrix ();
 
    Matrix& operator=(const Matrix& a);
    Matrix operator*(const Matrix& a) const;
};
 
Matrix::Matrix ()
{
  printf ("Matrix ()\n");
};
 
Matrix::Matrix (const Matrix&)
{
  printf ("Matrix (const Matrix&)\n");
};
 
Matrix::~Matrix ()
{
  printf ("~Matrix ()\n");
};
 
Matrix& Matrix::operator=(const Matrix& a)
{
  printf ("operator=(const Matrix&)\n");
 
  // тут как бы код, копирущий данные из "a" в "this"
 
  return *this;
}
 
Matrix Matrix::operator*(const Matrix& a) const
{
  printf ("operator*(const Matrix&)\n");
 
  Matrix result;
 
  // тут как бы код, умножающий "a" и "this" и записывающий
  // данные в "result"
 
  return result;
}
 
Matrix a, b, c;
 
int main (void)
{
  printf ("------------------\n");
  a = b * c;
  printf ("------------------\n");
}

Исполнение:

Code
$ g++-4.8 t.cc
$ ./a.out
Matrix ()
Matrix ()
Matrix ()
------------------
operator*(const Matrix&)
Matrix ()
operator=(const Matrix&)
~Matrix ()
------------------
~Matrix ()
~Matrix ()
~Matrix ()

Нас интересует только фрагмент печати внутри функции main (т.е. между палками)

Посмотрим на ассемблерный код. Компилирую с опцией -fno-inline, чтобы оставаться с короткой программой и не разводить геморрой по борьбе с inline'ом со стороны компилятора. В общем случае тела операторов класса Matrix будут в отдельном файле и НЕ будут доступны для inline'а. Опцию -fno-exceptions подаю, чтобы было меньше мусора в коде

Code
$ g++ t.cc -O2 -fno-inline -fno-exceptions
$ cat t.s
...
    leal    -9(%ebp), %ebx
    subl    $32, %esp
    movl    %ebx, (%esp)
    movl    $c, 8(%esp)
    movl    $b, 4(%esp)
    call    _ZN6MatrixmlERKS_  <- operator*
 
    subl    $4, %esp
    movl    %ebx, 4(%esp)
    movl    $a, (%esp)
    call    _ZN6MatrixaSERKS_  <- operator=
...

Таким образом мы видим, что построился код, схематично эквивалентный следующему примеру на Си. На всякий случай напоминаю, что с точки зрения семантики C++ выражение "a = b * c" трактуется как "a.operator= (b.operator* (c))"

C
typedef struct { /* внутренности */ } Matrix;
 
extern void operator_assign (Matrix *this, const Matrix *value);
extern void operator_mul (Matrix *result, const Matrix *this, const Matrix *operand2);
 
Matrix a, b, c;
 
int main (void)
{
  Matrix tmp;
 
  operator_mul (&tmp, &b, &c); /* tmp = b.operator* (c) */
  operator_assign (&a, &tmp);  /* a.operator= (tmp) */
}

Мы видим, что в этом коде делается ненужное действие в виде лишнего оператора присваивания. Для умножения матриц эффективный код на Си выглядел бы как

C
operator_mul (&a, &b, &c);

т.е. без заведения промежуточной переменной и дополнительного копирования (которое представляет собой ненужные накладные расходы)

Вопрос. Как правильно написать текст на C++, чтобы получить код, эквивалентный вышеприведённой эффективной реализации на C? Оставаясь при этом в объёме стандарта C++98. Оставляя исходник в понятном и читабельном виде, без использования извращений типа семиэтажных шаблонов и т.п.

@jdzvk · 22.03.2016, 15:02

Не по теме:

Renji, если вы используете матрицу 2x2, которая заполняется сразу("за раз"),
и таких матриц много - имеет смысл использовать соответствующую возможным значениям
матрицы строгую адресацию, соответствующую количеству матриц. причём адресацию с запасом,
позволяющим адресовать непрерывный "диапазон" одинаковых значений. одно или двумерный

@avgoor · 22.03.2016, 15:26

Evg,

Сообщение от Evg

a = a * a;

Как здесь обойтись без дополнительной памяти? Требовать, чтобы слева и справа не было одних и тех же матриц?

Evg · 22.03.2016, 15:46 **[ТС]**

Сообщение от Nosey

ничего вам не напоминает ASM vs C ?

Нет, не напоминает. Хотя бы потому, что опять-таки условные 90% тех, кто считает, что умеет программировать на ассемблере, попросту не смогут написать код перемножения матриц на ассемблере, чтобы он был быстрее, чем из-под компилятора Си

Сообщение от Nosey

Приведите примеры, желательно с тестами показывающие разницу, другого способа убедиться что С++ подход в результате не хуже я не знаю

Зачем? Делать мне больше нечего, как тебя в чём-то переубеждать? За конкретным примером далеко ходить не надо, он написан в первом посте данной темы. И пока до сих пор никто не привёл код на Си++, который бы работал столь же быстро, как и эквивалентный "эффективный" код на Си

Сообщение от Kastaneda

Вместо
a = b * c;
написать
(a = b) *= c;
понятно, что нужно реализовать *=

При таком подходе изменяется значение b. Что делает пример совсем не эквивалентным

Сообщение от avgoor

Как здесь обойтись без дополнительной памяти?

Да, тут соглашусь с претензией, она справедлива в том числе и для реализации функции operator_mul. Но для эффективной реализации мы действительно можем потребовать, чтобы dst не совпадал ни с одним из src. Я не специалист по математике, возможно, что есть алгоритмы, которые действительно требуют аккумулировать значение и работать операциями вида a *= b. Если задача требует подобных операций, то память, необходимую для вычисления произведения матриц, можно нормально выделять локально в стеке практически бесплатно (в отличие от динамической памяти, выделяемой всякими new). Хотя в таком варианте получится уже далеко не Си++ , потому что придётся работать с указателями, а не с ссылками

Во всяком случае твоя претензия помогла мне интуитивно понять, почему "стандартными средствами C++" мою постановку задачи В ОБЩЕМ СЛУЧАЕ не решить без промежуточного копирования

@avgoor · 22.03.2016, 15:55

Сообщение от Evg

Я не специалист по математике, возможно, что есть алгоритмы, которые действительно требуют аккумулировать значение и работать операциями вида a *= b. Если задача требует подобных операций, то память, необходимую для вычисления произведения матриц, можно нормально выделять локально в стеке практически бесплатно (в отличие от динамической памяти, выделяемой всякими new). Хотя в таком варианте получится уже далеко не Си++ , потому что придётся работать с указателями, а не с ссылками

Зависит много от чего. Например: размерность матрицы - это поле класса или параметр шаблона? Может это вообще разреженые матрицы итд.
В общем случае - тут тернарная операция, и реализовать ее как две бинарных - не получится.
Исходя из вышесказанного: Matrix::inplace_mul(const Matrix& l, const Matrix& r) так, наверное.

@Kastaneda · 22.03.2016, 15:56

Сообщение от Evg

При таком подходе изменяется значение b

???

C++
1
2
3
4
5
6
7
8
Matrix& Matrix::operator=(const Matrix& a)
{
  printf ("operator=(const Matrix&)\n");
 
  // тут как бы код, копирущий данные из "a" в "this"
 
  return *this;
}

operator = вернет ссылку на a, для которого уже будет вызвать *=. b тут меняться не будет.

@avgoor · 22.03.2016, 16:04

Evg, В принципе можно возвращать из operator* кортеж {Matrix*, Matrix*} и в operator=(std::tuple реализовать умножение. В общем возвращать прокси.

Evg · 22.03.2016, 16:26 **[ТС]**

Сообщение от Kastaneda

operator = вернет ссылку на a, для которого уже будет вызвать *=. b тут меняться не будет

Ну да, моск заклинило. Но лишнее присваивание a=b таки будет исполнено (перед тем, как выполнить умножение). Ибо

Сообщение от avgoor

В общем случае - тут тернарная операция, и реализовать ее как две бинарных - не получится

-----------------

Сообщение от avgoor

Исходя из вышесказанного: Matrix::inplace_mul(const Matrix& l, const Matrix& r) так, наверное.

Ну это эквивалентно примеру на Си. Т.е. уже известный вариант решения

Сообщение от avgoor

Evg, В принципе можно возвращать из operator* кортеж {Matrix*, Matrix*} и в operator=(std::tuple реализовать умножение

Но это уже C++11. Я тут не знаю, как всё это описать синтаксически, а потому не смогу себе родить исходник для анализа построенного кода. Но идею понял. Правда подозреваю, что перестанут работать выражения типа "a = b * c + d" или вызовы функций типа "foo (a * b)". Т.е. вариант с кортежами ограничивает написание кода лишь выражениями в одну операцию с обязательным qприсваиванием

@avgoor · 22.03.2016, 16:33

Сообщение от Evg

Т.е. вариант с кортежами ограничивает написание кода лишь выражениями в одну операцию с обязательным qприсваиванием

Кортеж для примера был. Имелось ввиду class MatrixMul, MatrixPlus... Дальше можно извратиться с шаблонами построить на них синтаксический парсер и надеятся, что компилятор схлопнет все это в эффективный код

@Kastaneda · 22.03.2016, 16:40

Сообщение от Evg

Но лишнее присваивание a=b таки будет исполнено (перед тем, как выполнить умножение)

Ну да, тогда извращаться.
Имхо - проще написать в С стиле, чем С++, но который без поллитры не разберешь.

@ct0r · 22.03.2016, 16:43

Nosey, а ты зачем считаешь кол-во инструкций? Типа меньше инструкций - быстрее программа?

Сообщение от Evg

вся неэффективность растёт из

сказочных ограничений (типа С++98, с ООП и тп).

Сообщение от Evg

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

Что один, что другой подход - крайности какие-то.

Сообщение от Evg

которую получается написать эффективно только в "некультурном" стиле

А что такое "некультурный стиль" в С++?

@avgoor · 22.03.2016, 16:48

ct0r, Как показывает практика, когда речь заходит о перемножении матриц - минимум тактов не крайность, а необходимость.

@Kastaneda · 22.03.2016, 16:57

Сообщение от avgoor

Как показывает практика, когда речь заходит о перемножении матриц - минимум тактов не крайность, а необходимость.

Я кэш-миссы даже считал, и префетчинг делал, чтоб их сократить. Да, если это узкое место, то приходится "вылизывать".

@avgoor · 22.03.2016, 17:01

Сообщение от Kastaneda

Я кэш-миссы даже считал, и префетчинг делал, чтоб их сократить.

Аналогично.

@ct0r · 22.03.2016, 17:05

Сообщение от avgoor

Как показывает практика, когда речь заходит о перемножении матриц - минимум тактов не крайность, а необходимость.

А причем тут практика и перемножение матриц? Там про подсознание.

@Nosey · 22.03.2016, 17:06

Сообщение от Evg

Зачем? Делать мне больше нечего, как тебя в чём-то переубеждать? За конкретным примером далеко ходить не надо, он написан в первом посте данной темы.

Потешно

А ты его запускал свой конкретный пример?
Ну ладно, открывай ротик, закладываю :

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#include "math/Math.h"
#include <iostream>
#include <vector>
 
const size_t c = 100000000;
 
ru::math::Matrix4 fcpp(const ru::math::Matrix4& mat1)
{
    ru::math::Matrix4 mat2 { 20, 30, 40 };
    return mat1 * mat2;
}
 
ru::math::Matrix4 mat1 { 10, 20, 30 };
ru::math::Matrix4 mat2 { 20, 30, 40 };
ru::math::Matrix4 mat3;
 
void fc(const ru::math::Matrix4* mat1)
{
    ru::math::Matrix4::operator_mul(&mat3, mat1, &mat2);
}
 
int main(void)
{
    std::vector<float> resVec;
    resVec.reserve(c);
    size_t i = c;
 
    clock_t startCpp = clock();
    while (--i)
    {
        resVec.push_back(fcpp(mat1).det());
    }
    clock_t endCpp = clock();
 
    std::cout << resVec.size() << " " << endCpp - startCpp << std::endl;
 
    resVec.clear();
    i = c;
 
    clock_t startC = clock();
    while (--i)
    {
        fc(&mat1);
        resVec.push_back(mat3.det());
    }
    clock_t endC = clock();
    std::cout << resVec.size() << " " << endC - startC << std::endl;
}

Реализация оператора умножения:

C++
1
2
3
4
5
6
            Matrix4 operator*(const Matrix4 &m) const
            {
                Matrix4 ret;
                operator_mul(&ret, this, &m);
                return ret;
            }

Вы только представьте сколько в Cpp реализации лишних копирований и присваиваний происходит, и все бесплатно, ах, эти новые квантовые ноутбуки.
Результаты :
99999999 3105052 - cpp
99999999 3098734 - c
И да, это расчёты честные, никаких компайлтайм расчётов нету.

Сообщение от ct0r

а ты зачем считаешь кол-во инструкций? Типа меньше инструкций - быстрее программа?

В данном случае - да, слишком уж большой разрыв для идентичных алгоритмов.
А вы считаете, что в данном случае меньшее количество инструкций хуже работают?

@ct0r · 22.03.2016, 17:16

Сообщение от Nosey

В данном случае - да, слишком уж большой разрыв для идентичных алгоритмов.
А вы считаете, что в данном случае меньшее количество инструкций хуже работают?

Да я фиг знает. Мерить надо. Я не умею считать такты с учетом конвейеров и суперскалярности, с учетом зависимостей по данным, с учетом кол-ва обращений к памяти и кол-ва промахов кэша и тд и тп. Интуиция тут не помощник. Ну если кто-то умеет, то ок.
Компилятор, когда оптимизирует, на кол-во инструкций точно не смотрит.

Evg · 22.03.2016, 17:26 **[ТС]**

Сообщение от ct0r

А что такое "некультурный стиль" в С++?

Тот, который "в стиле языка Си". Т.е. в моей терминологии при написании программы на Си++ "культурно" это

C++
a = b * c;

не "культурно"

C
operator_mul (&a, &b, &c);

При написании "культурно" (т.е. в стиле Си++) программа выглядит красиво, но работает неэффективно

Добавлено через 9 минут

Сообщение от Nosey

Ну ладно, открывай ротик, закладываю

Мне не интересно смотреть на исходник, в котором используется какой-то непонятный самопальный Math.h, о содержании которого я должен догадываться. Засовывание результатов в вектор - это, насколько я понял, борьба с оптимизациями. Но тем не менее, этот процесс входит в замер. А если получится так, что на одну итерацию цикла приходится условно 10 тактов для умножения матрицы и 1000 тактов для засовывания в вектор (т.е. доля полезной нагрузки составляет 1% от общего времени), то такой замер ни о чём. Очевидно, ты об этом не задумывался, когда писал вектор, в который нужно будет засунуть 100 миллионов экземпляров и не можешь сказать, какую долю времени всего теста занимает менеджер памяти при работе с вектором. Так что твой пример я готов рассматривать только в варианте с полным исходником. Чтобы он изначально был рабочим, чтобы я его мог переписать с симетричными подходами "c" и "cpp" и с правильным построением замера

Правда я всё равно не понимаю, что ты мне продемонстрировать этим примером хочешь. Если хочешь продемонстрировать, что ненужные копирования занимают всего 1% (2%, 3%, не суть) от времени исполнения, то мне это вовсе не интересно. Если для выполнения какой-то задачи код должен быть быстрым, то борьба идёт за каждый процент времени исполнения

@ct0r · 22.03.2016, 17:28

Evg, ну ООП в С++ тогда тоже некультурно, потому что в стиле Smalltalk. А перегрузка операторов - потому что в стиле ALGOL.

Evg · 22.03.2016, 17:29 **[ТС]**

Сообщение от avgoor

Имелось ввиду class MatrixMul, MatrixPlus... Дальше можно извратиться с шаблонами построить на них синтаксический парсер и надеятся, что компилятор схлопнет все это в эффективный код

Если рассматривать вариант с извращениями, то написание функции с тремя аргументами выглядит самым простым и эффективным решением. Я плохо знаю Си++, потому и спросил. Я думал, что можно написать реализацию матриц так, чтобы можно было писать "a = b * c" и иметь при этом эффективный код

@avgoor · 22.03.2016, 17:43

Сообщение от Evg

чтобы можно было писать "a = b * c" и иметь при этом эффективный код

...

Сообщение от avgoor

Зависит много от чего. Например: размерность матрицы - это поле класса или параметр шаблона? Может это вообще разреженые матрицы итд.

Теоретически можно.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

Evg 21281 / 8305 / 637 Регистрация: 30.03.2009 Сообщений: 22,660 Записей в блоге: 30

	Избыточное копирование объекта при реализации оператора умножения и оператора присваивания 21.03.2016, 18:43. Показов 5644. Ответов 84 Метки нет (Все метки) Есть класс работы с матрицами. Есть операция умножения матриц, описанная как оператор класса. В данном коротком примере я просто моделирую ситуацию. Реальное наполнение класса принципиальной разницы не играет, нужно просто понимать, что оператор умножения будет иметь большой код, оператор присваивания в реализации тоже будет не пустым. Эти места в примере засвечены комментариями C++ #include <cstdio> class Matrix { private: // внутренние данные матрицы public: Matrix (); Matrix (const Matrix&); ~Matrix (); Matrix& operator=(const Matrix& a); Matrix operator(const Matrix& a) const; }; Matrix::Matrix () { printf ("Matrix ()\n"); }; Matrix::Matrix (const Matrix&) { printf ("Matrix (const Matrix&)\n"); }; Matrix::~Matrix () { printf ("~Matrix ()\n"); }; Matrix& Matrix::operator=(const Matrix& a) { printf ("operator=(const Matrix&)\n"); // тут как бы код, копирущий данные из "a" в "this" return this; } Matrix Matrix::operator(const Matrix& a) const { printf ("operator(const Matrix&)\n"); Matrix result; // тут как бы код, умножающий "a" и "this" и записывающий // данные в "result" return result; } Matrix a, b, c; int main (void) { printf ("------------------\n"); a = b * c; printf ("------------------\n"); } Исполнение: Code $ g++-4.8 t.cc $ ./a.out Matrix () Matrix () Matrix () ------------------ operator(const Matrix&) Matrix () operator=(const Matrix&) ~Matrix () ------------------ ~Matrix () ~Matrix () ~Matrix () Нас интересует только фрагмент печати внутри функции main (т.е. между палками) Посмотрим на ассемблерный код. Компилирую с опцией -fno-inline, чтобы оставаться с короткой программой и не разводить геморрой по борьбе с inline'ом со стороны компилятора. В общем случае тела операторов класса Matrix будут в отдельном файле и НЕ будут доступны для inline'а. Опцию -fno-exceptions подаю, чтобы было меньше мусора в коде Code $ g++ t.cc -O2 -fno-inline -fno-exceptions $ cat t.s ... leal -9(%ebp), %ebx subl $32, %esp movl %ebx, (%esp) movl $c, 8(%esp) movl $b, 4(%esp) call _ZN6MatrixmlERKS_ <- operator subl $4, %esp movl %ebx, 4(%esp) movl $a, (%esp) call _ZN6MatrixaSERKS_ <- operator= ... Таким образом мы видим, что построился код, схематично эквивалентный следующему примеру на Си. На всякий случай напоминаю, что с точки зрения семантики C++ выражение "a = b * c" трактуется как "a.operator= (b.operator* (c))" C typedef struct { /* внутренности / } Matrix; extern void operator_assign (Matrix this, const Matrix value); extern void operator_mul (Matrix result, const Matrix this, const Matrix operand2); Matrix a, b, c; int main (void) { Matrix tmp; operator_mul (&tmp, &b, &c); /* tmp = b.operator* (c) / operator_assign (&a, &tmp); / a.operator= (tmp) */ } Мы видим, что в этом коде делается ненужное действие в виде лишнего оператора присваивания. Для умножения матриц эффективный код на Си выглядел бы как C operator_mul (&a, &b, &c); т.е. без заведения промежуточной переменной и дополнительного копирования (которое представляет собой ненужные накладные расходы) Вопрос. Как правильно написать текст на C++, чтобы получить код, эквивалентный вышеприведённой эффективной реализации на C? Оставаясь при этом в объёме стандарта C++98. Оставляя исходник в понятном и читабельном виде, без использования извращений типа семиэтажных шаблонов и т.п. 0

@jdzvk
	22.03.2016, 15:02
	Не по теме: Renji, если вы используете матрицу 2x2, которая заполняется сразу("за раз"), и таких матриц много - имеет смысл использовать соответствующую возможным значениям матрицы строгую адресацию, соответствующую количеству матриц. причём адресацию с запасом, позволяющим адресовать непрерывный "диапазон" одинаковых значений. одно или двумерный 0

@avgoor 1550 / 877 / 179 Регистрация: 05.12.2015 Сообщений: 2,555
	22.03.2016, 16:04
	Evg, В принципе можно возвращать из `operator` кортеж {Matrix, Matrix*} и в `operator=(std::tuple` реализовать умножение. В общем возвращать прокси. 0

@avgoor 1550 / 877 / 179 Регистрация: 05.12.2015 Сообщений: 2,555
	22.03.2016, 16:48
	ct0r, Как показывает практика, когда речь заходит о перемножении матриц - минимум тактов не крайность, а необходимость. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	22.03.2016, 17:28
	Evg, ну ООП в С++ тогда тоже некультурно, потому что в стиле Smalltalk. А перегрузка операторов - потому что в стиле ALGOL. 0