The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Анализ влияния ключевого слова final на производительность программ C++, opennews (??), 23-Апр-24, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


11. "Анализ влияния ключевого слова final на производительность п..."  +4 +/–
Сообщение от Аноним (11), 23-Апр-24, 14:50 
А вообще каким боком final влияет на производительность кода? Он же нужен исключительно чтобы бить по рукам, не более того.
Ответить | Правка | Наверх | Cообщить модератору

16. "Анализ влияния ключевого слова final на производительность п..."  +12 +/–
Сообщение от Аноним (16), 23-Апр-24, 15:25 
Поскольку нет наследников -> нет нужды смотреть в vtable -> можно дёргать методы напрямую, минуя виртуализаию
Ответить | Правка | Наверх | Cообщить модератору

24. "Анализ влияния ключевого слова final на производительность п..."  +1 +/–
Сообщение от Пряник (?), 23-Апр-24, 16:22 
Ты умнее Бенджамина Саммертона.
Ответить | Правка | Наверх | Cообщить модератору

55. "Анализ влияния ключевого слова final на производительность п..."  +3 +/–
Сообщение от anonymous (??), 23-Апр-24, 20:10 
Это не сложно.
Ответить | Правка | Наверх | Cообщить модератору

60. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Аноним (60), 23-Апр-24, 22:40 
Что-то я не понял твою мысль.

class base {
public:
    virtual void f() = 0;
};

class derived1 : public base {
public:
    virtual void f() {}
};

class derived2 final: public derived1 {
public:
    virtual void f() {}
};

int main()
{
    base *p = new derived2;

    p->f();  
    return 0;
}


По-твоему тут vtable не будет использоваться?

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

75. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Аноним (75), 24-Апр-24, 00:37 
Даже с MSVC не будет.
https://godbolt.org/z/aWGr639ej
Ответить | Правка | Наверх | Cообщить модератору

84. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от n00by (ok), 24-Апр-24, 08:36 
Осталось ещё убрать final и посмотреть на листинг, для полного просветления.
Ответить | Правка | Наверх | Cообщить модератору

91. "Анализ влияния ключевого слова final на производительность п..."  +1 +/–
Сообщение от Аноним (91), 24-Апр-24, 12:40 
Тот пример действительно не покажет эффект от `final`, если компилятор умеет запоминать тип присвоенного ссылке или указателю объекта, а не ограничивается типом самой ссылки или указателя. Куда лучше тут подходит https://godbolt.org/z/aPKxEWMz5
Ответить | Правка | Наверх | Cообщить модератору

102. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от n00by (ok), 25-Апр-24, 13:27 
Подходит лучше, пока нет определения функций-членов. При lto может быть проанализирован поток исполнения и разницы не окажется. Но даже если и окажется, то главный вопрос - почему вдруг с final медленнее, а не быстрее.
Ответить | Правка | Наверх | Cообщить модератору

89. "Анализ влияния ключевого слова final на производительность п..."  +2 +/–
Сообщение от siga (ok), 24-Апр-24, 12:18 
придумать такой сценарий, когда ключевое слово `final` приводит к девиртуализации вызова, в принципе несложно https://godbolt.org/z/b9d7GhjxW

а вот придумать ситуацию, когда оно сказывается негативно, уже сложнее. мне на ум пока приходит только невозможность применения EBCO https://godbolt.org/z/hE9aoc8Kc

Ответить | Правка | К родителю #60 | Наверх | Cообщить модератору

106. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от fuggy (ok), 25-Апр-24, 17:48 
Я пытался разобраться, но тут нет разницы в ассемблере между clang и gcc c final и без в первом случае. Откуда тогда разница в производительности берётся? Либо нужно более сложный кейс сравнивать.
Ответить | Правка | Наверх | Cообщить модератору

107. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от n00by (ok), 26-Апр-24, 06:50 
Мне тут другое непонятно. Автор тестов тестировал на своей библиотеке. Получил результат, вызывающий вопросы. Почему он не посмотрел асм и не нашёл ответ сам? Я в подобных случаях всегда смотрел и подчас открывал удивительные для себя вещи.
Ответить | Правка | Наверх | Cообщить модератору

81. "Анализ влияния ключевого слова final на производительность п..."  +1 +/–
Сообщение от bOOster (ok), 24-Апр-24, 08:20 
Хоть кто-то на опеннете знает как C++ работает.
Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

50. "Анализ влияния ключевого слова final на производительность п..."  –1 +/–
Сообщение от Аноним (50), 23-Апр-24, 18:42 
> Он же нужен исключительно чтобы бить по рукам

... тех недопрограммистов, кто его использует. Достало уже. То private/protected, которые через не особо надёжно работаюлие костыли обходить приходится, лишь бы форк фреймворка не компилировать, не поставлять и не сопровождать (а ведь один особо умный додумался задействовать доступ к защищённому члену класса и весь свой форк фреймворка в свой репозиторий скопировать, автоматически исключив возможность поставки этого хлама в каком-либо адекватном дистре, а PR, заменяющий протухший ненужный форк фреймворка на использование специально разработанного (не мной, очень популярная либа) и протестированного хака-костыля-обхода не принимает, видите-ли гарантий, что не поломают и что работать продолжит, тащи форк фреймворка и флатпак используй!).

Ответить | Правка | К родителю #11 | Наверх | Cообщить модератору

61. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Ivan_83 (ok), 23-Апр-24, 22:41 
Приватные/локальные патчи рулят, минус только в накоплении "техдолга".
Но я думаю что при разумном использовании оно стабилизируется на каком то колличестве и дальше расти не будет.

У меня примерно 15 патчей на фрю и 50-60 на порты, и дальше не растёт уже больше года.
Что то приходит, что то уходит.

Ответить | Правка | Наверх | Cообщить модератору

76. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Аноним (76), 24-Апр-24, 02:31 
Если эти патче не в апстриме - то твоя "FreeBSD" никакая не FreeBSD, а Ivan83BSD, которую будешь сопровождать сам, собирать сам, и использовать сам, потому что желающих ставить иваноподелки себе на комп даже в виртуалку нет.
Ответить | Правка | Наверх | Cообщить модератору

108. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Аноним (108), 26-Апр-24, 08:48 
Описал так, как будто это что-то плохое.
Ответить | Правка | Наверх | Cообщить модератору

94. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Аноним (94), 24-Апр-24, 14:50 
Privat и final действительно противоречат сути ООП т.к. мешают переиспользовать код, но с protected всё нормально.

У любого объекта есть два интерфейса - один для использования через композицию (public) и один для использования через наследование (protected).

Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

117. "Анализ влияния ключевого слова final на производительность п..."  +/–
Сообщение от Аноним (117), 27-Апр-24, 02:36 
Ничему они не противоречат. ООП - это не про наследование. ООП - это про объекты как "черные ящики", скрывающие детали реализации и работающие по контрактам. Контракт может быть как формальным (через interface в java), так и фактическим, это без разницы.

Private - это та самая инкапсуляция. Приватный метод от приватного свойства в этом смысла ничем не отличается - это внутрянка, о которой снаружи не надо ничего знать.

Final - это означает, что наследоваться надо не от конечной реализации, а от абстрактного класса, от которого унаследован финальный (или реализовывать интерфейс. Например, внутри в результате оптимизаций всё так тесно связано, что переопределение одного метода без понимания внутренностей приведет к фатальным последствиям. Разработчик этим прямо говорит - не надо от этого наследоваться. Или наследуйся дальше по иерархии, или используй делегирование.

Наследование вообще необязательно и заменяется делегированием всегда. То, что в конкретных C++ или Java для делегирования надо много копипастить - это особенности этих языков. Есть и другие.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру