реклама
разместить
Польза goto в C++

TL;DR: Дейскстра учился писать код с goto, научился, раскритиковал применение goto, учебные программы усложнили т.к. “так сказал великий Дейкстра”, учить детей программированию стало сложнее.

Польза goto в C++
1212
реклама
разместить

Если это не на 1 апреля то:
1) То есть Дийкстра и другие воспарили из-за goto ? А может вопреки?

2) Каким образом это помогает понять на интуитивном уровне? Очень удобно наверное понимать как и куда прыгает что-то верно? При том что прыгнуть оно может вообще куда угодно?

3) Нет плохих языков. Язык это инструмент. Он решает задачи. Ненужно говорить что болгарка это плохой молоток. И у С++ хватает проблем причем их на столько много что диву даешься и авторы стандартов уже головы ломают как эту мусорку чинить оставляя обратную совместимость

4) Вы так отлично говорите о быстрых языках программирования что забываете что сами себя облапошили с goto. А теперь давайте вместе угадывать на сколько удобно будет процессору предиктить куда же прыгнет goto и при этом заранее положить в кеш или стэк даже не говоря о том чтобы прям в конвеере иметь инструкции дальнейшие. Там может быть все на столько неожидано что придется обращаться к хипу и тогда замечательно побежит ваша производительность. Просто шикарно!

При этом ваши разговоры о том что сейчас это десятки строк с циклами и тд...вы серьезно? А вы не думали что циклы отлично параллелятся на процессоре например? А как параллелится ваш не предиктивный goto для компилятора?

4

Понимать как исполнитель прыгает из строки с goto xxx в строку с xxx: очень просто, совпадение xxx в обеих строках интуитивно понятно обладателям интеллекта.

1

Не из-за или вопреки goto, а благодаря тому, что в начале обучения никто не прикладывал усилия для того, чтобы они вместо использования минимального базиса для создания любых программ в первый же день обучения, занимались освоением широкого базиса, который хоть и позволяет выразить эквивалентные алгоритмы, накладывает искусственные ограничения и требует больше времени для изучения.

Какого широкого? Узнать пару циклов, свич и тд? Это дофига широко согласен. Минимальный базис в виде goto даст лучше выразить эквивалентный алгоритм? Да что за дичь я читаю гсоподи. Да иногда goto удобен но это крайне иногда в большинстве алгоритмов goto ненужен при этом без потери выразительности и при этом с большей читабильностью. При этом нормальный код это не "умно сделанный" код а баланс между быстротой и поддерживаемостью и читабильностью. С goto ты в лучшем случае чуть чуть выйграешь в компактности кода и потеряешь во всем остальном.

Сколько дней ты изучал с++ и писал hello world прежде чем сумел написать на нем простенькую 2д игру и сколько тебе было тогда лет?

недели 2-3 и было лет 17-18

А вот было бы круто, если бы ты смог сделать это за 1 день и было тебе тогда лет 6-8

1

Но вопрос некорректен так как у меня был базис паскаля

То есть целых 2-3 недели ты изучал язык чтобы понять этот самый широкий базис, вместо того чтобы изучить минимальный базис и получить безграничные возможности, а далее лишь изучать способы улучшить читаемость и сопровождаемость кода?

Но вопрос вообще непонятен к чему это? Для начала выучи базовые вещи языка а затем уже бери движок и изучай

Верно. Базовые вещи языка - int, if и goto. Это базис. Выучивается за 3 минуты. И дальше изучай библиотеку.

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

Какую библиотеку ты изучишь для написания игр когда ты знаешь только int, if и goto?

Arctic Engine

хыхыыхы авторы этого движка с тобой не согласны

Авторы это я и пара моих друзей, как они со мной могут быть несогласны?

Ну тогда получается ты сам с собой не согласен?

Откуда взялась информация о том что кто-то с чем-то несогласен?

Потому что это буквально первый пример и тут уже показан while, include, namespace, void

Это пример кода на движке. Движок позволяет писать и так и эдак.

Это скрыто в начале обучения. Код, что приводит автор в этих статьях - это буквально всё, что надо написать/скопировать начинающему и компилировать.

Ровно как и scanf в нашем с тобой диалоге. Просто ровно так же скрыто

Я же там отвечал, что лучше аналог getch - в нём скрыто значительно меньше, чем в scanf.

getch даст тебе символ а не получение числа. Человеку пофиг сколько сокрыто пока это становится менее сложно. В этом и суть сокрытия сложности. Потому люди и используют высокоуровневые языки программирования. Потмоу и работает тот же язык Go и пишут на нем хотя быстрее программы работатать будут на С++ или Раст том же. Скрывает сложность.

Зачем нормальному человеку при создании игры получение числа?

Во первых тут был контекст диалога про калькулятор что написал человек

Во вторых ты серьезно? Зачем получение числа ? Я даже хз как тебе овтетить чел. Внезапно но это такая стандартная вещь что используется прям дофига где и когда

Запускаю калькулятор под windows, там нет ввода через cin или scanf, вообще ничего похожего. Запускаю doom 2016, там вводить вообще ничего не нужно, только бегать и стрелять, запускаю doki doki literature club, там вообще управление только мышкой.

Во первых scanf работает не только с cin окей? Во вторых внезапно также и сейвы например или данные какие-то уровня также можно считывать) Как будто под дурачка косишь ей богу

Сейвы считывать через scanf?

Можно через него в том числе. Можно подругому. В принципе sscanf fscanf и так далее вполне себе часто использующиеся вещи

А потом люди удивляются что сейвы грузятся по 10 минут…

Для физуальной новеллы то? Да и чтение данных это самое меньшее что занимает по времени у сейвов. Гениальный ответ

Если ты будешь делать все правильно, то при загрузке данных с ссд диска самым медленным будет именно чтение с ссд диска

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

Это какие сейвы тебе надо было грузить с диска чтобы он был узким местом?)

Будешь грузить через fscanf - узким местом будет парсинг

Ты не то чтобы не прав что это будет медленнее. НО на сколько медленее? даже какой-нибудь парсер json(не говоря уже о бинарных форматах) файла в 30 мегабайт будет около мгновенно парсится. Да можно быстрее. Но это сейв файл, а не данные мира, меш, текстуры и так далее. парсинг и загрузк это на столько мелкая вещь при созранении и загрузке что они составляют едва ли составят один процент от всего процесса загрузки

Правильно написанная загрузка будет загружать игру за время меньшее чем размер памяти делить на скорость диска

Не понял к чему ты это написал и что ты пытаешься доказать. Ты загрузишь сохранение в разы быстрее чем будешь загружать данные для этого сохранения. К чему ты это написал то? Суть использование ССД не в использовании scanf а в использовании структур данных для правильного доступа к ссд так как основное оружие ссд это мелкоблочный рандомный доступ. И ты должен подхотовить данные так чтобы ты мог мелкоблочку запрашивать и записывать эффективно не пересобирая весь файл а там хоть scanf хоть нет. Без этого толку не будет у тебя от ssd. Не пойму что ты пытаешься доказать

Случайный мелкоблочный доступ к данным на ssd в разы медленнее чем крупноблочный последовательный.

Ты не понял что я написал? Суть в том чтобы записать туда. Ведь в hdd у тебя головка будет бегать и суть случайной записи как раз в том что тебе про правильной структуре данных ты можешь этим воспользоваться переписывая файл. Само собой если у тебя блямба большая последовательная тогда будет быстрее на чтение. Но если мы говорим о сейве или данных базы уровня который будет меняться или хранить diff куда надо писать то тебе нужна структура для мелких блоков

Быстро работающий сейв выглядит как двоичный файл, загружаемый одним куском в память и не требующий парсинга кроме патчинга указателей.

Быстро работающие данные уровня и персонажей - аналогично.

Так как видеопамяти у среднего игрока редко даже 4 гигабайта, загрузка с ссд (400 мб/с на чтение) не может длиться дольше 10 секунд

Ты

1) Абсолютно гнорируешь что я сказал

2) Зачем-то приплел данные к стейту.

видеопамять и загрузка в нее это данные. Стейт это сейв. И сейв в видеопамять не загружается и 400 мб/с у САТА у тебя никогда не выйдет потому что это будет только при полном последовательном чтении всех данных. А утебя текстурка уровня в одном месте, моделька в другом, уровень в третьем, скрипты в четвертом, шейдеры в пятом

А про стейт я уже сказал и про стурктуру изменяющегося уровня

Подожди, у меня как раз все упаковано так, что все текстурки и модельки уровня, уникальные персонажи и прочее - в одном большом файле, который читается на полной скорости хоть на HDD, хоть на SSD, хоть на Bule-Ray (в крутых играх так начали делать лет 30 назад, когда появились CD диски вместо картриджей у приставок).

Общие для разных уровней персонажи, типа персонажа игрока - во втором большом файле.

Вообще все скрипты, настройки и другая мелочевка типа звуков нажатия на кнопки и шрифтов - в еще одном большом файле, который целиком подгружается еще при запуске программы одним махом. Этот файл не очень большой, например, мегабайт 16, но этого уже достаточно для чтения на полной скорости.

Сохраненная игра - еще один (в зависимости от того что за игра - или маленький или большой файл)

Кстати, современные SATA SSD читать могут даже быстрее, 500MB/s и даже 600MB/s.

То что оно в одном файле не сделает его быстрее, так как есть такая вещь как фрагментация. И твой файл может быть размазан по HDD и ты в идеале должен сделать так чтобы твои данные располагались в соответствии с этим фрагментом или же были дефрагментированы и уложены рядом. В Блю рей так вообще другая система. Так как ты должен уложить так чтобы лазер в совершал меньше движений и располагать самые частые и большие данные как можно ближе к внешнему кольцу. И это не имеет никакого отношения к упаковке. Упаковка данных сделана чуть для другого. И более того в больших играх ты не загружаешь сразу все ресурсы из пака в память так что тебе ненадо читать весь пак и потому это бесполезный способ для ускорения. Более того важен порядок хагрузки их. И на счет твоего маленького файла со скритами и шрифтми ты больше потратишь на парсинг и подгрузку данных чем на загрузку в память.

Борьба с фрагментацией - задача файловой системы, и они с этой задачей отлично справляются.

Ты принципиально не понимаешь, что парсинг файла - лишний шаг, который не должен происходить при загрузке, парсинг - лишний шаг. Файл нужно писать в формате, не требующем парсинга. Загружаешь файл в память и патчишь указатели, после этого файл - набор структур в памяти, которыми программа просто пользуется.

Процессору максимально удобно предсказывать куда прыгнет goto, это связано с тем, что место перехода известно не только во время выполнения, оно известно на этапе компиляции и явно указано в результирующем машинном коде. Безусловный переход предсказывается со 100% точностью, ведь заранее известно что он произойдёт и процессор может начать спекулятивное выполнение кода расположенного после точки перехода.

Есть плохие языки. Язык это инструмент, созданный для решения определенных задач. Как отвертка. Хорошая отвертка сделана из высокопрочного сплава и ее передают из поколения в поколение, от деда внукам, а плохая сделана из незакаленного железа и деформируется еще до того как ей закрутят первую гайку. Так и плохие языки сделаны для того же, для чего и хорошие, но сделаны плохо: программы на них работают медленно, многие вещи вообще нельзя написать, в процессе развития между версиями 2 и 3 одного языка возникает полная несовместимость.

[]