1.1, Аноним (1), 14:15, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
А люди из интернета точно использовали final именно там, где нужно, а не везде его тыкали?
Это нужно тестировать на виртуальных вызовах, а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".
|
|
|
2.3, Аноним (3), 14:32, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
> а не просто "взял и поставил final на структурку или класс, потому что от нее никто не будет наследоваться".
Вообще-то final именно для этого и придуман, причем, не только в C++.
|
|
2.4, Аноним (4), 14:39, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
И как я вызову виртуальный метод, если у меня final стоит на самом первом классе?
|
|
2.8, Аноним (8), 14:43, 23/04/2024 [^] [^^] [^^^] [ответить]
| +2 +/– |
final как раз нужен для класса с реализацией интерфейса. А числа автора показывают, что в основном ничего не меняется за искл забагованного clang-а
|
|
|
1.5, Rev (?), 14:39, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Для себя автор исследования сделал вывод о необходимости избегать использованиЯ "final".
А опытный разработчик знает, что надо бенчмаркать свой код, и ставить final там, где бенчмарки покажут улучшение :)
|
|
|
2.9, Аноним (8), 14:45, 23/04/2024 [^] [^^] [^^^] [ответить]
| +7 +/– |
final это не метод оптимизации, а защита от гогнокода, особенно при работе в больших командах и в публичном коде
|
|
|
3.56, Аноним (56), 20:49, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Большие команды это где?
Средняя команда разарботчиков 8-12 челоек.
|
|
|
|
|
2.57, Bottle (?), 20:53, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Ещё бы не хватало, чтобы к коду с неопределённым и implementation-defined поведением добавились галлюцинации ИИ.
|
|
|
1.11, Аноним (11), 14:50, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
А вообще каким боком final влияет на производительность кода? Он же нужен исключительно чтобы бить по рукам, не более того.
|
|
|
2.16, Аноним (16), 15:25, 23/04/2024 [^] [^^] [^^^] [ответить]
| +6 +/– |
Поскольку нет наследников -> нет нужды смотреть в vtable -> можно дёргать методы напрямую, минуя виртуализаию
|
|
2.50, Аноним (50), 18:42, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Он же нужен исключительно чтобы бить по рукам
... тех недопрограммистов, кто его использует. Достало уже. То private/protected, которые через не особо надёжно работаюлие костыли обходить приходится, лишь бы форк фреймворка не компилировать, не поставлять и не сопровождать (а ведь один особо умный додумался задействовать доступ к защищённому члену класса и весь свой форк фреймворка в свой репозиторий скопировать, автоматически исключив возможность поставки этого хлама в каком-либо адекватном дистре, а PR, заменяющий протухший ненужный форк фреймворка на использование специально разработанного (не мной, очень популярная либа) и протестированного хака-костыля-обхода не принимает, видите-ли гарантий, что не поломают и что работать продолжит, тащи форк фреймворка и флатпак используй!).
|
|
|
1.12, Аноним (12), 15:00, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что-то я не вижу AOCC и ICC в тестах. Именно они были бы актуальными для соответствующих процессоров.
|
|
|
2.14, Ivan7 (ok), 15:10, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
ICC давно уже сдох, вернее, его придушили.
AOCC не интересно, т.к. это тот же Clang, причём только под Linux.
|
|
|
1.15, Бывалый Смузихлёб (ok), 15:23, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| –4 +/– |
> ключевого слова "final" [EN.cppreference.com/w/cpp/language/final]
Это какой-то особенный вид чего-то, о чём стараются не говорить в приличном обществе. Надо обязательно в русскоязычной статье затолкать ссылку исключительно на англоязычную статью при наличии русскоязычной
[RU.cppreference.com/w/cpp/language/final]
|
|
|
2.18, Я (??), 15:41, 23/04/2024 [^] [^^] [^^^] [ответить]
| +1 +/– |
какой плюсовик умеет читать документацию не на английском?
|
|
2.37, Аноним (37), 17:23, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Из любви к русскому языку - надо. Читать перевод на русский, чтобы в голове переводить обратно на английский, попутно избавляясь от затесавшихся гуртовщиков мышей - не любить русский язык.
|
|
|
1.19, Швондик (?), 15:41, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
иногда можно повысить производительность до 70% если для выхода из сложных циклов использовать оператор goto
|
|
|
2.20, Аноним (20), 16:00, 23/04/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
а если использовать выход в первой строчке проги, производительность ещё сильнее повысится!
|
|
|
3.21, Аноним (21), 16:18, 23/04/2024 [^] [^^] [^^^] [ответить]
| +3 +/– |
Нет, не повысится. Время исполнения уменьшится, но работа, выполненная за это время, будет равна нулю. Итого общая производительность тоже будет равна нулю — программа не делает ничего полезного для изначальной задачи, если только изначально не было цели сразу выходить.
|
|
|
4.39, Аноним (20), 17:47, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Кто сказал, что в изначальной задаче надо было что-то делать? Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.
|
|
|
5.40, Аноним (21), 17:52, 23/04/2024 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Кто сказал, что в изначальной задаче надо было что-то делать?
Если ничего делать не надо, то и задачи нет.
> Полезность - это всё иллюзия. И ваще, мы - пыль в масштабах Вселенной.
Отлично, давайте уйдём глубже в философию и метафизику от точныз цифр.
|
|
|
|
|
2.23, Аноним (-), 16:20, 23/04/2024 [^] [^^] [^^^] [ответить]
| –2 +/– |
> повысить производительность до 70%
Одной функции или всей программы)?
что-то мне подсказывает, что ты про первое
> если для выхода из сложных циклов
В плюсах этого можно достичь и другими способами, начиная от лямд, заканчивая просто return'ом.
> использовать оператор goto
Или превратить код в неподдерживаемые макароны, в которых потом еще много лет находить ошибки.
|
|
|
3.30, Швондик (?), 16:33, 23/04/2024 [^] [^^] [^^^] [ответить]
| –4 +/– |
да я просто пошутил, у нас за goto сразу увольняют если увидят в коде
|
|
|
4.46, Ivan7 (ok), 18:04, 23/04/2024 [^] [^^] [^^^] [ответить]
| +5 +/– |
За goto в C/C++ может уволить только абсолютно безграмотный чел, который никогда не кодил и не писал высокопроизводительные приложения. В некоторых случаях goto реально полезен, причём в этих случаях альтернатив ему особых нет, особенно это касается Си. А ассемблерный код вообще весь построен на тамошнем аналоге goto - jxx. Надеюсь, за jxx у вас никто никого не увольняет??? (А то тогда это совсем какая-то дикая дичайшая дичь.)
|
|
|
|
2.42, Аноним (41), 17:56, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
>если для выхода из сложных циклов использовать оператор goto
Мы про ОО-язык говорим или где?
|
|
|
3.48, Аноним (48), 18:24, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
>>если для выхода из сложных циклов использовать оператор goto
> Мы про ОО-язык говорим или где?
"Настоящий программист может писать Фортран^WСи-программы на любом языке!"
|
|
|
|
1.22, Пряник (?), 16:19, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Требуется сравнительный анализ кода на ассемблере. А так это гадание на /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 [^] [^^] [^^^] [ответить]
| +/– |
> Так повторямых сборок между Clang и g++ никто и не обещал.
ну у любого алгоритма есть один единственный оптимальный набор необходимых и достаточных кодов операций для соответствующей архитектуры, отсюда два разных компилятора, либо выдают два одинаковых набора, либо один из них выдал неоптимальный набор.
|
|
|
|
|
1.26, Серб (ok), 16:26, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Для себя автор исследования сделал вывод о необходимости избегать использование "final".
Вывод прямо противоположный результатам тестирования.
Делаешь макрос который будет final для gcc и пустотой для MS и clang - профит.
|
|
1.28, Аноним (28), 16:27, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Странный выбор у девелопера из опенсорса: промежуточный девелопмент релиз дистрибутива и MS компилятор.
Люди в опенсорсе используют готовые релизы и другие компиляторы. Разве не...
|
|
|
2.34, голос из леса (?), 16:48, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
стандартный "девелопер из опенсорс" с вероятностью 50% сидит на mac os, с вероятностью 40% на win. Остатки может и на linux.
|
|
|
3.45, Аноним (41), 18:02, 23/04/2024 [^] [^^] [^^^] [ответить]
| +/– |
Просмотрите исходники СПО-проектов. В подавляющем большинстве случаев там \0A-окончания строк. Сделайте вывод, кто на чём сидит.
|
|
|
|
1.35, Аноним (35), 17:02, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
> Причиной проведения тестирования послужили витающие в сети заявления, что использование "final" позволяет повысить производительность, которые ограничивались оценочными суждениями без указания результатов изменений.
Ну да, не включали голову.
> Для себя автор исследования сделал вывод о необходимости избегать использования "final".
И этот не включал.
Ну посмотри ты профайл, ассемблер, собери минимальный кейс на котором повторяется проблема, зашли в багзиллы. Это было бы исследование. А этот намерял неизвестно что, и ты поди - ключевого слова избегать будет. return'а ещё поизбегай.
|
|
1.49, Аноним (49), 18:39, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Странно, в тех же исходниках clang часто используется прием:
namespace {
class Classname final : public Basename {
void method() override {}
};
}
Тогда выглядит глупо, что сами же разработчики компилятора это не оптимизировали
|
|
1.52, Аноним (52), 19:38, 23/04/2024 [ответить] [﹢﹢﹢] [ · · · ] | +/– |
Замедление при использовании final вызывает у меня культурный шок Реализация ви... большой текст свёрнут, показать |
|
|