@hirthwork

Тег ООП в блоге hirthwork

hirthwork
12 Sep 2013
hirthwork

Полиморфизм, виртуальные функции, всё это сосёт. Глубоко и печально.
Представим, казалось бы обычный double-dispatch в тырпрайз коде:

// 3rd party library
struct processor {
    // returns number of processed bytes
    virtual size_t process(void* buf, size_t len) = 0;
};

struct file_processor: processor {
    // provides more effective processing routine
    virtual size_t process(FILE* file) = 0;
};

struct data_provider {
    // returns number of bytes processed
    virtual size_t process(processor& p) = 0;
};

...
struct file_provider: data_provider {
    FILE* file;
    virtual size_t process(processor& p);
};

size_t file_provider::process(processor& p) {
    file_processor* fp = dynamic_cast<file_processor*>(&p);
    if (fp) {
        return fp->process(file);
    } else {
        char buf[1024];
        size_t read = fread(buf, 1, sizeof buf, file);
        return p.process(buf, read);
    }
}

Ок, заебца, если наш processor является file_processor'ом, то data_provider'ы
умеющие работать с файлами будут использовать более эффективный метод обработки
данных. Таких оптимизаций могут быть десятки в чужой библиотеке.
А теперь, представим, что по флажку в конфиге мы хотим включать логгирование
количества обработанных байтиков.
Хуйня-война, пишем в своём коде декоратор:

struct logging_processor: processor {
    processor* parent;

    virtual size_t process(void* buf, size_t len) {
        size_t processed = parent->process(buf, len);
        std::iostream << processed << " bytes processed" << std::endl;
        return processed;
    }
};

Отлично, цифры логгируются, вот только теперь оптимизация у file_provider'а не
работает. Выхода три:
- Переопределять все возможные комбинации наследований
- Убить себя ап стену
- Перейти на хацкель

hirthwork
08 May 2013
hirthwork

В С++ экземпляр класса имеет доступ к private и
protected членам других экземпляров этого же класса.
Зачем это сделали? Затем что очень проблематично показалось тогда делать
конструкторы копирования и операторы присваивания без этого.
Почему проблематично? Потому что RVO сделали опциональной фичей. Если бы RVO
был обязателен для функций с одним return, то конструкторы копирования и
операторы присваивания можно было бы заменить одной функцией:
my_class my_class::clone() const noexcept {
return my_class(private_member1, private_member2);
}

А так — поленились возложить на компиляторописателей одну задачу и получили
говно вместо языка программирования

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.