Привет аноны. 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++», но это для тех, кто уже смешарик.
Почти дочитал Песни, осталось глав 10-15. Страуструп меня задушил. Перешел на видеоуроки от ChiliTomato с ютуба, дошёл до урока со Змейкой. Думаю за пару дней осилю и запощу результат.
Думал смотреть все туториалы заново, вдруг забыл что. Но пробежал глазами по вики, по уже пройденным, вроде все темы помнил. Вернулся к змейке, где и остановился. Сделал "рабочую" версию за день, но без домашки. Но решил отполировать сверх того, на что ушло ещё два дня, так же сделал домашку.
Полировка заключалась в следующем: добавил прохождение сквозь стены, что повлекло за собой следующие проблемы
1) нужно было модернизировать алгоритм перемещения
2) если на краю области есть препятствие, то при перемещении через стену змейка проходила сквозь него
Так же сделал не совсем тупую систему спавна цели и препятствий. Препятствия появляются случайно, но они НЕ могут появиться прямо перед головой змейки, внутри неё, поверх другого препятствия и поверх цели. Цель появляется случайно, и так же не может появиться внутри препятствия и змейки. Ещё, когда змейка кусает саму себя, голова не заезжает в тело, а так же она не может укусить себя за хвост.
У меня в детстве на телефоне была именно такая версия, об края не убивалась, и кусала себя без наезда поверх. Хотел добавить ещё систему жизней и очков. Но устал. Хочу двигаться дальше по туториалам.
"Песни о паскале" мало желания читать, из-за перерыва пыл поубавился, хотя книга хорошая, но консольные приложения делать скучно. Но я её почти прочел, и как раз дошел до глав с сортировками, а дальше графы. Может в будущем понадобится. Потому хочется добить, а не бросать почти в самом конце.
Норм. Богоугодная хуйня. Продолжай, мне нравится.
Ты на c++ или на паскале пишешь?
На паскале решаю только задания из книги "песни о паскале".
Змейка на с++. Учу его по видеоурокам от пика - ChiliTomatoNoodle
Ага.
>>792103
Да, отсутствие скопов оч. большой минус.
У меня тут вконце в цикле формула для индексации получается неприятной. Со скобочным скоупом можно было бы временную переменную ввести и приятней сделать. Глупый наверное пример, но всё же.
Автор не круто сделал, он этот подход с отдельными типами для массивов, просто чтобы их передавать в функции, по старой памяти из Turbo Pascal тянет (ну или формально примеры из книжки рассчитаны на компилируемость в нём... но смысл, когда всё равно все будут использовать актуальный ❤️FPC❤️).
Вот так круто: https://godbolt.org/z/Gj37han3Y. Этой фиче 27 лет, и она «базовая» в том смысле, что тупо исправляет ошибку изначального дизайна языка без каких-то сложных подкапотных механизмов (логика, по которой можно не хотеть давать ученикам, например, динамические массивы).
Автор выпустил книгу в 2010. Тогда, наверное, в учебных учреждения Турбо был всё ещё актуален. Я примерно в то время ходил в кружок по программированию. Там стояла винХП и ТурбоПаскаль.
Не знаю, зачем я туда ходил, кружок был платным. Я очень быстро перестал что-либо понимать и просто списывал у гораздо более умного друга, с кем туда и пошёл изначально.
Почему тебе нравится FPC?
Понял про себя, что мне неприятно делать несколько дел. Я из-за этого начинаю прокрастинировать. Если сфокусироваться на одном, то могу потратить много времени занимаясь этим. Потому зря, наверное, начал Паскаль параллельно. С играми в прошлом так же было, кстати. Никогда не играл в несколько игр параллельно, а выбирал одну и играл пока не пройду/надоест.
Но осталось совсем немного, учитывая что две последние главы филлерные, надеюсь за две недели точно добью и полностью сосредоточусь на курсе от Чили.
Книга в целом отличная, но лично мне она не подходит. В книге много мелких простых заданий, мне же больше по душе делать что-то одно и большое. Как выше змейку например. Или можно делить на мелкие подзадачи, но чтобы они были ступеньками к чему-то большому, а не независимыми.
Ну и автор очевидно по послесловию метил в школьников стремящихся к олимпиадами. Я уже 10+ лет не школьник и олимпиадные задачи не вызывают интереса.
Написал двоичный поиск. Почему-то очень долго тупил, как его написать, минут 20 размышлений потребовалось, чтобы дойти до введения переменных для левой/правой границы.
Существует корреляция между копать глубоко в любимый стак и "мне не важна зп, работа, ирл".
1 месяц c#
2 месяца unity
3 первая игра для вебплощадок.
Итого полгода.
БАЛЯ я тоже делал змейку на js. Zero rubles income.
Нет, чувак. Ты хоть работал когда нибудь? На работе нужно быть по сути удобным инструментом. Но собеседование смотрят сколько лично ты полезных проектов сделал на каком-то конкретном языке. Ключевое слово "полезных". Если ты сделал змейку, и хорошо знаешь синтаксис языка - полетишь пинком под зад.
Я бы возможно так поступил, будь у меня идея для игры. Она есть, но очень мутная и трудноосуществимая.
Если бы я хотел работать, то я бы хотел, скорее, создавать инструменты для создания игр, а не сами игры.
Я получаю менее половины от 100к. На жизнь хватает, но впритык, и у меня есть своё жилье.
>>817032
Я её делал просто как задание из уроков. Причём тут инкам?
https://wiki.planetchili.net/index.php/Beginner_C%2B%2B_Game_Programming_Tutorial_14
Здесь на скрине у меня была логическая ошибка. Первое это условие выхода l=m. Если n > Arr[m], то l:=m, и досрочный выход.
Можно поставить условие l=r. Допустим мы пришли к виду [][]LR[][], тогда m = L, и если n < Arr[m], то R:=L и выходим из цикла. Но если n > Arr[m], то L=m, бесконечный цикл.
Выход не дать ползункам застрять на месте, объявить l:=m+1 или r:=m-1; И условие выхода если ползунки разойдутся, l>r;
Книгу песни о Паскале я дочитал. В общем книга хорошая, но довольно объемная, много тривиальных заданий. Я изначально начал решать все, не пропуская ни одного, но к концу это надоело, но тк я до этого решал все, то и дальше хотелось решать все, что замедляло. Если её сократить, то была бы прям очень хорошая. Не знаю, почему она не понравилась Столярову.
В целом аноны выше были правы. Не стоило распыляться на Паскаль. Хотя, может, опыт из него и из решения заданий позволит быстрее осваивать С++, чем если бы его не было. Песни оканчивались адресами, динамическими переменными, графами и поиском кратчайшего пути на них. Потратил на всю книгу где-то 60-70 дней. Это дни когда я открывал и что-то делал, между ними были пропуски. Но мог сделать 1-2 заданий за 20 минут и закрыть. И следующие сделать в другой день, потратив так же не много времени.
Продолжаю проходить beginner плейлист от Chili. Почти закончил, осталось несколько уроков. На клон арконойда потратил дня 3, делал после работы. Приветствующей картинки и в случае проигрыша нету, тк инструмент для конвертации картинок не скачать, ссылки мертвые. Дольше всего думал как заставить мерцать в случае упадка мяча, и как сделать отскок зависящим от расстояния.
Кстати сменил работу. Но оказалось на более худшую, тяжелее и меньше свободного времени. Месяца 3 проработаю и буду искать другую.
>Не знаю, почему она не понравилась Столярову.
А что вообще когда либо нравилось столярову? Старый перд, ничего не любит, сидит в своём сербском щитхоле, от рака дохнет.
>Хотя, может, опыт из него и из решения заданий позволит быстрее осваивать С++
Бля, уже несколько месяцев прошло, ты до сих пор учебник не выбрал. Бери второй том столярова по С, и третий по С++, потом досыпь STL и норм будет. Учебники у него нормальные.
>ты до сих пор учебник не выбрал
Почему? Учебник нет, но я по плейлисту, видеоурокам учусь. Почти beginner плейлист закончил, осталось 3 урока, я сейчас на 22, сегодня его закончу и останутся лишь два.
https://www.youtube.com/@ChiliTomatoNoodle/courses
Ну ладно.
Но пикрил выглядит дебильтно. Во-первых обучение програмиированию не связано с векторной алгеброй. Хз зачем там насыпали матрицы и векторы - это всё на первом курсе в университете объясняют, понять как работает С++ это вообще не даёт. Камон, урок называется "С++", а обучают векторной алгебре - что за ебланство. Векторы можно хоть на С, хоть на Паскале, хоть на ассемблере реализовать. У столярова как раз плюс в том что акцент сделан именно на самом языке. То есть вот что такое С, и почему С - не паскаль? Потому что С - низкоуровневых язык, с околонулевым рантаймом, там каждая операция производит некоторые действия с памятью. Там даже есть глава "программа на С без стандартной библиотеки" которая демонстрирует чем по своей сути является С, и почему нововведения из gcc выглядят довольно нелепо. В следующий книге уже идёт повествование о С++, и там уже наглядно поясняется разница между низким байтоёбским уровнем, и высоким. То есть что такого делает компилятор С++, что позволяет сократить труд по программированию. Например вот пишешь ты void func(int a) - на обычном С под функцию строго выделяются байты. А в С++, на самом деле выделяются байты под функцию _int_func, чтобы её можно было перегрузить и сделать такую же но _float_func допустим. И компилятор в зависимости от аргумента выберет необходимую.
Чем это полезно вообще? С++ довольно топорный и низкоуровневый. Если не понимать как он устроен то можно подумать что он не работает как нужно. На самом деле он просто странный - создатели и добавили в него "высокоуровневые фишки" при этом байтоёбство оставили. В итоге получилось что-то всратое, но говорят что полезное, так как производительность он всяко больше выдаёт.
Во-вторых, если ты чисто хочешь разрабатывать игры, то зачем тебе разрабатывать графику, и зачем тебе С++? Разработка игр сводится к написанию скриптовухи, и разработке моделек. Это довольно душное занятие. Если начать писать свою графику, в какой-то момент поймёшь что нахуй эти видеоигры вообще нужны.
У Chili цель с 0, без опыта в программировании, обучить C++ и потом directX11. У него несколько плейлистов.
Начинающий: самые основы, переменные, их типы, операции, функции, циклы и условия. Так же классы, массивы, перегрузка операторов.
Опытный: там уже разные низкоуровневые и не очень вещи. Указатели например.
3д основы: графика без использования готовых инструментов. Там уже про векторы и матрицы.
directX: графика с использованием directX
Выше копии игр - это домашние задания из этого курса. Изначально он дал лишь функцию, закрашивающую пиксели по координатам.
Первые 2 плейлиста они именно про C++. Да, в уроках используются векторы, но просто для удобства, чтобы не писать int x, int y, а писать Vec2 point. Матрицы и нетривиальные операции над векторами у него уже после Intermediate плейлиста, я не скоро до них дойду.
Я проскользил по диагонали Столярова, часть про С. Интересно было, что в С нет главной программы, как в Паскале, и что можно без библиотек что-то делать. Я потом, наверное, всё это прочту чуть немного поподробней. Вкладывать много времени в С не хочу. Да и у меня сейчас времени не особо много, после работы часа 3 остается.
Про игры. И я изначально писал, что мне интересно сделать что-то, пусть и примитивное, не используя что-то готовое. И в каком-то видео, что на ютубе наткнулся, говорилось что вот учи C++.
У меня нет в голове идей игры, которую мне бы горело сделать. В этом случае я бы начал с Юнити или Анрила.
>Опытный
>там уже разные низкоуровневые и не очень вещи. Указатели например
Указатели - это уровень новичков. Они и в паскале и в С есть. Из твоего описания я всё больше убеждаюсь что видеокурс - полное говно, раз там указатели ставят на уровень "опытный". А if-else это уровень "Эксперт" в рамках данного видеокурса?
При том что нелепость С++ заключается ни в указателях, и не в конструкциях. Нелепость заключается в том что компилятор берёт на себя только рутинную часть некоторых действий, и в итоге получается "ни вашим ни нашим" - т.е. с одной стороны там можно писать классы, с другой стороны, их всё равно приходится колхозно инициализировать как на С, получается каша. Я и сам если честно когда пишу на С++ постоянно голову ломаю над реализацией тех или иных классов, и в итоге прихожу к тому что на С, это можно было бы сделать куда проще и быстрее, при этом удобство использования не сильно ухудшается - один хуй и там и там одинаковые количество кода. Но иногда С++ действительно быстрее, вот тот же TCP сервер намного более гибким получается на С++, нежели чем на С. На сишке выходит всратая портянка функций, что в любом случае переделывать нужно, на С++ достаточно поменять начледников базовой функции - считай переоборудовал сервер под всё что хочешь.
>3д основы: графика без использования готовых инструментов. Там уже про векторы и матрицы.
directX: графика с использованием directX
Нахуя вно нужно? Ну я под opengl прогал и свой рендер сделал. И как это помогло игры создать? Да никак. Мне лень писать игры. А было бы не лень - писал бы на годоте.
>Матрицы и нетривиальные операции над векторами у него уже после Intermediate плейлиста
Опять же, это уроки программирования? А какого хуя они объясняют математику за первый курс? Очевидно тупорылые индусы без образования впервые увидели матрицы и поэтому решили в свой говновидеоурок их впихнуть.
>я изначально писал, что мне интересно сделать что-то, пусть и примитивное, не используя что-то готовое. И в каком-то видео, что на ютубе наткнулся, говорилось что вот учи C++.
Он пиздабол. Язык не так важен, хоть на паскале пиши. Ну да ладно, пофиг, ебош. Может что-то весёлое закодишь!
Там не только про указатели. Но и про другие вещи. Вот кусок оглавления.
В общем не хочу тратить время на защиту, но не понимаю твою предвзятость.
>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
>А какого хуя они объясняют математику за первый курс? Очевидно тупорылые индусы без образования впервые увидели матрицы и поэтому решили в свой говновидеоурок их впихнуть.
Я их не знаю. Я не учился в университете. У меня только 11 классов.
>Вот, попробуй прочитать эти статьи и реализовать графику на паскале
Я работаю 6/1, после работы часа 3 остается свободных. Потому уроки выше для меня просто удобнее, чем копаться по всему интернету. У меня нет кучи свободного времени сейчас.
Пару тройку сообщений выше, писал, что сменил работу. Не совсем по своему желанию. Получаю около 45-50.
Ещё скажи что литкод не дрочат на собесах.
>Если ты не конченный долбоеб, то теле сложно будет не заметить что твоя программа тратит такты процессора на отрисовку мусора.
Чел, ты серьёзно, это нереально заметить без специального расследования, вспомни ту историю с O(N²) разбором JSON в GTA V, или миллион таких же историй. Даже если твоя программа очевидно критически тормозит и ты досконально помнишь, как ты её писал и что конкретно сделал плохо, ты в общем случае не можешь взять и сказать, что из этого, и из этого ли вообще, послужило причиной. Моя личная ИСТОРИЯ ИЗ ЖИЗНИ, от которой я охуел больше всего (https://www.mail-archive.com/[email protected]/msg42870.html) — это когда расследуя такой случай, я совершенно неожиданно выяснил, что Windows тихонько меняет приложениям, запускаемым под отладчиком, системную функцию HeapAlloc на её очень-очень-ОЧЕНЬ-ОЧЕНЬ медленную отладочную версию с 10 МИКРОсекундами на аллокацию, при минимальном использовании менеджера памяти доминирующую к хуям всё, что ты там из своего кода наоптимизируешь. А это системный код, не мой и не RTL.
И вот немного смежная и уже совсем недавняя история из жизни; ищется пост Торвальдса про это (https://www.reddit.com/r/programming/comments/24gr79/linus_on_the_cost_of_page_fault_handling/). Вот есть низкоуровневые функции запроса памяти у операционной системы, либо занулённой (в kernel-colored glasses это называется «спроецированной в своп»), либо спроецированной в файл, типа VirtualAlloc/MapViewOfFile или линуксовой mmap, ну классные функции, ещё и бесплатно зануляют или автоматически обмениваются информацией с диском, круто же? Оказывается, по умолчанию каждые 4096 байт памяти, выделенной этими функциями, при твоём первом их трогании невидимо приводят к пейдж фолту, который заполняет эту страницу нужными данными (ну, задним числом это очевидно; но всё равно я бы на месте системы фолтил побольше 1 страницы за раз, по крайней мере при очевидно последовательном паттерне доступа). По моим подсчётам, такой пейдж фолт стоит порядка 4'500 тактов, то есть порядка 1 такта/байт просто как едино- (или даже не едино-)временная цена в пересчёте на каждый потроганный байт. Это может быть не так много на общем фоне (Торвальдс упоминает 5% времени реальной работы, проводимого в таких фолтах, что всё ещё неприятно), но всё равно, до того, как я заметил, что хотя сами по себе эти функции быстрее, но если брать всю работу в целом, то за счёт фолтов VirtualAlloc внезапно проигрывает, в терминологии Pascal, FillChar, а MapViewOfFile внезапно проигрывает ReadFile/WriteFile, моё отношение к этим функциям было таким же, как у среднего человека из интернета: «О-ОО, ЗАЕБИСЬ, БЕСПЛАТНЫЕ НУЛИ / БЕСПЛАТНОЕ ОТОБРАЖЕНИЕ ПРЯМО НА ФАЙЛОВЫЙ КЭШ ОС».
>Чел, ты серьёзно, это нереально заметить без специального расследования, вспомни ту историю с O(N²) разбором JSON в GTA V
Ну мы же говорим про задачки школьного уровня. Тут достаточно просто посмотреть какой набор данных ты отправляешь в программу и какой в итоге на выходе получаешь. Это ещё и всё визуально. Стандартная программа создающая перспективную проекцию, в частности способна масштабировать треугольник. Очевидно же, что значения могут принимать хоть до миллиарда. Если вспомнить о том что переменные ещё и переполнятся, то само собой это коллапс. Нельзя так программу написать. Когда пишешь на С первым же делом думаешь, а что вообще в эти переменные будет записано, знаем ли мы диапазон, хватит ли его. В первых же главах книги Столярова как раз продемонстрирована уязвимость переполнения буфера - когда никто не подумал о том сколько байт вообще может быть записано, в итоге можно в стек коды возврата написать. Так что клиппинг всего подряд - это всё равно что обработка ввода. Когда ты вводим данные с потока, мы же всегда рассматриваем вообще все ситуации, что там могут ввести. Иначе тупо получается. Плюс в однопоточных программах профайлер всегда под рукой - запилил посмотрел что у тебя такты крадёт.
>это когда расследуя такой случай, я совершенно неожиданно выяснил, что Windows
Ну это ж получается ошибка винды, а не твоя. В зависимости от компилятора С результат тоже может быть довольно разный, С же для pdp создан, а не для x86. Чё мне за ошибки компилятора отдуваться?
>Оказывается, по умолчанию каждые 4096 байт памяти, выделенной этими функциями, при твоём первом их трогании невидимо приводят к пейдж фолту
Проблемы Пинуса Тормоза. Не я же этот mmap кодил. Нормально делай - нормально будет. В чем смысл оправдывать ошибки программистов тем что это "не очевидно" - они ж спецы своего дела, для них должно быть очевидно. За что им деньги платят?
Смотря каких собесах. Если в Яндекс или Тинькофф, то там не только литкод, там вообще заставят пазлы собирать. Бигтех хуле. А в среднеконторах пох.
Не, бигкеки могут пройти нахуй, особенно яндых, лучше уж дворником.
Не, а чё ради престижа можно было бы поработать. Но в бигтехи сто проц не возьмут. Хз вообще как туда устраиваются.
Наёбка для видешов.
Но таким можно заниматься когда у тебя уже закрыты все базовые потребности и на счёт капают деньги с ренты и ты можешь себе позволить тратить своё время на проекты от которых не будет никакого выхлопа.
>сколько усилий придётся вложить что бы запилить каэску на асме
Каеска посложнее будет. Там клиент-серверная архитектура с Quake 3, где события предсказываются заранее.
Это не ошибки и так надо (по крайней мере иногда), в частности, этот прикол с пейджфолтами идентичен в Windows и Linux и следует из идеи виртуальной памяти и паттернов её использования, это просто НЕОЧЕВИДНЫЕ примеры того, куда может улететь твоё время CPU без того, чтобы ты как программист предварительно пошёл нахуй по причине конченый долбоёб и сам виноват. Никто не виноват и всё работает как задумано, но знать, как именно работает, полезно для здоровья.
Уроки нравятся, потому что в них не консольные проекты. Надеюсь допройду все плейлисты до конца не забросив. Перехожу к intermediate.
Ну давай рассказывай, что такое остаточная рекурсия, и как не засрать стек.
>что такое остаточная рекурсия
Не знаю.
>и как не засрать стек
Ну, нужно что бы было какое-то условие, которое не даст бесконечно проваливаться в вызов функции.
Всё что я могу сейчас ответить.
> и как не засрать стек.
А на C++, по-моему, никак. Там хвостовая рекурсия по стандарту не схлопывается в цикл, если ничего не поменялось за последнее время.
Более того, инстанциацией шаблонов можно уронить стек во время компиляция. Метастековерфлоу... Господи, наконец-то мы в будущем.
Да по сути незачем. Я пару раз пытался выебнуться что-то рекурсивное закодить, в итоге пришёл к выводу что это неудобно, любая неостаточная рекурсия забъет стек, а остаточной по сути только изредка пару раз ей можно выебнуться. В остальном while всё заменяет. А если ограничивать количество итераций, то вообще не понятно зачем рекурсия нужна.
Как бы ты все пустые клеточки раскрыл? Ты ведь не знаешь заранее, сколько шагов придется делать, в случае цикла. Легко придумать такой алгоритм
раскрыть клеточку
если в клеточке записан 0, то
@раскрыть соседа
@@если в клеточке-соседа записан 0, то //иначе перейти к следующему
@@@раскрыть эту клеточку...
Я об рекурсии думаю как о простой подстановке текста. Сам ты не знаешь, сколько раз его придется подставлять, но компьютер может проверять условие и на основе него делать выбор.
[раскрыть соседа
если в клеточке-соседа записан 0, то A] = A
Я пытался через do-while, но там тоже получается, что нужно один и тот же текст подставлять друг за другом, и заранее неизвестно, сколько раз это придется сделать.
>Ты ведь не знаешь заранее, сколько шагов придется делать, в случае цикла.
Для этого есть цикл while. Рекурсивную функцию можно развернуть через while. А стек можно сделать вручную, выделив в куче заранее оптимальные количество места - при необходимости расширить.
>Я пытался через do-while, но там тоже получается, что нужно один и тот же текст подставлять друг за другом, и заранее неизвестно, сколько раз это придется сделать.
Скидывай. Го оценим. Рекурсивные функции в ряде случаев получаются короче и универсальнее. Вот только они жрут стек, а он ограничен. Если у тебя программа имеет возможность свалиться в stack overflow то это ж говнокод. Вот у меня была функция которая прошаривает каталоги в поисках файлов браузера. А что если там кто-то запихнет сотню каталогов - бах, программа вылетела. Ну это кал. А остаточной рекусией тут не сделать, потому что чтобы освободить стек нужно вернуться из функции, а пока мы прошариваем граф нам нельзя возвращаться из функции.
Бывают такие штуки, называемые деревьями, рассмотрим https://ru.wikipedia.org/wiki/Двоичное_дерево_поиска — специальные деревья, у которых в каждом узле есть ссылки на два поддерева, одно с меньшими элементами, другое — с большими.
Эта структура по своей природе рекурсивна: поддеревья каждого узла сами по себе являются такими же деревьями, и к ним применимы те же функции. Например, обход такого дерева по возрастанию проще, очевиднее, да, в принципе, и эффективнее всего сделать как https://godbolt.org/z/3vKrxWjnM.
Ну и чё и чего, при помощи цикла while тоже обходятся
С аппаратным стеком быстрее (это, кстати, у Столика было)
Не.. погоди... Падажжи ёмана. У нас же не чистый ассемблерный pop/push, у нас идёт операция вызова функции, там стековый фрейм целый нужно создать.
Если у нас рекурсивная программа обрабатывает произвольные пользовательские графы типо каталогов - то всё её использовать ни в коем случае нельзя. Пусть она хоть в тысячу раз быстрее - пользователь запросто может переполнить стек. Представь что ты программу на сервере запустил и какой-то подлец специально решил накидать в неё кала чтобы вызвать dos.
Если у нас данные ограничены, то почему бы не использовать while + локальные переменные? Думаешь операция вызова функции быстрее чем while? Чёто помниться через профайлер дороже выходило.
> там стековый фрейм целый нужно создать
Как будто что-то прям уж тяжёлое.
> Если у нас данные ограничены, то почему бы не использовать while + локальные переменные
Потому что для обхода того же дерева нужно будет использовать свой самодельный тяжёлый стек. Хотя, может можно и без стека. А может и не можно. Незнаю, чото лень мне думать сейчас.
>When the Stack is fully implemented and the program is executed, there are 8 test routines that will be run. All test routines should output 'Passed' to the console for the homework to be considered solved. Furthermore, the heap memory will be monitored at the end of the program and any dynamic memory that has not been freed will trigger a diagnostic error message. It is required that no diagnostic error be output for the homework to be considered solved.
Так как я уже имел дело с связными списками в Паскале, и стэк и очереди делал, думал будет легко. Но копи-конструктор и оператор присваивания были незнакомы, и пришлось потратить намного больше времени, чем ожидал. Хотя код получился простой.
Сделал 7 урок. Модифицировал змейку, теперь она настройки достает из файла. Возможно не лучшим образом, сделал отдельный класс, его конструктор читает файл и заполняет данные в него. Затем уже другие конструкторы берут информацию из этого класса, данные сделал публичными. Сейчас буду смотреть решение автора.
С с++ потоками и строками чувствую себя неловко. С с-строками, о которых он рассказывал в первых уроках, чувствовал себя так же.
Может в будущем стоит потратить время на какие-нибудь задачи, на работу с вводом/выводом, файлами. В Паскале это всё ощущалось гораздо уверенней.