>>794935

>Также сам по себе С испольщует стеклвый фрейм

Да ты ёбу дал, это понятие не C, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет (...кхм... ну, что-нибудь...), и написать под неё компилятор C. Более того, компилятору под «нормальные» платформы тоже не запрещено вместо стекового фрейма реализовать вызовы и локальные переменные как-то по другому; банально функция, заинлайненная в другую функцию, или функция, «вызванная» из другой функции последним действием через jmp вместо call — примеры таких «вызовов» без фрейма. Если под trunk-функциями имелись в виду leaf-функции, то это ТОЖЕ чисто понятие платформы. (А, ок.)

>в half-life был же вариант "software render". И всё нормально работало, не тормозило.

Играл я в неё недавно, и софтварный рендер выставлял... На высоких разрешениях он тормозит именно так, как от него можно ожидать. Старые ЭЛТ-мониторы умели нормально отображать низкие разрешения на весь экран.

>>794943

>fastcall-конвенции

...И даже соглашения платформы можно не соблюдать, если не хочется: https://devblogs.microsoft.com/oldnewthing/20150128-00/?p=44813, они нужны только для взаимодействия с остальным миром. Другое дело, что остальным миром может являться ОС и от неё может требоваться работоспособность механизма, которым Access Violation можно поймать и обработать как исключение, так что с внешним миром потенциально взаимодействует любая точка программы и в такой ситуации совсем борзеть всё же не стоит, но на практике вот автор https://github.com/synopse/mORMot2/blob/master/src/core/mormot.core.fpcx64mm.pas, который явно считает это промышленным решением, хладнокровно выебал в рот все эти соглашения Win64, что «пролог и эпилог функции должны выглядеть так-то и так-то, никаких push посередине, а то система её корректно раскрутить не сможет» (https://learn.microsoft.com/en-us/cpp/build/prolog-and-epilog), в теории достаточно охуевший компилятор C (GCC с достаточно охуевшими флагами, я не разбираюсь) тоже мог бы это сделать.

>>827002
Ну ладно.

Но пикрил выглядит дебильтно. Во-первых обучение програмиированию не связано с векторной алгеброй. Хз зачем там насыпали матрицы и векторы - это всё на первом курсе в университете объясняют, понять как работает С++ это вообще не даёт. Камон, урок называется "С++", а обучают векторной алгебре - что за ебланство. Векторы можно хоть на С, хоть на Паскале, хоть на ассемблере реализовать. У столярова как раз плюс в том что акцент сделан именно на самом языке. То есть вот что такое С, и почему С - не паскаль? Потому что С - низкоуровневых язык, с околонулевым рантаймом, там каждая операция производит некоторые действия с памятью. Там даже есть глава "программа на С без стандартной библиотеки" которая демонстрирует чем по своей сути является С, и почему нововведения из gcc выглядят довольно нелепо. В следующий книге уже идёт повествование о С++, и там уже наглядно поясняется разница между низким байтоёбским уровнем, и высоким. То есть что такого делает компилятор С++, что позволяет сократить труд по программированию. Например вот пишешь ты void func(int a) - на обычном С под функцию строго выделяются байты. А в С++, на самом деле выделяются байты под функцию _int_func, чтобы её можно было перегрузить и сделать такую же но _float_func допустим. И компилятор в зависимости от аргумента выберет необходимую.

Чем это полезно вообще? С++ довольно топорный и низкоуровневый. Если не понимать как он устроен то можно подумать что он не работает как нужно. На самом деле он просто странный - создатели и добавили в него "высокоуровневые фишки" при этом байтоёбство оставили. В итоге получилось что-то всратое, но говорят что полезное, так как производительность он всяко больше выдаёт.

Во-вторых, если ты чисто хочешь разрабатывать игры, то зачем тебе разрабатывать графику, и зачем тебе С++? Разработка игр сводится к написанию скриптовухи, и разработке моделек. Это довольно душное занятие. Если начать писать свою графику, в какой-то момент поймёшь что нахуй эти видеоигры вообще нужны.

>>827013

>Heap new delete

Это тоже уровень новичка.

>Destructors

Это у столярова есть, буквально в первых главах срр. Тоже уровень новичка

>std:string

Это STL. Полезная штука, у столярова этого нет. Это лучше отдельно от С++ учить, потому что шаблоны не являются частью с++.

>Всё остальное

Ну и мусор. А зачем это вообще изучать? Я когда свой трехмерных рендер писал, я максимум референс мануал по xlib прочитал. Всё. Зачем нужны уроки по клиппингу? Если ты не конченный долбоеб, то теле сложно будет не заметить что твоя программа тратит такты процессора на отрисовку мусора. Более того, тебе не сложно будет заметить, что если мусора больше чем полезного (а такую ситуацию запросто представить если ты например смотришь в близком приближении) то очевидно у тебя программа зависнет впизду обрабатывая мусор. Любому абсолютно придёт на ум вопрос: "как мне вычислить что фигура попадает в область". Собственно, самому думать сложно - заходим в Википедию. А там что? Там псевдокод:
https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm
Реализуем данный алгоритм хоть на паскале хоть на С, хоть на С++ разницы вообще не имеет.

Ты можешь прямого сейчас всю 3D графику реализовать на GraphABC паскаль

Вот, попробуй прочитать эти статьи и реализовать графику на паскале

https://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%91%D1%80%D0%B5%D0%B7%D0%B5%D0%BD%D1%85%D1%8D%D0%BC%D0%B0

https://en.wikipedia.org/wiki/Wavefront_.obj_file

https://en.wikipedia.org/wiki/Rasterisation#triangle

https://en.wikipedia.org/wiki/Z-buffering

https://en.wikipedia.org/wiki/3D_projection

https://en.wikipedia.org/wiki/Shading

https://en.wikipedia.org/wiki/Gouraud_shading

https://en.wikipedia.org/wiki/Barycentric_coordinate_system

>>870193
Так не используй RAII.
Ну, то есть в некоторой степени придётся использовать для взаимодействия с чужими либами - но это можно обернуть в классе (более того, задача достаточно шаблонная, ты можешь с удобным тебе синтаксисом сделать это для одного класса - а нейросеть по твоему шаблону сделать для всех остальных структур и функций либы).

Я примерно так делаю (RAII я не игнорирую, но использую очень ограничено):
У каждой структуре есть метод init. То есть после создания объект невалидный, и надо сделать init - и из-за того что это не конструктор, мне не надо использовать уродливые конструкции вида
class t_class{
A a;
B b;
tud_descriptor_string_cb usb_musor;
t_class(int x, int y):a{123,"s12313"},b(12312,643345), usb_musor{calculate_param_for_usb_musro()}{
... код конструктора.
}
}, я такое постоянно вижу в примерах, особенно в коде игр, и там таких вложенных штук просто на десять строк, больше чем конструктора.
Мне очень не нравится что в таком синтаксисе параметры для конструкторов я не могу в теле конструктора вычислить, а мне нужны вспомогательные функции вида calculate_param_for_usb_musro, чтобы прямо в скобках вычислить параметры - что не всегда эффективно (какая-то функция может высчитывать параметры сразу для двух вложенных классов), и выглядит отвратительно. Это та часть синтаксиса в с++, которая топ-1 по уродливости с моей точки зрения. Топ-2 это умные указатели, кстати.. Ну и ещё это странно, для примера я создаю структуру мира, в которую вложена, например, локация и объект. И получается, что несмотря на то что было бы логично сгенерировать мир, а потом туда в зависимости от свойств мира добавлять локацию и объекты - с raii выходит, что я сначала создаю объект, а уже потом локацию и мир. И так как объекту нужно что-то знать про мир, хотя бы просто иметь указатель на владельца, то всё-равно придётся что-то вроде ниже-описанной функции init делать.
С функцией init я могу в теле конструктора делать что хочу, удобным образом и в нужной мне последовательности, примерно так:
class t_class{
A a;
B b;
tud_descriptor_string_cb usb_musor;
void init(int x, int y){
a.init(123,"s12313");
auto r=calculate_param_for_();
b.init(r.first);
usb_musor.init(r.second);
... код конструктора.
}
}
Итого в конструкторе/деструкторе или ничего нет, или что-то супер простое типа выделения 20 мб памяти для массива, которую со стека я не возьму, а из кучи возьму, и которое в RAII логично ложится.
И аналогично я могу destroy вызывать когда мне хочется.
Есть конечно проблемы, что можно два раза вызвать init/destroy - но такую ошибку допустить достаточно сложно, как мне кажется, ну и к слову виртуальный метод (не статичный, а в таблице виртуальных методов когда есть что-то) даёт наклодных расходов больше (и по памяти, и по быстродействию), чем проверка bool-переменной в вызове статичного метода. Проверка проще, чем переход по чему-то там в таблице виртуальных методов, я тестировал это на разных компьютерах. Ну да это впрочем и логично, у проверки функционал проще. Да, надо иметь ввиду, что такая фигня сразу делает не особо совместимым тип с stl-контейнерами, и если unordered_map будет расширять свой внутренний буфер - он с большой вероятностью не слишком качественно скопирует твои объекты и нужно немного понимать что где происходит.
Конечно можно все объекты хранить как указатель, и вызывать для них new для инициализации в нужный момент - но это бьёт по производительности, и это не окей, что в угоду синтаксиса вместо монолитного расположения памяти объекты лежат в куче как попало, и разыменовываю постоянно указатели, хотя это нужно только для инициализации, лол. Или сделать пустой объект и move-оператор присваивания.

Да, move-симантика и вот эти мутные схемы, когда какая перегрузка перемещения или копирования вызывает, и почему у меня конструктор копирования и конструктор перемещения это не то же самое, что оператор = копирования и перемещения (при инициализациях вида A a={1,3}; и A a{1,3}; вроде какая-то разница в вызовах есть) тоже немного напрягает, потому не считаю зазорным написать явный метод вида move_unit(unit from, unit to). Это как есть офигительное копирование строк через while (dest++ = src++) и аналогичный фокус с абузом switch/case, но ведь всегда можно написать
int i = 0;
while (src != 0) {
dest = src;
i++;
}
dest = 0;
что скорее всего после компилятора будет байт в байт тем же кодом, что и вышерасположенная нечитаемая дичь.

>Что мне нравится, по сравнению с Паскалем:

Не знаю что там с паскалем, но в делфи (которая delphi XE и моложе) добавили же в некоторой степени обобщённые методы, генеретики какие-то. Я не помню, не писал 15 лет. Перегрузки тоже там есть, их я очень люблю и писал на делфи везде и в си пишу.

>>870253
Мяу, я конечно считаю, что ты перечислил большое количество искусственно возникающих проблем, которые невероятно хорошо решаются исключениями и RAII, и даже некоторое количество реальных проблем + помимо прочего я не могу не признать что твой подход верный с точки зрения здравомыслящего и направленного на результат человека: в 99.9% случаев оптимальнее и разумнее, дешевле и проще докупить второй сервер, вместо найма х3 программистов, которые смогли бы сделать то же самое без исключений и RAII.

Но речь идёт уже не про результат, а про процесс. То есть изначально претензия была не к тому, что через RAII программы не пишутся, а к тому, что это "фу, бяка, не хочу исключения", что я полностью поддерживаю. Мне оно не нравится дополнительными накладными расходами, и я понимаю что это в мире 16-ядерных ноутов с 16/32/64 гигами это шиза лютая, это как если бы я начал экономить электричество у себя дома, выключал бы свет на работе сберегая электричество на уровне как этим стоило бы заниматься на марсоходе. Что ещё абсурднее в мире, где у нас популярная операционная система - это виндоус, который после запуска сразу 4+ гб ест, и браузеры... ой, сам знаешь что я мог бы тут написать про браузеры и веб-языки. Ты прав во всём, если задача получить работающую программу, и нет задачи получать удовольствие от процесса.

Ещё чуть-чуть лирики, которая вряд ли стоит пикселей, на которых написана.

Типа да, это удобно; работает, что подтверждается практикой; очень сильно прикрывает задницу кожаным, которые да, могут пожертвовать 20% быстродействия и 40% потребления памяти, но зато получить возможно не решать фундаментальные проблемы кожаных (вроде невнимательности), а заниматься решением настоящих проблем. 40% производительности и памяти - это затраты, а не проблемы. Понятные, предсказуемые и с известным оптимальным (по времени и финансам) решением. А вот то что 30 лет назад не было удобного CAD-редактора вроде Solidworks или другого софта с таким - вот это было настоящей проблемой, несопоставимо более сложно, и даже если бы создание такой программы потребовало бы использовать просто худшие языки с х100 потреблением памяти и х0.01 производительностью, это бы всё-равно было оправдано.
А сейчас ещё нейронки плюс-минус в эту же сторону оптимизации ведут человечество. Я сейчас, сегодня, вот я сам - у которого любимый язык си, и который даже на питоне пишет почти без использования исключений, вот я тыкал нейронку, чтобы оно мне переформатировало csv, xlsx файлы и вывело какие-то графики, и оно мне это сделало за 10 минут, тогда как я бы сам гуглил функции всяких openpyxl и matplotlib день, а если бы писан на си, а в идеале ещё и без либ писать свой код для открытия и распаковки xlsx, где не будет исключений, это бы был уже не день, а месяц, если не год.

А ещё интересный мысленный эксперимент.
Вселенная 1. Байтоёбы. Лютые. Пишут код на чистом си. За каждым действием компьютера стоит строчка кода, 0 автоматический действий. Проходит 100 лет. Они даже написали кусочек игр, браузеров и даже cad-систем.
Вселенная 2. Адепты высокоуровневых языков. Прошло 20 лет. Пишут на питоне, на js, на любом мусоре, отображения окна браузера с 4 иконками и 40 строками текста требует загрузки 40 мб из сетки и 600 мб оперативы для кеширования, а работает это на связке тяжело жужжащих системников. Прошло 40 лет. Системников произвели ещё больше чтобы это хоть как-то работало, окей, если компьютер это 10 квт тепла и 70 децибелл шума, но лютое злоупотребление высокоуровневыми языками, конструкторами всевозможных программ и прочее приводят к тому что от реализации до демки требуется неделя или меньше даже для сложных программ. Ну и сервер на 50 квт для первых версий, да.
прошло 60 лет. Люди написали все возможные программы, изобрели удобнейшие cad-программы и прочее такое, и в тоге где-то стоит мегаваттный суперкомпьютер с cad системой, на нём отдель из нескольких инженеров считают как сделать ракету, как сделать термоядерный реактор, как собрать кольца и сферы дайсона и вот это всё + более того, любая идея проверяется численными методами за несколько часов написания кода и последующую отправку на рассчёт. Последующее тиражирование разработок этих инженеров делает эти мегаваттные затраты в масштабах человечества просто нулевыми и незначительными. Через 80 лет эти люди приходят к ии намного провосходящим всё что у нас есть сейчас, и эти ии к 85 году переписываю весь софт на супер-низкоуровневые инструкции, становится доступно каждому под свои нужны, задачи или хотелки написать и скомпилировать на час, например, интернет браузер на ассемблере под конкретную архитектуру этого человека. И всё. В этой точке вселенная 2 превосходит вселенную 1 и по суммарной вычислительной мощности (подстёгивалось не воспитание программистов, а создание серверов, которые масштабируются лучше) и по омтимизации (так как индивидуальное написание программ под каждую архитектуру становится доступным из-за феноменально высокой скорости разработки).

Аналогичная ситуация с зелёной и солнечной энергетикой. Думаю, если все откажутся от углеводородов и будут сидеть на солнечных панелях, то технологический прогресс замедлиться, и будет очень неспешным, и через 500 лет будет не сильно выше текущего. А если нещадно жечь нефть, уголь и газ, то технологический прогресс через 50 лет может быть очень высоким, приедут ко всяким реакторам на быстрых нейтронах или, лол, термоядерным реакторам и как бы так не вышло, что неспешное тление в течении 500 или 5000 лет загрязнит землю сильнее, чем короткий и очень интенсивный кусок в 50 лет, за которым технологий будет достаточно, чтобы прийти к отсутствию загрязнений. Иногда препятствие лучше преодолевать с разбегу, чем медленно, долго и упорно строить к нему лестницу.

>>870423

>видеокодеки

Ну, там и осмысленность высокая. Камер очень много, я не удивлюсь, если сейчас в мире есть петабайт данных в секунду. И если бы там был не h265/h264, а h262, то, ну, было бы три петабайта в секунду. А ещё, ну, вроде только вчера я видел в av1 кодировал по 40 минут на 1 секунду 1280х720х30 , а сейчас это и на процессоре в разы быстрее, и у меня на видеокарте стоит пусть не такой идеальный, но энкодер av1 который может в реальном времени писать 1920х1080х60. А ещё говоря уже av2 то ли вышел, то ли близко к этому. Это экономит одновременно кучу байт/с сетевого трафика и кучу байт на накопителях данных. Возможно в ущерб производительности. Впрочем, ещё лет 20 назад вроде бы предсказывали, что закон Мура плюс-минус работать будет (для производительности), а вот для памяти и данных оно растёт медленнее, и в целом мы придём к сценарию, что производительность дефицитным ресурсом не является, а вот скорость памяти ой как является. На сервере с терабайтом памяти скорость нейросети ограничивается скоростью памяти, расчёты это проценты от затрачиваемого времени. Ну и цены на ddr5, ну да сам знаешь.

>раньше ДЕЙСТВИТЕЛЬНО было лучше

Да есть такое. Я в этом восхищаюсь достижениями науки и техники времён второй мировой. Там в течении 1-3 лет не имея наработок и никакого опыта в соответствующих областях сделали ракету, турбореактивный двигатель, радары микроволновые, ну и так далее по списку, и основные выработанные тогда решения стали стандартом лет на 30 вперёд. А потом ещё за 1-10 лет сделали ядерные реакторы, бомбы, термоядерные бомбы, спутники. Сейчас какую-то фигню которую сделали ещё в 80 заново проектирую и разрабатываю лет 10 до первого образца - при том, что там ничего нового и все решения уже известны, просто выбери нужные и сделай. Это капец.

В нейросети я всё же верю. Инвесторам врут; это, возможно, обвалится, и по факту окажется намного менее полезным, чем думают - но, мяу - это:
1 - избавляет от рутинного кода. Парсинг json-файла я вполне и запись значений из него в нужные поля структуры я доверю нейросети больше, чем себе. Это очень простая задача, с которой справляется qwen-3.5-9B, который летает на любой 8 гб карте. но она скучная, мозг теряет активность и внимательность, и в таком коде я вероятнее напишу -1 или +1 в каком-то месте. А так я и время сохраняю. И фокус.
2 - я могу не влезать в чужую область, и совершенствоваться в своей. Я вот сейчас устройство разрабатываю, для его управления удобно было бы использовать мобильное приложение. Я убеждён полностью, что в разработке мобильного приложения, которое выполняет лишь функцию интерфейса и не содержит никакой логики и вычислений, просто принимает данные, отсылает команды - что там есть хоть что-то, чего бы я не смог сделать сам. Сюда же попадает генерация спрайтов и анимацией картинконейросетью для прототипа игры. Предположим я демку делаю. Если я оставлю квадраты вместо текстур, а игра, например, про атмосферу и ощущения - то с квадратами будет сложно представить что выйдет. А если нарисовать криво-косо хоть что-то напоминающее реальные объекты, то будет намного проще представить как оно будет выглядеть с нормальными спрайтами и звуками.
3 - оно развивается неадекватно быстро. Картинки до диффузионных моделей, картинки sd1.0, картинки sdxl, картинки qwen-image различаются невероятно сильно, на порядки. Ещё пара таких ступеней, и даже если больше ничего непроизойдёт - это уже будет невероятной пользой. Да даже если в текущем состоянии замрёт. Это как с GPS - можно сколько угодно ругать космос и бесполезность полётов на Венеру, Сатурн и прочее - но GPS (выгода от него, экономия человеческих ресурсов) уже с запасом окупают все деньги, которые человечество потратило на все космические программы, в том числе бредовые.
4 - уже сейчас существующие модельки могут заменить очень много рабочих мест. Я сегодня подключался к карточке у себя дома и локальной сеткой смог распарсить pdf-файл, перерисовать его в файл с разметкой и поменять нужное. В сущности если не использовать pdf-файлы, а оставлять редактируемые, а ещё лучше - разработать дружелюбный для компьютеров формат документов, то все работники занимающиеся оформлением и созданием документов будут не нужны. Машины вроде как катаются. Юристы, ну, я бы предпочёл чтобы меня судила непредвзятая нейросеть, у которой будет цифровая подпись от сертифицирующего центра, что веса не были модицифированы, и чтобы можно было воспроизвести результат её работы для проверки решения. Чем человек, у которого может быть просто тьма заинтересованности, финансовой, карьерной, ещё какой + эти эксперименты где судьи с 20 лет опыта после обеда и со сладким чаем освобождаю досрочно в 3 раза чаще, и при этом на прямой вопрос влияет ли это, говорят что нет, мы не предвзяты. Не очень хочется стать жертвой такого случая (попасть до обеда или после). Если использовать сеть для обучения. У меня бы слюни текли, если бы в институте я бы мог не только спросить уставшего преподавателя между пар, который не всё знает и которому не всегда интересно ещё что-то мне объяснять, а была бы нейросеть, которая персонализированно отвечает мне. И это всё то что уже существует. Даже если дальнейшего развития не будет.

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