Привет аноны. 29 лет. Работаю пиццамейкером во всем известной сети. Хочу вкатиться в геймдев. Начал
Венчик
!aukDfOT6o6
16/05/25 Птн 13:38:03
№
1
Хочется узнать как всё примерно работает под капотом. И вроде бы сейчас многие с Юнити уходят?
>И вроде бы сейчас многие с Юнити уходят?
Вот тут не подскажу. Имхо, С++ это ААА проекты в геймдеве, туда сложнее попасть. Часто эмбеддед разработка. Ещё какой-нибудь HFT, но туда даже сложнее чем в AAA gamedev.
Unity как будто проще для освоения и вката, да и можно будет выкатиться в бэкенд на c#.
Тут лучше самому помониторить рынок вакансий.
Но если не торопишься, есть свободное время, то почему бы не начать с плюсов. Правда, говорят, что даже те, кто годами на них пишут, до конца их не освоили. Но какую-нибудь БАЗУ по тому, как работает память (указатели), ООП и всё такое, можно получить.
Есть же анрил, его много кто использует вроде. И мне интересно, как без чего-то готового можно было бы что-то сделать, хотя бы 2д игру уровня Марио. Я видео на ютубе нашел, оттуда картинка с оп-поста, и там сказали выбирать C++.
Я уже начал их учить, не буду менять. Думаю если будет необходимость, то перейти с одного на другое не будет особых проблем.
Насчёт работы у меня не особо горит, хотя хотелось бы конечно, как минимум из-за разницы в зп. Но я уже привык к своей, и если не получится найти другую, то и пусть.
>Есть же анрил, его много кто использует вроде.
Да, но это как правило более крупные проекты соответственно, кажется, что в них выше требования и сложнее попасть/найти работу, особенно, если ты в рф. Условно, анрил - фортнайт, ведьмак 4, Star Wars Jedi.
Хотя многие вообще используют свой движок - GTA, атсасин крид, ведьмак 3 и т.д. Там тоже скорее всего C++, взять тот же RAGE
https://rockstargames.fandom.com/wiki/Rockstar_Advanced_Game_Engine
А юнити - куча инди игр, но и не толькo. Капхед, сабнатика, амонг ас, и т.д.
В общем-то, если не к спеху, то стоит скорее ориентироваться на то, в какой геймдев ты хочешь попасть. Если делать что-то в соло или в целом что-то относительно небольшое, то юнити.
А если метишься в звёзды и особо не спешишь, то конечно плюсы.
Ну а поскольку у тебя не горят сроки, точно ничего не мешает заниматься плюсами.
>>791147
>Думаю если будет необходимость, то перейти с одного на другое не будет особых проблем.
Тут ты прав.
Будет интересно посмотреть на прогресс конкретно в геймдеве, скрины того же марио и процесса создания, если возьмёшься. Или игру про кубических коров, которые могут перемещаться во времени и между параллельными мирами... >>784686 →
Посмотрел на ХХ вакансии. 90 и 180 в пользу Юнити. На анриле вроде бы небольшие игры есть. Стрей например. Сабнатика новая тоже на анриле будет.
Пока не хочу особо думать куда. Дочитаю сайт и потом осмотрюсь.
Автор в первой функции не использовал else if, а просто ifы. Его решение наверное лучше.
Пока много текста и мало упражнений. Что самому написать идей нет.
Так же Алекс почему-то законы де Моргана описал табличкой. Хотя они довольно интуитивны. не(А и В) значит, что не должно соблюдаться и А, и В одновременно. Нас устроит, что либо опа не выполняются, либо хотя бы одно из них. Значит (неА или неВ).
>Его решение наверное лучше
Лучше switch. Странно, если про него не рассказали тут
Через 1 главу расскажут.
>>791737
>Пока много текста и мало упражнений. Что самому написать идей нет.
Можешь тут посмотреть список идей, например https://github.com/turborium/TurboTasks
Я понял constexpr просто заменяет выражения, которые можно заранее просчитать, их результатом, чтобы не тратить на это время во время работы программы. Компьютер исплняет не std::cout << 2+3, 2+3 считается заранее, и компьютер будто исполняет другой код std::cout << 5
Если я правильно понял, то вроде бы ничего сложного.
Да, опыт есть, но очень давний. Готовился к ЕГЭ по информатике, знал Паскаль. Но сдавал по итогу другие предметы. Ещё джаву пытался учить, чтобы моды для майнкрафта делать, но очень быстро, через день-два, бросил.
>Компьютер исплняет не std::cout << 2+3, 2+3 считается заранее, и компьютер будто исполняет другой код std::cout << 5
То, что ты описываешь, называется свёрткой констант, это оптимизация в компиляторе, которая работает независимо от constexpr. Мне всё же кажется, constexpr не столько про подобные оптимизации, сколько про то, чтобы сделать какие-то вычисления заранее на этапе компиляции и потом использовать результаты этих вычислений во время работы программы.
Например, ты пишешь игру в стиле ascii арта, в которой есть много разных зелий, но спрайты зелий отличаются только тем, как выглядит содержимое колбочек. Вместо того, чтобы вручную рисовать все спрайты, можно написать код, который их генерирует. Причём логичнее было бы, чтобы спрайты генерировались единожды, только во время сборки экзешника игры, вместо того, чтобы генерировать их по новой при каждом запуске игры.
Это как раз можно через constexpr сделать. Если посмотришь в примере https://godbolt.org/z/TWW4vqY1P справа на асемблер, то увидишь там длинные последовательности из .byte - это сгенерированные на этапе компиляции спрайты, которые запишутся прямо внутрь экзешника. При запуске программы эти массивы байтов просто считываются и выводятся в консоль. А если уберёшь отовсюду в коде constexpr, то тогда спрайты будут генерироваться не во время компиляции, а при каждом запуске программы.
С constexpr много нюансов связано, которые зависят в том числе от версии стандарта плюсов, там не всё так просто. И я не знаю, зачем этим забивать голову. Для меня это выглядит как гейткиперство кодинга: как будто нарочно ебут голову какой-то си плюс плюсовой хуйнёй, чтобы ты в итоге ничего не понял. С википедией то же самое: в 90% случаев статьи написаны таким языком, что если заранее с темой не знаком, то ты вообще ничего не поймёшь. Я уже не верю в то, что это всё ненарочно.
Листал /pr, наткнулся на книги Стоялрова. Прочитал введение и ещё посмотрел видео автора этой темы, что ты скинул, ПетраТурбо.
Решил скорректировать планы. Начать с Паскаля, а затем Плюсы. Но учиться буду не по Столярову, он льёт много воды, и почему-то предлагает учить потом С?
Нашёл книгу "Песни о Паскале", в ней очень много задач. Буду налегать на неё, learncpp буду почитывать и дальше, чтобы не забыть и не пришлось перечитывать, но в более медленном темпе.
Как писать в тред прогресс не знаю. Темы в книге небольшие и постить решение задач после каждой главы слишком мелко. Наверное буду писать пару раз в неделю, а не каждый(е) 2 дня.
Зачем начинать с Паскаля? Это лишнее и только время отнимет. Ты же не будешь писать на Паскуале.
>он льёт много воды
Да ладно, он смешной... Временами. Мне чем-то Гоблина напоминает, не удивлюсь, если он в своё время на тупичке сидел.
>и почему-то предлагает учить потом С
Потому что Столик я теперь буду его так называть, по-моему звучит мило шиз. Он сторонник того, что, если ты начал учить программирование не с паскаля, то ты уже обречён, и тебя ничто не спасёт (пикрил как пример; честно говоря, я хотел другой его пост прикрепить, но мне лень искать). На взрослый язык для солидных дядь (Си) по Столику можно переходить только после того как написал пару тысяч строк кода на паскале. А дальше... А что дальше? Языков других больше нет. Ну, плюсы есть, но с НЕБОЛЬШИМ нюансом — это плюсы достандартизационного образца. За один твой constexpr он тебя, вероятно, пидорнул бы подальше со своего сайта. У него есть книжка по плюсам, её даже можно прочитать, она очень тонкая и там только базовые вещи написаны, но он люто ненавидит STL, поэтому её придётся изучать отдельно. Ещё, если решишься читать, к некоторым тезисам нужно относиться с осторожностью, как например к идее о том, что лесенка из if'ов лучше, чем исключения.
Чё ещё хотел сказать... Не помню. В общем, если интересно, подробно с творчеством можно ознакомиться здесь:
https://stolyarov.info
https://linux.org.ru (здесь нужно зайти в поиск и вбить имя пользователя Croco, именно Croco, с большой буквы, там регистрозависимые ники)
http://thalassa.croco.net/doc/cpp_subset.html#cplusplus
Это самый лучший язык на самом деле, просто про это никто не знает и у него нет нормальных компиляторов (как и у других языков... я джва года назад пробовал расписать ряд стандартных функций на ассемблере, сначала не знал ассемблера и делал это через C++, и очень сильно разочаровался в компиляторах C++, они то удивительно тупые, то СЛИШКОМ умные и ПОЭТОМУ делают ЕЩЁ хуже, чем если бы были тупыми), и туториалов. Эти туториалы для оБуЧеНиЯ заведомо не будут хватать звёзд с неба, но кроме них я ничего и не видел (впрочем, и не искал), кроме вот этой страницы: https://castle-engine.io/modern_pascal, и то, 3/4 тех возможностей, что на ней расписаны, я ненавижу — всё, что связано с классами, ввиду того, что экземпляры классов нельзя разместить статически, а про ещё столько же автор не рассказал. В первую очередь про это: https://wiki.freepascal.org/management_operators, возможность создавать пользовательские управляемые типы, то есть недо-аналог конструктора по умолчанию, конструктора копирования, и (авто)деструктора в C++, не такие полезные, как в C++, потому что в Паскале (пока) нет скоупов как в C++, чтобы автовызвать деструктор раньше конца функции, но хоть что-то.
Какой прекрасный пост. Ну почему меня увлек мир ебаного гламура в свое время, и не было никого рядом (и интернета толком тоже не было), кто бы подтолкнул в волшебный мир инженерии. Я ведь учился в шараге на погромиста (в 2002 поступил), куда пошел аж в 14 лет, так раньше можно было умудриться, да. Когда я узнал про демосцену очень хотел приобрести толстенную книгу по ОпенГл (да, не совсем то, но другого про программирование непосредственно графики в магазинах не было), но чёт денег так и не нашел, а потом полез в веб и купил книгу по пхп ебаному. Впрочем даже на него забил после сдачи диплома на много лет. А когда опомнился и вкатился, все сделал неправильно. Сделал штук 30 сайтов в общей сложности, самый дорогой за 150, но обычно по 20-40 были. И все на этом. Оп, ты молодец.
>Это самый лучший язык на самом деле
Ну да, если ты НЕ хочешь делать игры и НЕ хочешь найти работу, то язык охуенный. Хотя про игры ещё можно поспорить. Примерно в 2011 я недолго ходил в кружок по программированию, в котором мы рисовали всякое на паскале (ABC.net). Несколькими годами позже он появился в школе, естественно, детский уровень. И я буквально дрочил на это видео:
https://youtu.be/kDVJexd_tpY
>Ну да, если ты НЕ хочешь делать игры и НЕ хочешь найти работу
Не стоит вскрывать эту тему. . .
Учил его в школе. Большую часть мне придется просто вспомнить. К концу упомянутый книги интересные задачи, поиск, сортировки. Буду вкатываться, если не брошу, условно 1г1м вместо 1г, разница? Learn cpp я не бросаю, просто пока что буду меньше времени уделять. Меня напрягает малое кол-во задач там.
>>792094
Не понимаю, для чего учить С, зная Паскаль? Это ведь языки одного и того же уровня, из одного и того же времени.
Другие его книги, сети, парадигмы, мне не интересны. Возможно прочту у него про ассемблер в первой, там небольшая глава.
https://www.youtube.com/@SimpleCodeIT/playlists
Главное сначала плейлист "основы", потом - "ооп". И домашки там есть, можно делать.
Спасибо за совет. Но мне намного проще воспринимать текст, чем звук, даже в школе на уроках я ничего не понимал, только после того как учебник дома читал.
По тексту ещё и поиск проще, если что-то захочу перечитать. Плюс хочу потренироваться в чтении английского. Я почти без проблем могу читать что-то не художественное, но очень быстро устаю.
вот странно вроде прям оче этот ресурс люди рекоммендуют, но я глянул и не ахти. Там автопроверка заданий есть?
Паскаль мне нравится своей словесностью, begin end выглядят приятней скобочек. Но есть один жирный минус: это секция объявлений переменных. В С++ гораздо удобней их объявлять прямо в программе. Возможно это сделано ради того чтобы мотивировать заранее продумывать что пишешь. Я и так это делаю, но продумывать до таких мелочей, сколько переменных понадобится, уже перебор.
Думал 7 главу на learncpp прочитаю быстро за пару заходов. Но ушло гораздо больше времени, и ощущение что мало что запомнил оттуда. Слишком много информации "на потом". Возможно стоит перечитать и собственноручно повбивать примеры, я же просто читал и лишь отвечал на вопросы и писал программы, заданные в упражнениях вконце главы.
Нашёл, кстати, отзыв Столярова на "Песни". Почему-то он негативный. А мне пока книжка нравится. Жаль ничего в таком стиле для С++ нет. Стиль письма "для детей" может кого-то и отталкивает, но learn cpp Алекс иногда расписывает настолько подробно, будто для людей с проблемами развития, что это становится невероятно тяжело читать. И это может соседствовать с инфой, которую уже тяжело с первого раза уловить и приходиться перечитывать, смотреть примеры.
>>792396
То что мне нравилось уже давно нет в меню. Из того что есть сейчас, наверное Диабло.
>То что мне нравилось уже давно нет в меню. Из того что есть сейчас, наверное Диабло.
Эх. Столько воспоминаний с этой пиццей. А её, оказывается, из меню убрали. Теперь ни пиццы, ни друзей, с которыми я раньше её ел, да и воспоминания уже улетучиваются.
Ты путаешь наверное. Раньше вместо Диабло была Мексиканская. Вторую на первую заменили. Сейчас Диабло всё ещё есть.
Паскаль прочёл до 20 главы. Пока там ничего нового, я это когда-то знал. В нём, кстати, switch реализован лучше. В нём нельзя провалиться в метки ниже, не нужно писать break/return, после исполнения кода относящийся к метке он автоматически выйдет из case of(паскалевский аналог switch).
Следующая 9 глава выглядит скучноватой. Но благо она коротенькая.
Столяров - полный долбоеб и хуесос. Вообще, обращайте внимание на либертарианские взгляды - за типичным лишертариашкой скрытается обыкновенный проткнутый левак-коммиглист. В случае столярыча это работает в полной мере. Де факто, Анька Столярова выступает за ограничению свободы слова, за концентрационные лагеря, за довольно примитивное рабство.
Кстати, кодить этот долбоеб при седых мудях тоже нихуя не умеет. На linux.org, его "фалассу" оценили как дикий говнокод нулевого похлеба.
Однако, не смотря на всё это, книги у Столярова действительно не плохие. Столяров умеет преподавать. И это напрямую связано с тем что он ТУПОЙ как пробка. Я заметил, что тупые люди, как правило не понимают довольно простые вещи с первого раза, и поэтому им приходится извиваться в мысленной гимнастике, ходить бессмысленными умозаключениями, чтобы прийти к конечному факту. Поэтому тупые люди способны более развернуто и подробно объяснять некоторый материал. То что умному просто лень рассказывать - тупой человек будет разжёвывать часами. Поэтому, книги Столярова пожалуй могу посоветовать. Но сам столяров - вырожденец недоразвитый. Ну, кстати это не особо страшно, детей то у него нет, этот долбоеб ведь чайлдфри. А вот недавно врачи обнаружили у него рак.. часики то тикают, а пиписька больше не стоит. Так и здохнет он плешивым душеым шизопреподом, который всю жизнь затирал студентам пол Unix-way сидя на убунту.
>Не понимаю, для чего учить С, зная Паскаль? Это ведь языки одного и того же уровня, из одного и того же времени.
Да не, абсолютно разные языки из разных эпох. Паскаль - это высокоуровневый язык, с поддержкой ООП, с полноценными юнитами и раздутым рантаймом. Паскаль ближе к, С++ чем к С.
Сишка - низкоуровневый язык, в идеале с нулевым рантаймом (хотя на практике это чаще всего не так). В С нет ни классов, ни конструкторов, и даже отдельных модулей нет - модули компилируются сразу в байткод и линкуются. А вот в Паскале на уровне языка можно подключить "модуль".
>НЕ хочешь найти работу
Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Начнем с того что "программист" - это никакой не интеллектуальный труд. Интеллектуальный труд - это псиоп. На рынке не особо нужны люди типо Рируру, рынок более заинтересован в формальном подходе и формошлёпстве. Кодишь на известных фреймворках по форме -> стабильность -> прибыль. Поэтому любой наёмный труд - это всегда рутина.
Рынок сейчас перенасыщен разного рода лодырями-кнопкодавами. Желающих плевать в потолок и получать 999ккк в секунду много, а товар сбывать некуда. Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
И это я про вакансии разработчика на Java, на Python, на PHP. Если брать во внимание C++ то он никому не всрался даже с опытом работы в 6 лет. Так что чтение книг Столярова - дело не прибыльное, в чем сам Столярчик и признаётся. Можешь почитать гостевуху, там периодически появляются вкатуны, которые прочитав все его книги не могут найти работу, на что столяров им предъявляет мол: "А сколько ты полезных программ продал, сынок". Очевидно, торговля программами сейчас уже звучит как пережиток прошлого. Новоиспечённый вкатун отвечает что ничего он не продавал - и получает ответ, что стало быть он не настоящий программист, и книгу он читал зря. Чистосердечное признание Столярова, что его книга - полная хуйня бесполезная, которая не учит никаким профессиональным навыкам.
Однако, если для тебя сама цель - не заработок денег, а создание игр, то в целом создать игру можно на чем угодно. И тут Столяров оказывается как никогда прав, когда говорит что аналогов С и С++ в настоящем мире нет, какими бы кривыми и уродливыми эти два языка не были. Никакие Javы не дают столько контроля над процессом разработки, чтобы сделать игру производительнее. Так что для разработки игр вполне себе и плюсы, и си, и паскаль подходят. Гта ре3 на плюсах чисто сделана. Doom вообще на чистом С написан.
>Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
Напомню, что в 2018 так же говорили, даже в 2012 так же говорили лол. Количество дерьма просто надо побольше знать, но так всегда и было, в 2007 я вот книжки покупал, в 2012 уже много текстовой инфы в интернетах было, но приходилось, прям сильно в коде фреймворка сидеть и смотреть че как работает, ну и т.д. инфу получать все проще и проще, поэтому и надо ее знать больше.
Насчёт байтоебства, ну кто-то же микроконтроллеры все ещё программирует... В любой профессии найти классное место сложно, и погромирование к этому приходит.
>Насчёт байтоебства, ну кто-то же микроконтроллеры все ещё программирует...
Кто-то да программирует. Пара embedded разработчиков, которых препод по блату пристроил, например. А для остальных вход закрыт. Хз, я контроллеры ковырял, прогал, на собесах на все общие вопросы по С по сетям и устройстве контроллеров ответил - всё равно не взяли. Да даже бы и если взяли, в embedded разработке денег особо много нет, там 150к потолок. Я туда чисто ради интереса пытался трудоустроиться. Если уж выкатываться в IT ради денег, то лучше в ML время потратить.
>Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Сложнее, чем на других языках, но легче, чем на паскале. Возможно. У меня несколько знакомых в 2023-2024 находили. Правда, там не backend, а embedded. С Нулевым опытом. В резюме указывали два года.
Но вообще ты прав, особенно насчёт Столярова.
А почему нет? На чистом ассемблере - идея такая себе. Но с вкраплениями ассемблера, почему бы и нет. Особенно что, вопреки тому что говорит столяров, С довольно не идеален на практике. С изначально был разработан под компьютер PDP и оптимизирован под его инструкции. Перенос языка на компилятор для x86-64 вносит некоторый хаос. Возьмём следующий фрагмент кода на языке С:
int x = 1;
x = x << sizeof(int) ⚹ 8;
Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным "1". Т.е. один и тот же код, на разных системах будет выдавать разный результат. Кроме того, компилятор под x86-64 терят довольно много производительности, так как в каком то смысле является костылем. Для решения проблем начали делать оптимизаторы, и тут отпитизаторы оказались довольно опасной штукой - создатель каждого оптимизатора сам решает каким путем оптимизировать. Т.е. в некоторых случаях, а твоей программе компилятор мог бы взять и заменить код на уязвимый, а порой может быть и вовсе работающий некорректно. Получается что программируя на С, ты не можешь гарантировать, что твоя программа будет работать вообще.
Также сам по себе С испольщует стеклвый фрейм, так что частое выполнение функций и trunk-функций даёт о себе знать в узких горлышках программы. Пока фрейм подготовится, пока процессор распердиться - на всё это уходит довольно много тактов процессора. И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда. Ассемблер, мне кажется мог бы помочь, именно вот в таких узких местах.
Интересный тред. Надеюсь ОП создаст что-то прикольное.
> trunk-функций
Что такое trunk-функция? Не гуглится вообще никак.
> Также сам по себе С испольщует стеклвый фрейм
А ты уверен, что это написано в стандарте? На x64 есть всякие fastcall-конвенции, которые кучу аргументов кидают через регистры.
Хотя, конечно, иногда вызовы функций могут быть дорогими. Константин Владимиров, например, любит показывать, как Сишный qsort сосёт у std::sort приплюснутого, потому что компиляторы C++ имеют доступ к типу объекта переданного в качестве функтора, и вследствие могут заинлайнить вызов. А компиляторы Си не могут, потому что информация о типе затирается тут, кстати, забавно вышло — я как будто говорю о компиляторах C++ и C как о разных программах, лол.
Но тут, надо понимать, имеется в виду косвенный вызов функции. А на явных, наверное, особо нет смысла экономить.
> И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда
Интерполяция текстур по треугольнику на процессоре? Софтвейр рендер делаешь что-ли? Тут, наверное, уже мало что поможет...
>Что такое trunk-функция? Не гуглится вообще никак.
Ну, типо варпер функция, которая вызвает другую функцию, чисто для инкапсуляции. Просто в дизассемблере она почему-то thunk называется, я поэтому так привык называть.
>А ты уверен, что это написано в стандарте?
Насколько я понял, в стандарте вроде бы не написано ничего вообще. Т.е. стандарт компилятора С специально оставляет "пустые места" для того чтобы разработчики сами могли решить как им реализовать ту или иную конструкцию. Из-за этого код и становится нестабильным, потому что на олной платформе он использует одни решения, а на другом - другие.
>Софтвейр рендер делаешь что-ли? Тут, наверное, уже мало что поможет...
Да)) Но мне просто интересно, вот в half-life был же вариант "software render". И всё нормально работало, не тормозило. Получается програмные рендеры всё таки в теории можно как-то оптимизировать, мб распараллелить. Почему то у меня только тормознутое говно получилось, сколько бы я не старался.
Ещё нужно изучить drm-kmod драйвера, чтобы можно было напрямую с видеокартой работать. Тогда можно аппаратный рендер добавить. Типо софтверный - общий для всех, а аппаратный - если повезёт.
>Также сам по себе С испольщует стеклвый фрейм
Да ты ёбу дал, это понятие не 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 с достаточно охуевшими флагами, я не разбираюсь) тоже мог бы это сделать.
>Да ты ёбу дал, это понятие не C, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет
Так тогда и получается, что на одной платформе, допустим битовый сдвиг будет спамит 11 в новые биты, а на другой 00. Т.е. если мы битовые сдвиги используем для расчета света, то на одной платформе текстура может оказаться белой, а на другой зелёной. В чём я не прав?
Или вот по-лучше есть пример как раз в учебнике сторярыча. Там он демонстрирует пример остаточной рекурсии. Так вот, если программу написать не используя остаточную рекурсию, т.е. чтобе стек рос по мере вызова функций, то получается, на некоторых платформах где стек не используется, программа может отработать стабильно и даже пройти все юнит тесты. Но стоит эту программу портировать на другую платформу - она рухнет со "стек оверфлоу". Насколько я знаю высокоуровневые языки типо Java эти вопросы решают при помощи собственной среды выполнения jvm, именно поэтому ими в энтерпрайсе и пользуются. А С - нет, не обязан. Т.е. имея ввиду как раз специфику и минималистичность языка, мы получаем на выходе неоднозначные компиляторы.
Во-первых, «а вы так не делайте». GIGO — это нормально, если функция не имеет какого-то однозначного результата в каком-то случае, то ему нормально быть неопределённым. В платформозависимом коде можно положиться на конкретное поведение (так-то то, что на x86 сдвиг автоматически берёт %, часто удобно), в универсальном — «не делайте так», зато не полностью определённые функции проще реализовать на всех уровнях вплоть до цены в транзисторах.
О, придумал иллюстрацию: радиус сходимости рядов для вычисления трансцендентных функций. Если тебе нужно реализовать функцию тангенса, то ты можешь использовать ряд Тейлора (или другого мужика), но у него будет радиус сходимости — π/2 (на практике радиус «быстрой сходимости» может быть ещё меньше), и если функция tan(x) нужна для произвольного x, то тебе понадобится предварительный этап argument reduction, приводящий x к нужному диапазону. Этот этап сильно сложнее, чем вычисление самого ряда (поверь) (ладно, вот здесь сравни основную функцию синуса с вспомогательной функцией k_rem_pio2, до которой доходит argument reduction в «очень плохих случаях»: https://gitlab.com/freepascal.org/fpc/source/-/blob/cb4bcaa068c86564249be6f58c28458c8fa839d0/rtl/inc/genmath.inc#L1453), так что если функция всё-таки НЕ нужна для произвольного x, то ты можешь не делать argument reduction, а вместо этого сказать, что при x > π/2 функция возвращает фигню. Это оставит тебе пространство для манёвра; ты сможешь даже поменять мужика; у нового мужика будет другой размер ч радиус или другие значения вне радиуса, но это неважно, ведь ты оставил за собой право вернуть фигню.
Метафорично, ты / Столик предлагаете мне пожертвовать возможностью прыгать по хуям ради штабильности того, что меня и ебать-то не должно.
>платформозависимом коде можно положиться на конкретное поведение
Да, при том что я вот не понимаю в чём фишка якобы "платформо-независимой" java если ошибка StakOverflow таки возникает. Т.е. вот коллеги мне мимо делом нарассказывал, что С++ - фигня, байтоёбство для дрочеров памяти, а вот в java смазка выделяется сама! ни о какой памяти думать не нужно. Но стоит сделать while(1) { new.. так сразу программа вылетает с ошибкой Out of memory. А що таке?! Почему сборщик мусора не спас? Вернее.. зачем нужен сборщик мусора, если он спасает не от всего. Получается, что вот вы сделали "высокоуровневый язык" для быстрой корпоративной разработки... казалось бы, значит нам не обязательно знать "что там под капотом". Но фактически то это не так, всё равно приходится знать что там под капотом, понимать концепции стека pop, push чтобы хоть что-то написать. Так тогда бы почему не выкинуть эту жаву и не начать байтоёбствовать. Ведь если понимать все нюансы работы с памятью, то ошибок утечки памяти избежать легко.
>так что если функция всё-таки НЕ нужна для произвольного x, то ты можешь не делать argument reduction, а вместо этого сказать, что при x > π/2 функция возвращает фигню. Это оставит тебе пространство для манёвра; ты сможешь даже поменять мужика
Ну так то мне кажется что гибкость программы идёт в разрез с её производительностью. Т.е. чем более программа примитивна, тем более она производительна. Так что каждый раз надо бы задуматься "а нужна ли универсальность в конкретно этом случае". И если функция известна заранее, почему бы не использовать готовый результат в виде таблицы, а промежуточные варианты просто с интерполировать. Даже если взять банально вычисление квадратного корня - програмно его фиг высчитаешь.
>Метафорично, ты / Столик предлагаете мне пожертвовать возможностью прыгать по хуям ради штабильности того, что меня и ебать-то не должно.
А я чё, я даже не программист. Просто сижу тут уши грею.
Столярову вообще ничего помоему не нравиться - на всё ворчит, все у него гниды и предатели, всех пристрелить "маленькими и в кроватках".
Скачал вместо этого книгу Страуструпа. Она есть во всех топах, а так же в ней много заданий. Надеюсь пойдёт так же легко, как и Паскалик.
А чё столярова не читануть. У него глава про С++ довольно урезана, т.е. там объясняются только самые базовые конструкции C++, не написано ничего ни про STL, ни про паттерны какие-нибудь. Но по сути, то что объясняется это и есть сам чистый С++. Потом, если охота можно и чего другого навернуть.
Не, не пойдёт. Страуструп ещё хуже.
Из того, что я видел, рекомендуют книгу Харви Дейтел, Пол Дейтел «Как программировать на C++».
Ещё лекции Константина Владимирова крутые и книжка Скотта Майерса «Эффективный и современный C++», но это для тех, кто уже смешарик.