10 причин почему программист на С++ может выбить много денег

gcc с O3 и lto, в принципе, встраивает некоторые виртуальные вызовы.

Если встроит(inline) метод, то, вызов _этого_ метода, видимо, будет быстрее. Нужно только добавить проверку того, что метод не был заменен на другой. Если не встроит, то вызов, по идее, должен получаться медленнее, из-за бОльшего количества indirection-ов. Вызовы перегруженных методов соответственно тоже не будут быстрыми.

И делает это гораздо лучше, чем в случае ручных указателей на функции.

Сам вызов по «ручному» указателю должен бы быть быстрее, чем через vtable. Насчет инлайнинга, в случае с «ручными» указателями, трудно сказать. Вроде бы возможен.

Если не встроит, то вызов, по идее, должен получаться медленнее, из-за бОльшего количества indirection-ов.

Омг, аж на один indirection больше. Вы так уверены, что это окажет больший эффект, нежели необходимость каждый раз вытаскивать vtable конкретного объекта в кеш?

необходимость каждый раз вытаскивать vtable конкретного объекта в кеш?

Какой такой vtable?

Кто-то что-то не правильно распарсил.

Сам вызов по «ручному» указателю должен бы быть быстрее, чем через vtable. Насчет инлайнинга, в случае с «ручными» указателями, трудно сказать. Вроде бы возможен.

За вызов по ручному или виртуальному плюсовому ничего сказать не могу. Но вызов функции по указателю очень быстро работает. У интеля все мат функции реализованы через диспетчер, который выбирает исходя из cpuid при первом вызове. Ассемблер мне таки пришлось почитать ;)

Сам вызов по «ручному» указателю должен бы быть быстрее, чем через vtable.

С чего вдруг? У нас есть указатель на vtbl в объекте и есть известное значение смещения. Соответственно, никакого дополнительного уровня косвенности тут нет.

Ну я так понял, что у тебя есть вот такая кучка функций (фактически, vtable):

struct ISomething {
    void (*foo)(void*, int);
    bool (*bar)(void*, float);
};

struct A {
    struct ISomething something_methods;
    // ...
};

// ...

struct A *obj = make_A();
obj->something_methods.foo(obj, 100);

struct A {
    struct ISomething* something_methods;
    // ...
};

У нас есть указатель на vtbl в объекте и есть известное значение смещения.

object->vtbl+offset->method()

vs

object->method()

Я, пользуясь терминами статьи на lwn.net, говорю про «Directly embedded function pointers». Под «ручными» указателями вроде бы это подразумевается в дискуссии.

есть вот такая кучка функций (фактически, vtable)

Не, никакой кучки. «Directly embedded function pointers». См. ответ выше.

object->method()

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

На практике структурку с методами выделяют или совсем в отдельную сущность(которая будет передаваться в функции отдельным параметром - получаем «одноуровневый» ad-hoc полиморфизм, чем-то похожий на тайпклассы Haskell, но без контроля со стороны компилятора) или делают точно такой же указатель на vtbl/«объект-класс».

У тебя будет каша из методов и полей в каждом объекте.

Никакой каши.

struct object {
// Data
 data1_t data1;
 data2_t data2;
// Methods
 method1_ret_t (*function1)();
 method2_ret_t (*function2)();
};

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

Каждый объект будет содержать только указатели на те методы, которые ты собираешься перезагружать. Соответственно в каждом экземпляре класса(структуре) могут быть указатели на разные методы(функции). Если метод общий для всех экземпляров класса, делается обычная функция, аргументом в которую указатель на структуру(объект).

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

Каждый объект будет содержать только указатели на те методы, которые ты собираешься перезагружать.

Нет. Он должен будет содержать все.

Все коротко, ясно и понятно.

Создай 100500 объектов и получи 100500 лишних наборов дублирующих друг друга указателей.

Это может быть полезно(например, если у тебя объекты(а не классы) часто меняют свои методы на лету). Но это плохое решение в большинстве случаев.

Если метод общий для всех экземпляров класса, делается обычная функция, аргументом в которую указатель на структуру(объект).

Ты запутался, как мне кажется. Давай на примере. Покажи, как ты будешь представлять аналог:

class A
{
public:
    explicit A(int x)
        : m_x(x)
    {
    }

    int foo()
    {
        return m_x;
    }

    virtual int f()
    {
        puts("A::f");
        return m_x;
    }

    virtual int g()
    {
        puts("A::g");
        return m_x;
    }

    virtual int h()
    {
        puts("A::h");
        return m_x;
    }

private:
    int m_x;
};

class B : public A
{
public:
    B(int x, int y)
        : A(x),
          m_y(y)
    {
    }

    virtual int f()
    {
        puts("B::f");
        return A::f() + m_y;
    }

    virtual int g()
    {
        puts("B::g");
        return m_y;
    }

    virtual int h()
    {
        puts("B::h");
        return m_y;
    }

private:
    int m_y;
};

Нет. Он должен будет содержать все.

Обоснуй. Зачем применять object->init(object) вместо init_object(object), если init у всех объектов одинаковый?

Но это плохое решение в большинстве случаев.

Мы здесь вроде не о простоте реализации.

И это... ОО головного мозга не всегда хорошо работает в программировании.

Обоснуй. Зачем применять object->init(object) вместо init_object(object), если init у всех объектов одинаковый?

ОМГ. Вы вообще понимаете, что такое позднее связывание? У вас может быть 100500 объектов с одним foo и еще 100500 с другим. При этом остальные функции, например, у них будут совпадать полностью.

Т.е.

int f(my_object_t *obj)
{
    obj->foo(obj);
    obj->bar(obj);
}

Должен работать с объектами обоих видов(«классов»)

Ты запутался, как мне кажется.

Возможно, очень мало спал.

Давай на примере. Покажи, как ты будешь представлять аналог:

Я не использую C++, с синтаксисом, семантикой и используемой терминологией знаком слабо. ОО-шные «кунштюки» почти не использую, только по необходимости.

И это... ОО головного мозга не всегда хорошо работает в программировании.

Мы тут о поздних связываниях и ad-hoc полиморфизмах, если что.

Не хотите ООП, давайте возьмем что-то вроде тайпклассов Haskell.

Делается это обычно как-то так:

/* typeclass */
typedef struct my_typeclass {
    int (*foo)(void *);
    int (*bar)(void *, int x);
} my_typeclass_t;
 
/* some function */
/* require typeclass */
int
some_fun(my_typeclass_t * instance, void * v1, void * v2)
{
    return instance->foo(v1) + instance->foo(v2);
}
 
/* some type 1 */
typedef struct my_type1 {
    int x;
} my_type1_t;
 
/* some type 2 */
typedef struct my_type2 {
    int y;
} my_type2_t;
 
/* instance of my_typeclass by type1 */
int
type1_foo(void *self)
{
    return ((my_type1_t*)self)->x;
}
 
int
type1_bar(void *self, int x)
{
    return ((my_type1_t*)self)->x + x;
}
 
static my_typeclass_t my_type1_instance_my_typeclass = {
    &type1_foo,
    &type1_bar
};
 
/* instance of my_typeclass by type2 */
int
type2_foo(void *self)
{
    return ((my_type2_t*)self)->y * 2;
}
 
int
type2_bar(void *self, int x)
{
    return ((my_type2_t*)self)->y * x;
}
 
static my_typeclass_t my_type2_instance_my_typeclass = {
    &type2_foo,
    &type2_bar
};
 
int
main()
{
    my_type1_t v1, v2;
    v1.x = 10;
    v2.x = 100;
 
    some_fun(&my_type1_instance_my_typeclass, &v1, &v2);
}

У вас может быть 100500 объектов с одним foo и еще 100500 с другим. При этом остальные функции, например, у них будут совпадать полностью.

Ну и? Те, которые совпадают - object_foo(obj), те которые разные obj->bar(obj). Перезагрузка: obj->bar = &other_bar_function;

Я это уже писал, или анон читает только последний пост?

Неплохо так. Примерно так и делаю, кстати. Хотя Haskell не знаю=)

Мы тут о поздних связываниях и ad-hoc полиморфизмах, если что.

Ага. Но все началось с вот этого вброса. Мне кажется что свою точку зрения я отстоял.

Не хотите ООП, давайте возьмем что-то вроде тайпклассов Haskell.

Извини, анон, но с Haskell-ем я тоже не знаком, а про тайпклассы слышу и вовсе впервые.

И еще предпочитаю не дискутировать на темы в которых я совсем некомпетентен.

Мне кажется что свою точку зрения я отстоял.

Тебе кажется. Ибо ты показал не позднее связывание по типу объекта, а обычный вызов функции по указателю. Твой вариант отличается от «классического» тем, что ты в объектах хранишь методы. А это, во-первых, оверхед по памяти, во-вторых ставит крест на «расширении» объекта(т.е. делает почти невозможным наследование, как классовое, так и прототипное), в третьих не компенсирует это гибкостью(которую мы наблюдаем с «тайпклассами»). И все это потому, что ты, действительно, мало знаешь.

И еще предпочитаю не дискутировать на темы в которых я совсем некомпетентен.

Но уже начал. Там вроде простой сишных код. Структурка с указателями на функции выделяется в отдельный тип. А дальше мы можем заполнять такую структурку(или даже несколько) для своего типа.

что ты, действительно, мало знаешь.

Да, мало. Чем дольше живу, тем больше это понимаю.

Но уже начал. Там вроде простой сишных код.

Скажу тебе честно, анон, я просто «съезжаю». Мне же нужно и в RL кодить. Отвлекает все это.