Общие вопросы по программированию (703 стр)

Aroch
> синтетический пример скорее всего не покажет большой разницы.
"Реализовать" в смысле в конечном приложении. У него же должны быть хотя бы какие-то демки, под которые он это всё делает, какой-нибудь тетрис или змейка, вот на них и тестируется.

Имбирная Ведьмочка
> "Реализовать" в смысле в конечном приложении. У него же должны быть хотя бы
> какие-то демки, под которые он это всё делает, какой-нибудь тетрис или змейка,
> вот на них и тестируется.
на мелком говне тоже особой разницы скорее всего не заметишь. А что-то крупное сомневаюсь что он когда либо писал. Хотя можно предложить ему тот же рейтрейсер написать и сравнить, тут уже разница сразу станет видна.

iw4nna.rock
> Вы ляпнули околесицу. Такое бывает. Я вас не осуждаю за это.
Покажи полный пример с a.draw(), чтобы компилировался, а не тот огрызок, что ты написал. Пусть даже тело draw будет ровно таким же, как в примере.

Alprog
> А ничего, что современный компайлер может передавать параметры через регистры,
> что быстрее рандомного доступа к памяти?
используя компилятор FPC я ему указываю использовать регистры, в случае необходимости.

> современный компайлер может решить заинлайнить функцию
что-то как раз в FPC этого не заметил. Доступные ("глобальные" - якобы) переменные используемые в функциях - инлайнятся, закрытые - нет.

> переставить местами операции с локальными переменными ради оптимизации
Не все компиляторы оптимизированы полностью.

> Я уж молчу про какую-то возможность масштабирования программы
что не так с возможностью масштабирования при использовании глобальных переменных?

  Важно понимать, что я не за и не против, я за то, чтоб подходить с правильной стороны. И для каждого это может быть разный подход. Особенно учитывая какими компиляторами пользуется человек.

Mirrel
> используя компилятор FPC
он уже научился компилить плюсовый код? Зачем ты тащишь в обсуждение всякую гадость?

Mirrel
> Особенно учитывая какими компиляторами пользуется человек
Мы говорили про библиотеку рендера на С++. Человек пользуется следующими компиляторами:

MinGW
Visual C++ 6.0 and higher
Open Watcom V2

Совет использовать ему глобальные переменные ради производительности — это вредный совет.
И предубеждения тут не причём. Это по факту так.

> используя компилятор FPC
Я допускаю, что в мире паскаля такой компилятор, что там действительно глобальные переменные по какой-то причине предпочтительнее. Но тогда это офтоп и не очень понятно, зачем кому-то, кроме паскалистов, на это ориентироваться.

> что не так с возможностью масштабирования при использовании глобальных переменных?
Я правильно помню, что ты не используешь систему контроля версий? Или с кем-то путаю? Просто я вряд ли смогу объяснить что-то про масштабирование, если речь идёт о масштабах, где даже контроль версий ещё не является необходимостью.

Mirrel
FPC — это не современный компилятор. Современные компиляторы — это LLVM, GCC и, с большой натяжкой, MSVC.

Alprog
> Совет использовать ему глобальные переменные ради производительности
ткнёшь пальцем, где я писал в совокупности о  глобальных переменных и производительности?

  Использовать глобальные переменные, чтоб увеличить производительность - это дополнительная работа программиста. И есть ли такие индивидуумы, которые этим будут заниматься?

Mirrel
> Использовать глобальные переменные, чтоб увеличить производительность - это
> дополнительная работа программиста.
Причём вовсе не гарантируется, что производительность от этого действительно увеличится, о чём тут и говорят.

static_assert(std::is_nothrow_invocable_v<decltype(&B::template operator()<int>), B>);

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

Я думаю, что производительность больше увеличится из за архитектурных особенностей. К примеру реализация того же батчинга геометрии и текстур под капотом фреймворка. Это даст больший буст, чем микро оптимизации.
Рисование только видимых объектов. Максимум вижу смысл указать inline определённым методам и то это имеет смысл для старых компиляторах. На современных gcc 11 и msvc 2022 оптимизация очень хороша.

nes
> static_assert(std::is_nothrow_invocable_v<decltype(&B::template operator()<int>), B>);
>
> Какая же срань, кресты скоро станут сложнее машинного кода для восприятия.
Всё понятно же. Берётся класс B, внутри него берётся шаблонный метод operator(), в этот шаблон подставляется параметр <int> — получается B::template operator()<int>, для этого метода берётся указатель-на-мембер-функцию; после чего происходит проверка, что для типа &B::template operator()<int>, каким бы он по факту не был, можно сделать std::invoke, дополнительно передав объект типа B по значению в качестве первого аргумента, и этот инвок будет nothrow.

Это неправильная проверка, кстати говоря. Так как объект в метод передаётся по ссылке или указателю, то и в из_инвокабл должно быть соответственно либо const volatile B&, либо const volatile B*:

#include <functional>
#include <type_traits>

struct bt {
    void func();
};

void foo(bt const& b) {
    // passes:
    static_assert(std::is_invocable_v<decltype(&bt::func), bt>);
    // no matching function for call to 'invoke(void (bt::*)(), const bt&)':
    std::invoke(&bt::func, b);
    // what actually corresponds to the above:
    static_assert(std::is_invocable_v<decltype(&bt::func), const bt&>);
}

Mirrel
> передавать структуру (объект?).
Это лучше чем глобальные переменные. В данном случае.

iw4nna.rock
Я рад, что всё таки кто то думает об оптимизации. По работе особо не пооптимизируешь, а в данном проекте могу развернуться.

Aroch
> Хотя можно предложить ему тот же рейтрейсер написать и сравнить, тут уже
> разница сразу станет видна.
Что это? Необязательно писать с нуля. Могу что то портировать под фреймворк. Я портировал примеры по OpenGL 3.3 c glfw, вполне успешно.