| 1.1, Аноним (1), 14:15, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
 А люди из интернета точно использовали final именно там, где нужно, а не везде его тыкали?
Это нужно тестировать на виртуальных вызовах, а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".
| | |
| |
| 2.3, Аноним (3), 14:32, 23/04/2024 [^] [^^] [^^^] [ответить]
| +3 +/– | |
> а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".
Вообще-то final именно для этого и придуман, причем, не только в C++.
| | |
| 2.4, Аноним (4), 14:39, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
И как я вызову виртуальный метод, если у меня final стоит на самом первом классе?
| | |
| 2.8, Аноним (8), 14:43, 23/04/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
final как раз нужен для класса с реализацией интерфейса. А числа автора показывают, что в основном ничего не меняется за искл забагованного clang-а
| | |
|
| 1.5, Rev (?), 14:39, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
> Для себя автор исследования сделал вывод о необходимости избегать использованиЯ "final".
А опытный разработчик знает, что надо бенчмаркать свой код, и ставить final там, где бенчмарки покажут улучшение :)
| | |
| |
| 2.9, Аноним (8), 14:45, 23/04/2024 [^] [^^] [^^^] [ответить]
| +10 +/– |
final это не метод оптимизации, а защита от гогнокода, особенно при работе в больших командах и в публичном коде
| | |
| |
| 3.56, Аноним (56), 20:49, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Большие команды это где?
Средняя команда разарботчиков 8-12 челоек.
| | |
| |
| 4.92, Аноним (8), 12:53, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Это там, где больше одного человека. За примерами команд >1K с общим кодом можешь, например, сходить в гугл или даже местный Яндекс.
| | |
|
|
| 2.77, Аноним (77), 04:47, 24/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– | |
> А опытный разработчик знает, что надо бенчмаркать свой код, и ставить final там, где бенчмарки покажут улучшение :)
В какой-то выдуманной идеальной вселенной может быть. Бенчмаркать на final - ни у кого не будет времени на подобную фигню и еще смотри что все зависит от компилятора, будешь расставлять final условной компиляцией?
| | |
|
| |
| 2.57, Bottle (?), 20:53, 23/04/2024 [^] [^^] [^^^] [ответить]
| +6 +/– |
Ещё бы не хватало, чтобы к коду с неопределённым и implementation-defined поведением добавились галлюцинации ИИ.
| | |
| |
| 3.72, Sw00p aka Jerom (?), 23:29, 23/04/2024 [^] [^^] [^^^] [ответить]
| –2 +/– | |
> Ещё бы не хватало
лол, кек, компилятор ведь за меня лучше сгенерирует код машинный, и чем тут ЫЫ не помошник? ведь он тоже как и компилятор - "недочеловек".
| | |
|
|
| 1.11, Аноним (11), 14:50, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
А вообще каким боком final влияет на производительность кода? Он же нужен исключительно чтобы бить по рукам, не более того.
| | |
| |
| 2.16, Аноним (16), 15:25, 23/04/2024 [^] [^^] [^^^] [ответить]
| +12 +/– |
Поскольку нет наследников -> нет нужды смотреть в vtable -> можно дёргать методы напрямую, минуя виртуализаию
| | |
| |
| 3.60, Аноним (60), 22:40, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Что-то я не понял твою мысль.
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 не будет использоваться?
| | |
| |
| |
| 5.84, n00by (ok), 08:36, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Осталось ещё убрать final и посмотреть на листинг, для полного просветления.
| | |
| |
| 6.91, Аноним (91), 12:40, 24/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Тот пример действительно не покажет эффект от 'final', если компилятор умеет запоминать тип присвоенного ссылке или указателю объекта, а не ограничивается типом самой ссылки или указателя. Куда лучше тут подходит https://godbolt.org/z/aPKxEWMz5
| | |
| |
| 7.102, n00by (ok), 13:27, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Подходит лучше, пока нет определения функций-членов. При lto может быть проанализирован поток исполнения и разницы не окажется. Но даже если и окажется, то главный вопрос - почему вдруг с final медленнее, а не быстрее.
| | |
|
|
|
| |
| 5.106, fuggy (ok), 17:48, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Я пытался разобраться, но тут нет разницы в ассемблере между clang и gcc c final и без в первом случае. Откуда тогда разница в производительности берётся? Либо нужно более сложный кейс сравнивать.
| | |
| |
| 6.107, n00by (ok), 06:50, 26/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Мне тут другое непонятно. Автор тестов тестировал на своей библиотеке. Получил результат, вызывающий вопросы. Почему он не посмотрел асм и не нашёл ответ сам? Я в подобных случаях всегда смотрел и подчас открывал удивительные для себя вещи.
| | |
|
|
|
|
| 2.50, Аноним (50), 18:42, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Он же нужен исключительно чтобы бить по рукам
... тех недопрограммистов, кто его использует. Достало уже. То private/protected, которые через не особо надёжно работаюлие костыли обходить приходится, лишь бы форк фреймворка не компилировать, не поставлять и не сопровождать (а ведь один особо умный додумался задействовать доступ к защищённому члену класса и весь свой форк фреймворка в свой репозиторий скопировать, автоматически исключив возможность поставки этого хлама в каком-либо адекватном дистре, а PR, заменяющий протухший ненужный форк фреймворка на использование специально разработанного (не мной, очень популярная либа) и протестированного хака-костыля-обхода не принимает, видите-ли гарантий, что не поломают и что работать продолжит, тащи форк фреймворка и флатпак используй!).
| | |
| |
| 3.61, Ivan_83 (ok), 22:41, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
 Приватные/локальные патчи рулят, минус только в накоплении "техдолга".
Но я думаю что при разумном использовании оно стабилизируется на каком то колличестве и дальше расти не будет.
У меня примерно 15 патчей на фрю и 50-60 на порты, и дальше не растёт уже больше года.
Что то приходит, что то уходит.
| | |
| |
| 4.76, Аноним (76), 02:31, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Если эти патче не в апстриме - то твоя "FreeBSD" никакая не FreeBSD, а Ivan83BSD, которую будешь сопровождать сам, собирать сам, и использовать сам, потому что желающих ставить иваноподелки себе на комп даже в виртуалку нет.
| | |
|
| 3.94, Аноним (94), 14:50, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Privat и final действительно противоречат сути ООП т.к. мешают переиспользовать код, но с protected всё нормально.
У любого объекта есть два интерфейса - один для использования через композицию (public) и один для использования через наследование (protected).
| | |
| |
| 4.117, Аноним (117), 02:36, 27/04/2024 [^] [^^] [^^^] [ответить] | +/– | Ничему они не противоречат ООП - это не про наследование ООП - это про объекты... большой текст свёрнут, показать | | |
|
|
|
| 1.12, Аноним (12), 15:00, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Что-то я не вижу AOCC и ICC в тестах. Именно они были бы актуальными для соответствующих процессоров.
| | |
| |
| 2.14, Ivan7 (ok), 15:10, 23/04/2024 [^] [^^] [^^^] [ответить]
| +4 +/– |
 ICC давно уже сдох, вернее, его придушили.
AOCC не интересно, т.к. это тот же Clang, причём только под Linux.
| | |
|
| 1.15, Бывалый Смузихлёб (ok), 15:23, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –7 +/– |
 > ключевого слова "final" [EN.cppreference.com/w/cpp/language/final]
Это какой-то особенный вид чего-то, о чём стараются не говорить в приличном обществе. Надо обязательно в русскоязычной статье затолкать ссылку исключительно на англоязычную статью при наличии русскоязычной
[RU.cppreference.com/w/cpp/language/final]
| | |
| |
| 2.18, Я (??), 15:41, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
какой плюсовик умеет читать документацию не на английском?
| | |
| |
| |
| 4.98, Aleksander256 (?), 09:58, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Школьник? Не встречал взрослого плюсовика который хотябы не сможет почитать хотябы документацию на англицком языке
| | |
| |
| 5.99, Бывалый Смузихлёб (ok), 10:43, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> Школьник? Не встречал взрослого плюсовика который хотябы не сможет почитать хотябы документацию
> на англицком языке
Вопрос не в превозмогании( особенно на фоне обилия онлайн-переводчиков ), а в здравом смысле
| | |
| |
| 6.101, Aleksander256 (?), 12:55, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Тогда пусть ссылаются только на статьи написаные на русском языке. Даже если она устарели и актуальна.
Автор использует ресурс на котором будет 100% достоверная информация, и деллися этой ссылкой, потому что информация которую получаете по ней не введет читателя в заблуждение. Вот это здраво, а в каком состоянии информация на русском языке, это вопрос, полноценна она или нет, достоверна она или нет, отвечает критериям читателя или нет, итд. Если хотите можете взять на себя обязанность в поддержке русскоязычного ресурса, привести в порядок, но ссылаться на него или нет, это уже дело автора.
| | |
|
| 5.103, n00by (ok), 13:29, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Поставим вопрос иначе: какой % плюсовиков прочитал стандарт языка?
| | |
| |
| |
| 7.121, n00by (ok), 09:11, 28/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Звчем? Русский или английский?
Вот этот - явно не читал стандарт.
| | |
|
|
|
|
|
| 2.37, Аноним (37), 17:23, 23/04/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Из любви к русскому языку - надо. Читать перевод на русский, чтобы в голове переводить обратно на английский, попутно избавляясь от затесавшихся гуртовщиков мышей - не любить русский язык.
| | |
| 2.73, Аноним (73), 00:09, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Для упрощения процесса эта вики уже была переведена с помощью Google на ... и русский языки.
не, пусть будет ссылка на англоязычную
| | |
|
| 1.19, Швондик (?), 15:41, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
иногда можно повысить производительность до 70% если для выхода из сложных циклов использовать оператор goto
| | |
| |
| 2.20, Аноним (20), 16:00, 23/04/2024 [^] [^^] [^^^] [ответить]
| +6 +/– |
а если использовать выход в первой строчке проги, производительность ещё сильнее повысится!
| | |
| |
| 3.21, Аноним (21), 16:18, 23/04/2024 [^] [^^] [^^^] [ответить]
| +4 +/– |
 Нет, не повысится. Время исполнения уменьшится, но работа, выполненная за это время, будет равна нулю. Итого общая производительность тоже будет равна нулю — программа не делает ничего полезного для изначальной задачи, если только изначально не было цели сразу выходить.
| | |
| |
| 4.39, Аноним (20), 17:47, 23/04/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
Кто сказал, что в изначальной задаче надо было что-то делать? Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.
| | |
| |
| 5.40, Аноним (21), 17:52, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Кто сказал, что в изначальной задаче надо было что-то делать?
Если ничего делать не надо, то и задачи нет.
> Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.
Отлично, давайте уйдём глубже в философию и метафизику от точныз цифр.
| | |
|
|
|
| 2.23, Аноним (-), 16:20, 23/04/2024 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> повысить производительность до 70%
Одной функции или всей программы)?
что-то мне подсказывает, что ты про первое
> если для выхода из сложных циклов
В плюсах этого можно достичь и другими способами, начиная от лямд, заканчивая просто return'ом.
> использовать оператор goto
Или превратить код в неподдерживаемые макароны, в которых потом еще много лет находить ошибки.
| | |
| |
| 3.30, Швондик (?), 16:33, 23/04/2024 [^] [^^] [^^^] [ответить]
| –6 +/– |
да я просто пошутил, у нас за goto сразу увольняют если увидят в коде
| | |
| |
| 4.46, Ivan7 (ok), 18:04, 23/04/2024 [^] [^^] [^^^] [ответить]
| +10 +/– |
За goto в C/C++ может уволить только абсолютно безграмотный чел, который никогда не кодил и не писал высокопроизводительные приложения. В некоторых случаях goto реально полезен, причём в этих случаях альтернатив ему особых нет, особенно это касается Си. А ассемблерный код вообще весь построен на тамошнем аналоге goto - jxx. Надеюсь, за jxx у вас никто никого не увольняет??? (А то тогда это совсем какая-то дикая дичайшая дичь.)
| | |
| |
| 5.85, n00by (ok), 08:42, 24/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Некоторые и за "C/C++" увольняют, поскольку это маркер, что писавший не видит разницы. В С++ goto позволяет обойти конструкторы/деструкторы, что недопустимо.
| | |
| |
| 6.93, Аноним (93), 14:19, 24/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
можно пример? Чтоб именно goto обошел конструктор/деструктор, а не какой-нить setjmp
| | |
| |
| 7.104, n00by (ok), 14:04, 25/04/2024 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> можно пример? Чтоб именно goto обошел конструктор/деструктор, а не какой-нить setjmp
https://godbolt.org/z/KGaoGYq9W
#include <iostream>
struct S { S(); };
int main()
{
goto uninit;
int i(0);
S s;
uninit:
std::cout << i;
}
example.cpp
<source>(9): warning C4533: initialization of 's' is skipped by 'goto uninit'
<source>(9): note: see declaration of 's'
<source>(10): note: see declaration of 'uninit'
<source>(11) : warning C4700: uninitialized local variable 'i' used
Compiler returned: 0
В GCC вам по умолчанию нужный ключик добавили, что бы это воспринималось как error.
Стандарт явно запрещает лишь переходы в блоки try/catch (A goto or switch statement shall not be used to transfer control into a try block or into a handler).
| | |
| |
| 8.116, Ivan7 (ok), 16:12, 26/04/2024 [^] [^^] [^^^] [ответить] | +1 +/– | Во-первых, в данном случае компилятор выдал кучу предупреждений Во-вторых, если... текст свёрнут, показать | | |
|
|
|
|
|
|
| 2.42, Аноним (41), 17:56, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>если для выхода из сложных циклов использовать оператор goto
Мы про ОО-язык говорим или где?
| | |
| |
| 3.48, Аноним (48), 18:24, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
 >>если для выхода из сложных циклов использовать оператор goto
> Мы про ОО-язык говорим или где?
"Настоящий программист может писать Фортран^WСи-программы на любом языке!"
| | |
|
| 2.63, Ivan_83 (ok), 22:44, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
Это тонкий троллинг :)
goto полезен скорее для выхода по ошибке, к есдиному месту где очищаются ресурсы.
Иногда там местки расставляют через строчку, чтобы разное колличество шаго деинициализации/освобождения ресурсов делать.
А так, мне нравится режим фильтра, когда последовательно проверяются условия (не повышая вложенности) и стараются быстрее сделать break/continue/return.
| | |
| |
| 3.87, n00by (ok), 08:46, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
> goto полезен скорее для выхода по ошибке,
> к единому месту где очищаются ресурсы.
Это нормально в Си. В Си++ вместо этого используется RAII, и при наличии не POD типов goto опасен.
| | |
| |
| 4.110, Аноним (108), 09:00, 26/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Использование RAII не освобождает от необходимости подчищать при выходе из цикла.
| | |
| |
| 5.119, n00by (ok), 08:30, 28/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Использование RAII не освобождает от необходимости подчищать при выходе из цикла.
"можно пример?" (ц) Что и за кем необходимо подчищать.
| | |
|
|
|
|
| 1.22, Пряник (?), 16:19, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Требуется сравнительный анализ кода на ассемблере. А так это гадание на /dev/random.
| | |
| |
| 2.31, Sw00p aka Jerom (?), 16:35, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Требуется сравнительный анализ разработчиков всех этих компиляторов, стандарт языка вроде один, архитектура машинных команд вроде одна, оптимизации одни и те же, ток результирующий исполняемый код почему-то разный.
| | |
| |
| 3.36, Пряник (?), 17:20, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Я это и сказал. Компилятор выдаёт на выходе код ассемблера сначала перед тем, как конвертировать в машинный. Код ассемблера и машинный равны примерно 1-к-1.
| | |
| |
| 4.51, Sw00p aka Jerom (?), 18:56, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Так повторямых сборок между Clang и g++ никто и не обещал.
ну у любого алгоритма есть один единственный оптимальный набор необходимых и достаточных кодов операций для соответствующей архитектуры, отсюда два разных компилятора, либо выдают два одинаковых набора, либо один из них выдал неоптимальный набор.
| | |
| |
| |
| |
| 7.111, Аноним (108), 09:02, 26/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
То что утверждается без аргументов опровергается также без аргументов.
| | |
|
|
|
|
| 3.66, Аноним (60), 23:06, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Ты объем кода шланга или гцц видел? Ну ок, покажи как надо делать. Потом сравнительный анализ тебя проведем
| | |
|
| 2.78, Аноним (77), 04:52, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– | |
> Требуется сравнительный анализ кода на ассемблере. А так это гадание на /dev/random.
Замер фактической производительность > чем гадание на ассемблере.
| | |
|
| 1.26, Серб (ok), 16:26, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
 > Для себя автор исследования сделал вывод о необходимости избегать использование "final".
Вывод прямо противоположный результатам тестирования.
Делаешь макрос который будет final для gcc и пустотой для MS и clang - профит.
| | |
| 1.28, Аноним (28), 16:27, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Странный выбор у девелопера из опенсорса: промежуточный девелопмент релиз дистрибутива и MS компилятор.
Люди в опенсорсе используют готовые релизы и другие компиляторы. Разве не...
| | |
| |
| 2.34, голос из леса (?), 16:48, 23/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
стандартный "девелопер из опенсорс" с вероятностью 50% сидит на mac os, с вероятностью 40% на win. Остатки может и на linux.
| | |
| |
| 3.45, Аноним (41), 18:02, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Просмотрите исходники СПО-проектов. В подавляющем большинстве случаев там \0A-окончания строк. Сделайте вывод, кто на чём сидит.
| | |
| |
| 4.88, n00by (ok), 08:50, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ну мы так на Венде делали. Специально, для повышения качества экспертизы.
| | |
| 4.90, Аноним (90), 12:36, 24/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Офигеть показатель. Наверное конец строки - это штука, которую принципиально невозможно настроить в редакторе или IDE? Надо будет глянуть как там у меня под виндой в Geany и Notepad++ сделано.
| | |
| 4.96, Электрон (?), 07:46, 25/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
Показательнее пример Mozilla, разработчики Firefox пользуются Chrome в качестве основного браузера, везде Гуглосервисы.
| | |
| 4.97, Электрон (?), 07:48, 25/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Забыл еще написать про электронные адреса. Заглянуть в AUR - там повсеместно gmail указан.
| | |
|
|
|
| 1.35, Аноним (35), 17:02, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– | |
> Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений.
Ну да, не включали голову.
> Для себя автор исследования сделал вывод о необходимости избегать использования "final".
И этот не включал.
Ну посмотри ты профайл, ассемблер, собери минимальный кейс на котором повторяется проблема, зашли в багзиллы. Это было бы исследование. А этот намерял неизвестно что, и ты поди - ключевого слова избегать будет. return'а ещё поизбегай.
| | |
| 1.49, Аноним (49), 18:39, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Странно, в тех же исходниках clang часто используется прием:
namespace {
class Classname final : public Basename {
void method() override {}
};
}
Тогда выглядит глупо, что сами же разработчики компилятора это не оптимизировали
| | |
| |
| 2.62, Аноним (60), 22:44, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
final может не только с классами использоваться (запрещая их наследовать), но и для методов-членов, запрещая дочерним классам их переопределять
| | |
| 2.114, Пряник (?), 11:58, 26/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
Какой же стрёмный синтаксис у плюсов... Обернули в какой-то namespace, два имени у класса, после функции какой-то override. Очень понятно.
| | |
|
| 1.52, Аноним (52), 19:38, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– |
Замедление при использовании final вызывает у меня культурный шок. Реализация виртуальных методов стандартна - в объекте хранится указатель на таблицу, в таблице указатель на код. final гарантирует, что наследники не переопределяли код, поэтому чтение таблицы компилятор может иногда выкинуть. Я просто не могу представить, что должен сделать компилятор, чтобы стандартный подход стал выполняться медленней. final и override - это в основном синтаксический сахар, чтобы бить по рукам тех, кто не синхронизирует изменения методов в предках и потомках, а также помощь читающим код, чтобы было видно виртуальные методы. Реально выкидывание чтения таблицы должно происходить крайне редко, обычно везде передаётся указатель на базовый класс с виртуальными методами без реализации.
Из-за большой разницы в производительности, я склонен подозревать автора больше чем что-либо ещё.
| | |
| 1.80, Аноним (-), 07:22, 24/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Ко там хвалил шланг? Запомните, копилефтный GCC - это эталон качества.
| | |
| |
| 2.82, Аноним (82), 08:27, 24/04/2024 [^] [^^] [^^^] [ответить]
| –3 +/– |
Тормоза шлангового кода - это не баг, а фича. M$ не для того его спонсирует, чтобы тот обгонял их собственный, конкурирующий, закрытый продукт.
| | |
|
| 1.113, Аноним (108), 09:13, 26/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
>final was placed on just about EVERY interface.
"Бездумное, механическое использование ключевого слова final в среднем понижает произодительность, поэтому лучше его избегать."
Это точно ведущий разработчик, а не взятый по гендерной квоте?
| | |
|
