14 Кб, 480x360Привет аноны. 29 лет. Работаю пиццамейкером во всем известной сети. Хочу вкатиться в геймдев. Начал учить C++ по сайту learn cpp com. Буду постить прогресс.
10 Кб, 283x141Пока что писать особо нечего. Прочел 4 главы. Читаю 5. Упражнения сложностей пока не вызывали.
>>1044
Хочется узнать как всё примерно работает под капотом. И вроде бы сейчас многие с Юнити уходят?
Хочется узнать как всё примерно работает под капотом. И вроде бы сейчас многие с Юнити уходят?
>>1111
Вот тут не подскажу. Имхо, С++ это ААА проекты в геймдеве, туда сложнее попасть. Часто эмбеддед разработка. Ещё какой-нибудь HFT, но туда даже сложнее чем в AAA gamedev.
Unity как будто проще для освоения и вката, да и можно будет выкатиться в бэкенд на c#.
Тут лучше самому помониторить рынок вакансий.
Но если не торопишься, есть свободное время, то почему бы не начать с плюсов. Правда, говорят, что даже те, кто годами на них пишут, до конца их не освоили. Но какую-нибудь БАЗУ по тому, как работает память (указатели), ООП и всё такое, можно получить.
>И вроде бы сейчас многие с Юнити уходят?
Вот тут не подскажу. Имхо, С++ это ААА проекты в геймдеве, туда сложнее попасть. Часто эмбеддед разработка. Ещё какой-нибудь HFT, но туда даже сложнее чем в AAA gamedev.
Unity как будто проще для освоения и вката, да и можно будет выкатиться в бэкенд на c#.
Тут лучше самому помониторить рынок вакансий.
Но если не торопишься, есть свободное время, то почему бы не начать с плюсов. Правда, говорят, что даже те, кто годами на них пишут, до конца их не освоили. Но какую-нибудь БАЗУ по тому, как работает память (указатели), ООП и всё такое, можно получить.
>>1129
Есть же анрил, его много кто использует вроде. И мне интересно, как без чего-то готового можно было бы что-то сделать, хотя бы 2д игру уровня Марио. Я видео на ютубе нашел, оттуда картинка с оп-поста, и там сказали выбирать C++.
Я уже начал их учить, не буду менять. Думаю если будет необходимость, то перейти с одного на другое не будет особых проблем.
Насчёт работы у меня не особо горит, хотя хотелось бы конечно, как минимум из-за разницы в зп. Но я уже привык к своей, и если не получится найти другую, то и пусть.
Есть же анрил, его много кто использует вроде. И мне интересно, как без чего-то готового можно было бы что-то сделать, хотя бы 2д игру уровня Марио. Я видео на ютубе нашел, оттуда картинка с оп-поста, и там сказали выбирать C++.
Я уже начал их учить, не буду менять. Думаю если будет необходимость, то перейти с одного на другое не будет особых проблем.
Насчёт работы у меня не особо горит, хотя хотелось бы конечно, как минимум из-за разницы в зп. Но я уже привык к своей, и если не получится найти другую, то и пусть.
>>1147
Да, но это как правило более крупные проекты соответственно, кажется, что в них выше требования и сложнее попасть/найти работу, особенно, если ты в рф. Условно, анрил - фортнайт, ведьмак 4, Star Wars Jedi.
Хотя многие вообще используют свой движок - GTA, атсасин крид, ведьмак 3 и т.д. Там тоже скорее всего C++, взять тот же RAGE
https://rockstargames.fandom.com/wiki/Rockstar_Advanced_Game_Engine
А юнити - куча инди игр, но и не толькo. Капхед, сабнатика, амонг ас, и т.д.
В общем-то, если не к спеху, то стоит скорее ориентироваться на то, в какой геймдев ты хочешь попасть. Если делать что-то в соло или в целом что-то относительно небольшое, то юнити.
А если метишься в звёзды и особо не спешишь, то конечно плюсы.
Ну а поскольку у тебя не горят сроки, точно ничего не мешает заниматься плюсами.
>>1147
Тут ты прав.
Будет интересно посмотреть на прогресс конкретно в геймдеве, скрины того же марио и процесса создания, если возьмёшься. Или игру про кубических коров, которые могут перемещаться во времени и между параллельными мирами... >>784686 →
>Есть же анрил, его много кто использует вроде.
Да, но это как правило более крупные проекты соответственно, кажется, что в них выше требования и сложнее попасть/найти работу, особенно, если ты в рф. Условно, анрил - фортнайт, ведьмак 4, Star Wars Jedi.
Хотя многие вообще используют свой движок - GTA, атсасин крид, ведьмак 3 и т.д. Там тоже скорее всего C++, взять тот же RAGE
https://rockstargames.fandom.com/wiki/Rockstar_Advanced_Game_Engine
А юнити - куча инди игр, но и не толькo. Капхед, сабнатика, амонг ас, и т.д.
В общем-то, если не к спеху, то стоит скорее ориентироваться на то, в какой геймдев ты хочешь попасть. Если делать что-то в соло или в целом что-то относительно небольшое, то юнити.
А если метишься в звёзды и особо не спешишь, то конечно плюсы.
Ну а поскольку у тебя не горят сроки, точно ничего не мешает заниматься плюсами.
>>1147
>Думаю если будет необходимость, то перейти с одного на другое не будет особых проблем.
Тут ты прав.
Будет интересно посмотреть на прогресс конкретно в геймдеве, скрины того же марио и процесса создания, если возьмёшься. Или игру про кубических коров, которые могут перемещаться во времени и между параллельными мирами... >>784686 →
112 Кб, 724x696Дочитал 5ую главу. Сделал задание. Сначала ввод имени/возраста сделал блоками, потом догадался, что можно в функцию вывести. Так же это позволяет сделать и имя и возраст константами, потому что нельзя написать int x{ std::cin >> x };
>>1348
Посмотрел на ХХ вакансии. 90 и 180 в пользу Юнити. На анриле вроде бы небольшие игры есть. Стрей например. Сабнатика новая тоже на анриле будет.
Пока не хочу особо думать куда. Дочитаю сайт и потом осмотрюсь.
Посмотрел на ХХ вакансии. 90 и 180 в пользу Юнити. На анриле вроде бы небольшие игры есть. Стрей например. Сабнатика новая тоже на анриле будет.
Пока не хочу особо думать куда. Дочитаю сайт и потом осмотрюсь.
115 Кб, 992x586Сегодня ничего не хотелось делать. Но вчера почти дочитал 6 главу, потому нашёл силы добить.
Автор в первой функции не использовал else if, а просто ifы. Его решение наверное лучше.
Пока много текста и мало упражнений. Что самому написать идей нет.
Так же Алекс почему-то законы де Моргана описал табличкой. Хотя они довольно интуитивны. не(А и В) значит, что не должно соблюдаться и А, и В одновременно. Нас устроит, что либо опа не выполняются, либо хотя бы одно из них. Значит (неА или неВ).
Автор в первой функции не использовал else if, а просто ifы. Его решение наверное лучше.
Пока много текста и мало упражнений. Что самому написать идей нет.
Так же Алекс почему-то законы де Моргана описал табличкой. Хотя они довольно интуитивны. не(А и В) значит, что не должно соблюдаться и А, и В одновременно. Нас устроит, что либо опа не выполняются, либо хотя бы одно из них. Значит (неА или неВ).
57 Кб, 800x526>>1746
Через 1 главу расскажут.
Через 1 главу расскажут.
Оп, а ты до этого на других языках программировал? Просто мне кажется довольно неадекватным, что ты только начал, а тебе уже впихивают constexpr сразу после объяснения того, что такое переменные и условные операторы. Про массивы рассказывается вообще только в 16 главе, а перед этим куча гораздо менее важных вещей. Как будто это всё рассчитано на тех, кто уже умеет программировать
>>1737
Можешь тут посмотреть список идей, например https://github.com/turborium/TurboTasks
>>1737
>Пока много текста и мало упражнений. Что самому написать идей нет.
Можешь тут посмотреть список идей, например https://github.com/turborium/TurboTasks
На реддите и других ресурсах этот курс советуют часто.
Я понял constexpr просто заменяет выражения, которые можно заранее просчитать, их результатом, чтобы не тратить на это время во время работы программы. Компьютер исплняет не std::cout << 2+3, 2+3 считается заранее, и компьютер будто исполняет другой код std::cout << 5
Если я правильно понял, то вроде бы ничего сложного.
Да, опыт есть, но очень давний. Готовился к ЕГЭ по информатике, знал Паскаль. Но сдавал по итогу другие предметы. Ещё джаву пытался учить, чтобы моды для майнкрафта делать, но очень быстро, через день-два, бросил.
Я понял constexpr просто заменяет выражения, которые можно заранее просчитать, их результатом, чтобы не тратить на это время во время работы программы. Компьютер исплняет не std::cout << 2+3, 2+3 считается заранее, и компьютер будто исполняет другой код std::cout << 5
Если я правильно понял, то вроде бы ничего сложного.
Да, опыт есть, но очень давний. Готовился к ЕГЭ по информатике, знал Паскаль. Но сдавал по итогу другие предметы. Ещё джаву пытался учить, чтобы моды для майнкрафта делать, но очень быстро, через день-два, бросил.
112 Кб, 1137x839>>1809
То, что ты описываешь, называется свёрткой констант, это оптимизация в компиляторе, которая работает независимо от constexpr. Мне всё же кажется, constexpr не столько про подобные оптимизации, сколько про то, чтобы сделать какие-то вычисления заранее на этапе компиляции и потом использовать результаты этих вычислений во время работы программы.
Например, ты пишешь игру в стиле ascii арта, в которой есть много разных зелий, но спрайты зелий отличаются только тем, как выглядит содержимое колбочек. Вместо того, чтобы вручную рисовать все спрайты, можно написать код, который их генерирует. Причём логичнее было бы, чтобы спрайты генерировались единожды, только во время сборки экзешника игры, вместо того, чтобы генерировать их по новой при каждом запуске игры.
Это как раз можно через constexpr сделать. Если посмотришь в примере https://godbolt.org/z/TWW4vqY1P справа на асемблер, то увидишь там длинные последовательности из .byte - это сгенерированные на этапе компиляции спрайты, которые запишутся прямо внутрь экзешника. При запуске программы эти массивы байтов просто считываются и выводятся в консоль. А если уберёшь отовсюду в коде constexpr, то тогда спрайты будут генерироваться не во время компиляции, а при каждом запуске программы.
С constexpr много нюансов связано, которые зависят в том числе от версии стандарта плюсов, там не всё так просто. И я не знаю, зачем этим забивать голову. Для меня это выглядит как гейткиперство кодинга: как будто нарочно ебут голову какой-то си плюс плюсовой хуйнёй, чтобы ты в итоге ничего не понял. С википедией то же самое: в 90% случаев статьи написаны таким языком, что если заранее с темой не знаком, то ты вообще ничего не поймёшь. Я уже не верю в то, что это всё ненарочно.
>Компьютер исплняет не std::cout << 2+3, 2+3 считается заранее, и компьютер будто исполняет другой код std::cout << 5
То, что ты описываешь, называется свёрткой констант, это оптимизация в компиляторе, которая работает независимо от constexpr. Мне всё же кажется, constexpr не столько про подобные оптимизации, сколько про то, чтобы сделать какие-то вычисления заранее на этапе компиляции и потом использовать результаты этих вычислений во время работы программы.
Например, ты пишешь игру в стиле ascii арта, в которой есть много разных зелий, но спрайты зелий отличаются только тем, как выглядит содержимое колбочек. Вместо того, чтобы вручную рисовать все спрайты, можно написать код, который их генерирует. Причём логичнее было бы, чтобы спрайты генерировались единожды, только во время сборки экзешника игры, вместо того, чтобы генерировать их по новой при каждом запуске игры.
Это как раз можно через constexpr сделать. Если посмотришь в примере https://godbolt.org/z/TWW4vqY1P справа на асемблер, то увидишь там длинные последовательности из .byte - это сгенерированные на этапе компиляции спрайты, которые запишутся прямо внутрь экзешника. При запуске программы эти массивы байтов просто считываются и выводятся в консоль. А если уберёшь отовсюду в коде constexpr, то тогда спрайты будут генерироваться не во время компиляции, а при каждом запуске программы.
С constexpr много нюансов связано, которые зависят в том числе от версии стандарта плюсов, там не всё так просто. И я не знаю, зачем этим забивать голову. Для меня это выглядит как гейткиперство кодинга: как будто нарочно ебут голову какой-то си плюс плюсовой хуйнёй, чтобы ты в итоге ничего не понял. С википедией то же самое: в 90% случаев статьи написаны таким языком, что если заранее с темой не знаком, то ты вообще ничего не поймёшь. Я уже не верю в то, что это всё ненарочно.
Такое няшное начало, дропнешь, конечно, но было бы очень круто увидеть лет через 5 от тебя релиз какой-нибудь необычной индийобы.
318 Кб, 833x294>>1766
Листал /pr, наткнулся на книги Стоялрова. Прочитал введение и ещё посмотрел видео автора этой темы, что ты скинул, ПетраТурбо.
Решил скорректировать планы. Начать с Паскаля, а затем Плюсы. Но учиться буду не по Столярову, он льёт много воды, и почему-то предлагает учить потом С?
Нашёл книгу "Песни о Паскале", в ней очень много задач. Буду налегать на неё, learncpp буду почитывать и дальше, чтобы не забыть и не пришлось перечитывать, но в более медленном темпе.
Как писать в тред прогресс не знаю. Темы в книге небольшие и постить решение задач после каждой главы слишком мелко. Наверное буду писать пару раз в неделю, а не каждый(е) 2 дня.
Листал /pr, наткнулся на книги Стоялрова. Прочитал введение и ещё посмотрел видео автора этой темы, что ты скинул, ПетраТурбо.
Решил скорректировать планы. Начать с Паскаля, а затем Плюсы. Но учиться буду не по Столярову, он льёт много воды, и почему-то предлагает учить потом С?
Нашёл книгу "Песни о Паскале", в ней очень много задач. Буду налегать на неё, learncpp буду почитывать и дальше, чтобы не забыть и не пришлось перечитывать, но в более медленном темпе.
Как писать в тред прогресс не знаю. Темы в книге небольшие и постить решение задач после каждой главы слишком мелко. Наверное буду писать пару раз в неделю, а не каждый(е) 2 дня.
>>2032
Зачем начинать с Паскаля? Это лишнее и только время отнимет. Ты же не будешь писать на Паскуале.
Зачем начинать с Паскаля? Это лишнее и только время отнимет. Ты же не будешь писать на Паскуале.
301 Кб, 1062x229>>2032
Да ладно, он смешной... Временами. Мне чем-то Гоблина напоминает, не удивлюсь, если он в своё время на тупичке сидел.
Потому что Столик я теперь буду его так называть, по-моему звучит мило шиз. Он сторонник того, что, если ты начал учить программирование не с паскаля, то ты уже обречён, и тебя ничто не спасёт (пикрил как пример; честно говоря, я хотел другой его пост прикрепить, но мне лень искать). На взрослый язык для солидных дядь (Си) по Столику можно переходить только после того как написал пару тысяч строк кода на паскале. А дальше... А что дальше? Языков других больше нет. Ну, плюсы есть, но с НЕБОЛЬШИМ нюансом — это плюсы достандартизационного образца. За один твой constexpr он тебя, вероятно, пидорнул бы подальше со своего сайта. У него есть книжка по плюсам, её даже можно прочитать, она очень тонкая и там только базовые вещи написаны, но он люто ненавидит STL, поэтому её придётся изучать отдельно. Ещё, если решишься читать, к некоторым тезисам нужно относиться с осторожностью, как например к идее о том, что лесенка из if'ов лучше, чем исключения.
Чё ещё хотел сказать... Не помню. В общем, если интересно, подробно с творчеством можно ознакомиться здесь:
https://stolyarov.info
https://linux.org.ru (здесь нужно зайти в поиск и вбить имя пользователя Croco, именно Croco, с большой буквы, там регистрозависимые ники)
http://thalassa.croco.net/doc/cpp_subset.html#cplusplus
>он льёт много воды
Да ладно, он смешной... Временами. Мне чем-то Гоблина напоминает, не удивлюсь, если он в своё время на тупичке сидел.
>и почему-то предлагает учить потом С
Потому что Столик я теперь буду его так называть, по-моему звучит мило шиз. Он сторонник того, что, если ты начал учить программирование не с паскаля, то ты уже обречён, и тебя ничто не спасёт (пикрил как пример; честно говоря, я хотел другой его пост прикрепить, но мне лень искать). На взрослый язык для солидных дядь (Си) по Столику можно переходить только после того как написал пару тысяч строк кода на паскале. А дальше... А что дальше? Языков других больше нет. Ну, плюсы есть, но с НЕБОЛЬШИМ нюансом — это плюсы достандартизационного образца. За один твой constexpr он тебя, вероятно, пидорнул бы подальше со своего сайта. У него есть книжка по плюсам, её даже можно прочитать, она очень тонкая и там только базовые вещи написаны, но он люто ненавидит STL, поэтому её придётся изучать отдельно. Ещё, если решишься читать, к некоторым тезисам нужно относиться с осторожностью, как например к идее о том, что лесенка из if'ов лучше, чем исключения.
Чё ещё хотел сказать... Не помню. В общем, если интересно, подробно с творчеством можно ознакомиться здесь:
https://stolyarov.info
https://linux.org.ru (здесь нужно зайти в поиск и вбить имя пользователя Croco, именно Croco, с большой буквы, там регистрозависимые ники)
http://thalassa.croco.net/doc/cpp_subset.html#cplusplus
727 Кб, 888x1500>>2039
Это самый лучший язык на самом деле, просто про это никто не знает и у него нет нормальных компиляторов (как и у других языков... я джва года назад пробовал расписать ряд стандартных функций на ассемблере, сначала не знал ассемблера и делал это через C++, и очень сильно разочаровался в компиляторах C++, они то удивительно тупые, то СЛИШКОМ умные и ПОЭТОМУ делают ЕЩЁ хуже, чем если бы были тупыми), и туториалов. Эти туториалы для оБуЧеНиЯ заведомо не будут хватать звёзд с неба, но кроме них я ничего и не видел (впрочем, и не искал), кроме вот этой страницы: https://castle-engine.io/modern_pascal, и то, 3/4 тех возможностей, что на ней расписаны, я ненавижу — всё, что связано с классами, ввиду того, что экземпляры классов нельзя разместить статически, а про ещё столько же автор не рассказал. В первую очередь про это: https://wiki.freepascal.org/management_operators, возможность создавать пользовательские управляемые типы, то есть недо-аналог конструктора по умолчанию, конструктора копирования, и (авто)деструктора в C++, не такие полезные, как в C++, потому что в Паскале (пока) нет скоупов как в C++, чтобы автовызвать деструктор раньше конца функции, но хоть что-то.
Это самый лучший язык на самом деле, просто про это никто не знает и у него нет нормальных компиляторов (как и у других языков... я джва года назад пробовал расписать ряд стандартных функций на ассемблере, сначала не знал ассемблера и делал это через C++, и очень сильно разочаровался в компиляторах C++, они то удивительно тупые, то СЛИШКОМ умные и ПОЭТОМУ делают ЕЩЁ хуже, чем если бы были тупыми), и туториалов. Эти туториалы для оБуЧеНиЯ заведомо не будут хватать звёзд с неба, но кроме них я ничего и не видел (впрочем, и не искал), кроме вот этой страницы: https://castle-engine.io/modern_pascal, и то, 3/4 тех возможностей, что на ней расписаны, я ненавижу — всё, что связано с классами, ввиду того, что экземпляры классов нельзя разместить статически, а про ещё столько же автор не рассказал. В первую очередь про это: https://wiki.freepascal.org/management_operators, возможность создавать пользовательские управляемые типы, то есть недо-аналог конструктора по умолчанию, конструктора копирования, и (авто)деструктора в C++, не такие полезные, как в C++, потому что в Паскале (пока) нет скоупов как в C++, чтобы автовызвать деструктор раньше конца функции, но хоть что-то.
>>2103
Какой прекрасный пост. Ну почему меня увлек мир ебаного гламура в свое время, и не было никого рядом (и интернета толком тоже не было), кто бы подтолкнул в волшебный мир инженерии. Я ведь учился в шараге на погромиста (в 2002 поступил), куда пошел аж в 14 лет, так раньше можно было умудриться, да. Когда я узнал про демосцену очень хотел приобрести толстенную книгу по ОпенГл (да, не совсем то, но другого про программирование непосредственно графики в магазинах не было), но чёт денег так и не нашел, а потом полез в веб и купил книгу по пхп ебаному. Впрочем даже на него забил после сдачи диплома на много лет. А когда опомнился и вкатился, все сделал неправильно. Сделал штук 30 сайтов в общей сложности, самый дорогой за 150, но обычно по 20-40 были. И все на этом. Оп, ты молодец.
Какой прекрасный пост. Ну почему меня увлек мир ебаного гламура в свое время, и не было никого рядом (и интернета толком тоже не было), кто бы подтолкнул в волшебный мир инженерии. Я ведь учился в шараге на погромиста (в 2002 поступил), куда пошел аж в 14 лет, так раньше можно было умудриться, да. Когда я узнал про демосцену очень хотел приобрести толстенную книгу по ОпенГл (да, не совсем то, но другого про программирование непосредственно графики в магазинах не было), но чёт денег так и не нашел, а потом полез в веб и купил книгу по пхп ебаному. Впрочем даже на него забил после сдачи диплома на много лет. А когда опомнился и вкатился, все сделал неправильно. Сделал штук 30 сайтов в общей сложности, самый дорогой за 150, но обычно по 20-40 были. И все на этом. Оп, ты молодец.
>>2103
Ну да, если ты НЕ хочешь делать игры и НЕ хочешь найти работу, то язык охуенный. Хотя про игры ещё можно поспорить. Примерно в 2011 я недолго ходил в кружок по программированию, в котором мы рисовали всякое на паскале (ABC.net). Несколькими годами позже он появился в школе, естественно, детский уровень. И я буквально дрочил на это видео:
https://youtu.be/kDVJexd_tpY
>Это самый лучший язык на самом деле
Ну да, если ты НЕ хочешь делать игры и НЕ хочешь найти работу, то язык охуенный. Хотя про игры ещё можно поспорить. Примерно в 2011 я недолго ходил в кружок по программированию, в котором мы рисовали всякое на паскале (ABC.net). Несколькими годами позже он появился в школе, естественно, детский уровень. И я буквально дрочил на это видео:
https://youtu.be/kDVJexd_tpY
>>2121
Не стоит вскрывать эту тему. . .
>Ну да, если ты НЕ хочешь делать игры и НЕ хочешь найти работу
Не стоит вскрывать эту тему. . .
>>2039
Учил его в школе. Большую часть мне придется просто вспомнить. К концу упомянутый книги интересные задачи, поиск, сортировки. Буду вкатываться, если не брошу, условно 1г1м вместо 1г, разница? Learn cpp я не бросаю, просто пока что буду меньше времени уделять. Меня напрягает малое кол-во задач там.
>>2094
Не понимаю, для чего учить С, зная Паскаль? Это ведь языки одного и того же уровня, из одного и того же времени.
Другие его книги, сети, парадигмы, мне не интересны. Возможно прочту у него про ассемблер в первой, там небольшая глава.
Учил его в школе. Большую часть мне придется просто вспомнить. К концу упомянутый книги интересные задачи, поиск, сортировки. Буду вкатываться, если не брошу, условно 1г1м вместо 1г, разница? Learn cpp я не бросаю, просто пока что буду меньше времени уделять. Меня напрягает малое кол-во задач там.
>>2094
Не понимаю, для чего учить С, зная Паскаль? Это ведь языки одного и того же уровня, из одного и того же времени.
Другие его книги, сети, парадигмы, мне не интересны. Возможно прочту у него про ассемблер в первой, там небольшая глава.
241 Кб, 433x390ОП, может будет полезно в дополнение к learn c++. Когда я учился в универе, видео с этого канала стали для меня открытием:
https://www.youtube.com/@SimpleCodeIT/playlists
Главное сначала плейлист "основы", потом - "ооп". И домашки там есть, можно делать.
https://www.youtube.com/@SimpleCodeIT/playlists
Главное сначала плейлист "основы", потом - "ооп". И домашки там есть, можно делать.
>>2196
Спасибо за совет. Но мне намного проще воспринимать текст, чем звук, даже в школе на уроках я ничего не понимал, только после того как учебник дома читал.
По тексту ещё и поиск проще, если что-то захочу перечитать. Плюс хочу потренироваться в чтении английского. Я почти без проблем могу читать что-то не художественное, но очень быстро устаю.
Спасибо за совет. Но мне намного проще воспринимать текст, чем звук, даже в школе на уроках я ничего не понимал, только после того как учебник дома читал.
По тексту ещё и поиск проще, если что-то захочу перечитать. Плюс хочу потренироваться в чтении английского. Я почти без проблем могу читать что-то не художественное, но очень быстро устаю.
>>1766
вот странно вроде прям оче этот ресурс люди рекоммендуют, но я глянул и не ахти. Там автопроверка заданий есть?
вот странно вроде прям оче этот ресурс люди рекоммендуют, но я глянул и не ахти. Там автопроверка заданий есть?
>>2396
Флорентина.
Флорентина.
Давно не было апдейтов. Половину дней я спустил на Доту. Удалил, чтобы не отвлекала. Прочёл 12 глав "Песни о Паскале" и 7 главу на learn cpp.
Паскаль мне нравится своей словесностью, begin end выглядят приятней скобочек. Но есть один жирный минус: это секция объявлений переменных. В С++ гораздо удобней их объявлять прямо в программе. Возможно это сделано ради того чтобы мотивировать заранее продумывать что пишешь. Я и так это делаю, но продумывать до таких мелочей, сколько переменных понадобится, уже перебор.
Думал 7 главу на learncpp прочитаю быстро за пару заходов. Но ушло гораздо больше времени, и ощущение что мало что запомнил оттуда. Слишком много информации "на потом". Возможно стоит перечитать и собственноручно повбивать примеры, я же просто читал и лишь отвечал на вопросы и писал программы, заданные в упражнениях вконце главы.
Нашёл, кстати, отзыв Столярова на "Песни". Почему-то он негативный. А мне пока книжка нравится. Жаль ничего в таком стиле для С++ нет. Стиль письма "для детей" может кого-то и отталкивает, но learn cpp Алекс иногда расписывает настолько подробно, будто для людей с проблемами развития, что это становится невероятно тяжело читать. И это может соседствовать с инфой, которую уже тяжело с первого раза уловить и приходиться перечитывать, смотреть примеры.
>>2396
То что мне нравилось уже давно нет в меню. Из того что есть сейчас, наверное Диабло.
Паскаль мне нравится своей словесностью, begin end выглядят приятней скобочек. Но есть один жирный минус: это секция объявлений переменных. В С++ гораздо удобней их объявлять прямо в программе. Возможно это сделано ради того чтобы мотивировать заранее продумывать что пишешь. Я и так это делаю, но продумывать до таких мелочей, сколько переменных понадобится, уже перебор.
Думал 7 главу на learncpp прочитаю быстро за пару заходов. Но ушло гораздо больше времени, и ощущение что мало что запомнил оттуда. Слишком много информации "на потом". Возможно стоит перечитать и собственноручно повбивать примеры, я же просто читал и лишь отвечал на вопросы и писал программы, заданные в упражнениях вконце главы.
Нашёл, кстати, отзыв Столярова на "Песни". Почему-то он негативный. А мне пока книжка нравится. Жаль ничего в таком стиле для С++ нет. Стиль письма "для детей" может кого-то и отталкивает, но learn cpp Алекс иногда расписывает настолько подробно, будто для людей с проблемами развития, что это становится невероятно тяжело читать. И это может соседствовать с инфой, которую уже тяжело с первого раза уловить и приходиться перечитывать, смотреть примеры.
>>2396
То что мне нравилось уже давно нет в меню. Из того что есть сейчас, наверное Диабло.
>>4110
Эх. Столько воспоминаний с этой пиццей. А её, оказывается, из меню убрали. Теперь ни пиццы, ни друзей, с которыми я раньше её ел, да и воспоминания уже улетучиваются.
>То что мне нравилось уже давно нет в меню. Из того что есть сейчас, наверное Диабло.
Эх. Столько воспоминаний с этой пиццей. А её, оказывается, из меню убрали. Теперь ни пиццы, ни друзей, с которыми я раньше её ел, да и воспоминания уже улетучиваются.
>>4118
Ты путаешь наверное. Раньше вместо Диабло была Мексиканская. Вторую на первую заменили. Сейчас Диабло всё ещё есть.
Ты путаешь наверное. Раньше вместо Диабло была Мексиканская. Вторую на первую заменили. Сейчас Диабло всё ещё есть.
>>4132
Да я жопой прочитал. Подумал, что диабло убрали из меню.
Да я жопой прочитал. Подумал, что диабло убрали из меню.
Добил 8 главу. Последнее урпажнение сделал в лоб, автор же разнес на функции. Мне моё решение кажется лучше, у Алекса же выглядит так, будто это заготовка под сборник игр, если каждую пихать в отдельную функцию.
Паскаль прочёл до 20 главы. Пока там ничего нового, я это когда-то знал. В нём, кстати, switch реализован лучше. В нём нельзя провалиться в метки ниже, не нужно писать break/return, после исполнения кода относящийся к метке он автоматически выйдет из case of(паскалевский аналог switch).
Следующая 9 глава выглядит скучноватой. Но благо она коротенькая.
Паскаль прочёл до 20 главы. Пока там ничего нового, я это когда-то знал. В нём, кстати, switch реализован лучше. В нём нельзя провалиться в метки ниже, не нужно писать break/return, после исполнения кода относящийся к метке он автоматически выйдет из case of(паскалевский аналог switch).
Следующая 9 глава выглядит скучноватой. Но благо она коротенькая.
728 Кб, 575x727>>4110
Столяров - полный долбоеб и хуесос. Вообще, обращайте внимание на либертарианские взгляды - за типичным лишертариашкой скрытается обыкновенный проткнутый левак-коммиглист. В случае столярыча это работает в полной мере. Де факто, Анька Столярова выступает за ограничению свободы слова, за концентрационные лагеря, за довольно примитивное рабство.
Кстати, кодить этот долбоеб при седых мудях тоже нихуя не умеет. На linux.org, его "фалассу" оценили как дикий говнокод нулевого похлеба.
Однако, не смотря на всё это, книги у Столярова действительно не плохие. Столяров умеет преподавать. И это напрямую связано с тем что он ТУПОЙ как пробка. Я заметил, что тупые люди, как правило не понимают довольно простые вещи с первого раза, и поэтому им приходится извиваться в мысленной гимнастике, ходить бессмысленными умозаключениями, чтобы прийти к конечному факту. Поэтому тупые люди способны более развернуто и подробно объяснять некоторый материал. То что умному просто лень рассказывать - тупой человек будет разжёвывать часами. Поэтому, книги Столярова пожалуй могу посоветовать. Но сам столяров - вырожденец недоразвитый. Ну, кстати это не особо страшно, детей то у него нет, этот долбоеб ведь чайлдфри. А вот недавно врачи обнаружили у него рак.. часики то тикают, а пиписька больше не стоит. Так и здохнет он плешивым душеым шизопреподом, который всю жизнь затирал студентам пол Unix-way сидя на убунту.
Столяров - полный долбоеб и хуесос. Вообще, обращайте внимание на либертарианские взгляды - за типичным лишертариашкой скрытается обыкновенный проткнутый левак-коммиглист. В случае столярыча это работает в полной мере. Де факто, Анька Столярова выступает за ограничению свободы слова, за концентрационные лагеря, за довольно примитивное рабство.
Кстати, кодить этот долбоеб при седых мудях тоже нихуя не умеет. На linux.org, его "фалассу" оценили как дикий говнокод нулевого похлеба.
Однако, не смотря на всё это, книги у Столярова действительно не плохие. Столяров умеет преподавать. И это напрямую связано с тем что он ТУПОЙ как пробка. Я заметил, что тупые люди, как правило не понимают довольно простые вещи с первого раза, и поэтому им приходится извиваться в мысленной гимнастике, ходить бессмысленными умозаключениями, чтобы прийти к конечному факту. Поэтому тупые люди способны более развернуто и подробно объяснять некоторый материал. То что умному просто лень рассказывать - тупой человек будет разжёвывать часами. Поэтому, книги Столярова пожалуй могу посоветовать. Но сам столяров - вырожденец недоразвитый. Ну, кстати это не особо страшно, детей то у него нет, этот долбоеб ведь чайлдфри. А вот недавно врачи обнаружили у него рак.. часики то тикают, а пиписька больше не стоит. Так и здохнет он плешивым душеым шизопреподом, который всю жизнь затирал студентам пол Unix-way сидя на убунту.
>>2191
Да не, абсолютно разные языки из разных эпох. Паскаль - это высокоуровневый язык, с поддержкой ООП, с полноценными юнитами и раздутым рантаймом. Паскаль ближе к, С++ чем к С.
Сишка - низкоуровневый язык, в идеале с нулевым рантаймом (хотя на практике это чаще всего не так). В С нет ни классов, ни конструкторов, и даже отдельных модулей нет - модули компилируются сразу в байткод и линкуются. А вот в Паскале на уровне языка можно подключить "модуль".
>Не понимаю, для чего учить С, зная Паскаль? Это ведь языки одного и того же уровня, из одного и того же времени.
Да не, абсолютно разные языки из разных эпох. Паскаль - это высокоуровневый язык, с поддержкой ООП, с полноценными юнитами и раздутым рантаймом. Паскаль ближе к, С++ чем к С.
Сишка - низкоуровневый язык, в идеале с нулевым рантаймом (хотя на практике это чаще всего не так). В С нет ни классов, ни конструкторов, и даже отдельных модулей нет - модули компилируются сразу в байткод и линкуются. А вот в Паскале на уровне языка можно подключить "модуль".
89 Кб, 1280x720>>2121
Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Начнем с того что "программист" - это никакой не интеллектуальный труд. Интеллектуальный труд - это псиоп. На рынке не особо нужны люди типо Рируру, рынок более заинтересован в формальном подходе и формошлёпстве. Кодишь на известных фреймворках по форме -> стабильность -> прибыль. Поэтому любой наёмный труд - это всегда рутина.
Рынок сейчас перенасыщен разного рода лодырями-кнопкодавами. Желающих плевать в потолок и получать 999ккк в секунду много, а товар сбывать некуда. Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
И это я про вакансии разработчика на Java, на Python, на PHP. Если брать во внимание C++ то он никому не всрался даже с опытом работы в 6 лет. Так что чтение книг Столярова - дело не прибыльное, в чем сам Столярчик и признаётся. Можешь почитать гостевуху, там периодически появляются вкатуны, которые прочитав все его книги не могут найти работу, на что столяров им предъявляет мол: "А сколько ты полезных программ продал, сынок". Очевидно, торговля программами сейчас уже звучит как пережиток прошлого. Новоиспечённый вкатун отвечает что ничего он не продавал - и получает ответ, что стало быть он не настоящий программист, и книгу он читал зря. Чистосердечное признание Столярова, что его книга - полная хуйня бесполезная, которая не учит никаким профессиональным навыкам.
Однако, если для тебя сама цель - не заработок денег, а создание игр, то в целом создать игру можно на чем угодно. И тут Столяров оказывается как никогда прав, когда говорит что аналогов С и С++ в настоящем мире нет, какими бы кривыми и уродливыми эти два языка не были. Никакие Javы не дают столько контроля над процессом разработки, чтобы сделать игру производительнее. Так что для разработки игр вполне себе и плюсы, и си, и паскаль подходят. Гта ре3 на плюсах чисто сделана. Doom вообще на чистом С написан.
>НЕ хочешь найти работу
Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Начнем с того что "программист" - это никакой не интеллектуальный труд. Интеллектуальный труд - это псиоп. На рынке не особо нужны люди типо Рируру, рынок более заинтересован в формальном подходе и формошлёпстве. Кодишь на известных фреймворках по форме -> стабильность -> прибыль. Поэтому любой наёмный труд - это всегда рутина.
Рынок сейчас перенасыщен разного рода лодырями-кнопкодавами. Желающих плевать в потолок и получать 999ккк в секунду много, а товар сбывать некуда. Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
И это я про вакансии разработчика на Java, на Python, на PHP. Если брать во внимание C++ то он никому не всрался даже с опытом работы в 6 лет. Так что чтение книг Столярова - дело не прибыльное, в чем сам Столярчик и признаётся. Можешь почитать гостевуху, там периодически появляются вкатуны, которые прочитав все его книги не могут найти работу, на что столяров им предъявляет мол: "А сколько ты полезных программ продал, сынок". Очевидно, торговля программами сейчас уже звучит как пережиток прошлого. Новоиспечённый вкатун отвечает что ничего он не продавал - и получает ответ, что стало быть он не настоящий программист, и книгу он читал зря. Чистосердечное признание Столярова, что его книга - полная хуйня бесполезная, которая не учит никаким профессиональным навыкам.
Однако, если для тебя сама цель - не заработок денег, а создание игр, то в целом создать игру можно на чем угодно. И тут Столяров оказывается как никогда прав, когда говорит что аналогов С и С++ в настоящем мире нет, какими бы кривыми и уродливыми эти два языка не были. Никакие Javы не дают столько контроля над процессом разработки, чтобы сделать игру производительнее. Так что для разработки игр вполне себе и плюсы, и си, и паскаль подходят. Гта ре3 на плюсах чисто сделана. Doom вообще на чистом С написан.
89 Кб, 1280x720>>2121
Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Начнем с того что "программист" - это никакой не интеллектуальный труд. Интеллектуальный труд - это псиоп. На рынке не особо нужны люди типо Рируру, рынок более заинтересован в формальном подходе и формошлёпстве. Кодишь на известных фреймворках по форме -> стабильность -> прибыль. Поэтому любой наёмный труд - это всегда рутина.
Рынок сейчас перенасыщен разного рода лодырями-кнопкодавами. Желающих плевать в потолок и получать 999ккк в секунду много, а товар сбывать некуда. Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
И это я про вакансии разработчика на Java, на Python, на PHP. Если брать во внимание C++ то он никому не всрался даже с опытом работы в 6 лет. Так что чтение книг Столярова - дело не прибыльное, в чем сам Столярчик и признаётся. Можешь почитать гостевуху, там периодически появляются вкатуны, которые прочитав все его книги не могут найти работу, на что столяров им предъявляет мол: "А сколько ты полезных программ продал, сынок". Очевидно, торговля программами сейчас уже звучит как пережиток прошлого. Новоиспечённый вкатун отвечает что ничего он не продавал - и получает ответ, что стало быть он не настоящий программист, и книгу он читал зря. Чистосердечное признание Столярова, что его книга - полная хуйня бесполезная, которая не учит никаким профессиональным навыкам.
Однако, если для тебя сама цель - не заработок денег, а создание игр, то в целом создать игру можно на чем угодно. И тут Столяров оказывается как никогда прав, когда говорит что аналогов С и С++ в настоящем мире нет, какими бы кривыми и уродливыми эти два языка не были. Никакие Javы не дают столько контроля над процессом разработки, чтобы сделать игру производительнее. Так что для разработки игр вполне себе и плюсы, и си, и паскаль подходят. Гта ре3 на плюсах чисто сделана. Doom вообще на чистом С написан.
>НЕ хочешь найти работу
Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Начнем с того что "программист" - это никакой не интеллектуальный труд. Интеллектуальный труд - это псиоп. На рынке не особо нужны люди типо Рируру, рынок более заинтересован в формальном подходе и формошлёпстве. Кодишь на известных фреймворках по форме -> стабильность -> прибыль. Поэтому любой наёмный труд - это всегда рутина.
Рынок сейчас перенасыщен разного рода лодырями-кнопкодавами. Желающих плевать в потолок и получать 999ккк в секунду много, а товар сбывать некуда. Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
И это я про вакансии разработчика на Java, на Python, на PHP. Если брать во внимание C++ то он никому не всрался даже с опытом работы в 6 лет. Так что чтение книг Столярова - дело не прибыльное, в чем сам Столярчик и признаётся. Можешь почитать гостевуху, там периодически появляются вкатуны, которые прочитав все его книги не могут найти работу, на что столяров им предъявляет мол: "А сколько ты полезных программ продал, сынок". Очевидно, торговля программами сейчас уже звучит как пережиток прошлого. Новоиспечённый вкатун отвечает что ничего он не продавал - и получает ответ, что стало быть он не настоящий программист, и книгу он читал зря. Чистосердечное признание Столярова, что его книга - полная хуйня бесполезная, которая не учит никаким профессиональным навыкам.
Однако, если для тебя сама цель - не заработок денег, а создание игр, то в целом создать игру можно на чем угодно. И тут Столяров оказывается как никогда прав, когда говорит что аналогов С и С++ в настоящем мире нет, какими бы кривыми и уродливыми эти два языка не были. Никакие Javы не дают столько контроля над процессом разработки, чтобы сделать игру производительнее. Так что для разработки игр вполне себе и плюсы, и си, и паскаль подходят. Гта ре3 на плюсах чисто сделана. Doom вообще на чистом С написан.
Для работы сейчас актуально либо 1С разработка, бухгалтерия (почему-то в 1С до сих пор с руками и ногами без опыта разбирают). Либо обслуживание, администрирование, девосп (вкатится не так легко как ранее, однако в отличие от разрабов открытые вакансии есть и не мало). А также машинное обучение. Вот МЛьщики сейчас всех по зарплате опережают пожалуй.
>>4871
Напомню, что в 2018 так же говорили, даже в 2012 так же говорили лол. Количество дерьма просто надо побольше знать, но так всегда и было, в 2007 я вот книжки покупал, в 2012 уже много текстовой инфы в интернетах было, но приходилось, прям сильно в коде фреймворка сидеть и смотреть че как работает, ну и т.д. инфу получать все проще и проще, поэтому и надо ее знать больше.
Насчёт байтоебства, ну кто-то же микроконтроллеры все ещё программирует... В любой профессии найти классное место сложно, и погромирование к этому приходит.
>Если в 2018, можно было смело пойти в любую компанию - тебя бы взяли даже без опыта, то сейчас с опытом в 3 года работы не так то просто трудоустроится.
Напомню, что в 2018 так же говорили, даже в 2012 так же говорили лол. Количество дерьма просто надо побольше знать, но так всегда и было, в 2007 я вот книжки покупал, в 2012 уже много текстовой инфы в интернетах было, но приходилось, прям сильно в коде фреймворка сидеть и смотреть че как работает, ну и т.д. инфу получать все проще и проще, поэтому и надо ее знать больше.
Насчёт байтоебства, ну кто-то же микроконтроллеры все ещё программирует... В любой профессии найти классное место сложно, и погромирование к этому приходит.
>>4875
Кто-то да программирует. Пара embedded разработчиков, которых препод по блату пристроил, например. А для остальных вход закрыт. Хз, я контроллеры ковырял, прогал, на собесах на все общие вопросы по С по сетям и устройстве контроллеров ответил - всё равно не взяли. Да даже бы и если взяли, в embedded разработке денег особо много нет, там 150к потолок. Я туда чисто ради интереса пытался трудоустроиться. Если уж выкатываться в IT ради денег, то лучше в ML время потратить.
>Насчёт байтоебства, ну кто-то же микроконтроллеры все ещё программирует...
Кто-то да программирует. Пара embedded разработчиков, которых препод по блату пристроил, например. А для остальных вход закрыт. Хз, я контроллеры ковырял, прогал, на собесах на все общие вопросы по С по сетям и устройстве контроллеров ответил - всё равно не взяли. Да даже бы и если взяли, в embedded разработке денег особо много нет, там 150к потолок. Я туда чисто ради интереса пытался трудоустроиться. Если уж выкатываться в IT ради денег, то лучше в ML время потратить.
>>4871
Сложнее, чем на других языках, но легче, чем на паскале. Возможно. У меня несколько знакомых в 2023-2024 находили. Правда, там не backend, а embedded. С Нулевым опытом. В резюме указывали два года.
Но вообще ты прав, особенно насчёт Столярова.
>Ага, сейчас бы в 2к25 работу искать разрабом на С++. Вообще забей.
Сложнее, чем на других языках, но легче, чем на паскале. Возможно. У меня несколько знакомых в 2023-2024 находили. Правда, там не backend, а embedded. С Нулевым опытом. В резюме указывали два года.
Но вообще ты прав, особенно насчёт Столярова.
191 Кб, 736x736>>4930
А почему нет? На чистом ассемблере - идея такая себе. Но с вкраплениями ассемблера, почему бы и нет. Особенно что, вопреки тому что говорит столяров, С довольно не идеален на практике. С изначально был разработан под компьютер PDP и оптимизирован под его инструкции. Перенос языка на компилятор для x86-64 вносит некоторый хаос. Возьмём следующий фрагмент кода на языке С:
int x = 1;
x = x << sizeof(int) ⚹ 8;
Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным "1". Т.е. один и тот же код, на разных системах будет выдавать разный результат. Кроме того, компилятор под x86-64 терят довольно много производительности, так как в каком то смысле является костылем. Для решения проблем начали делать оптимизаторы, и тут отпитизаторы оказались довольно опасной штукой - создатель каждого оптимизатора сам решает каким путем оптимизировать. Т.е. в некоторых случаях, а твоей программе компилятор мог бы взять и заменить код на уязвимый, а порой может быть и вовсе работающий некорректно. Получается что программируя на С, ты не можешь гарантировать, что твоя программа будет работать вообще.
Также сам по себе С испольщует стеклвый фрейм, так что частое выполнение функций и trunk-функций даёт о себе знать в узких горлышках программы. Пока фрейм подготовится, пока процессор распердиться - на всё это уходит довольно много тактов процессора. И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда. Ассемблер, мне кажется мог бы помочь, именно вот в таких узких местах.
Интересный тред. Надеюсь ОП создаст что-то прикольное.
А почему нет? На чистом ассемблере - идея такая себе. Но с вкраплениями ассемблера, почему бы и нет. Особенно что, вопреки тому что говорит столяров, С довольно не идеален на практике. С изначально был разработан под компьютер PDP и оптимизирован под его инструкции. Перенос языка на компилятор для x86-64 вносит некоторый хаос. Возьмём следующий фрагмент кода на языке С:
int x = 1;
x = x << sizeof(int) ⚹ 8;
Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным "1". Т.е. один и тот же код, на разных системах будет выдавать разный результат. Кроме того, компилятор под x86-64 терят довольно много производительности, так как в каком то смысле является костылем. Для решения проблем начали делать оптимизаторы, и тут отпитизаторы оказались довольно опасной штукой - создатель каждого оптимизатора сам решает каким путем оптимизировать. Т.е. в некоторых случаях, а твоей программе компилятор мог бы взять и заменить код на уязвимый, а порой может быть и вовсе работающий некорректно. Получается что программируя на С, ты не можешь гарантировать, что твоя программа будет работать вообще.
Также сам по себе С испольщует стеклвый фрейм, так что частое выполнение функций и trunk-функций даёт о себе знать в узких горлышках программы. Пока фрейм подготовится, пока процессор распердиться - на всё это уходит довольно много тактов процессора. И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда. Ассемблер, мне кажется мог бы помочь, именно вот в таких узких местах.
Интересный тред. Надеюсь ОП создаст что-то прикольное.
191 Кб, 736x736>>4930
А почему нет? На чистом ассемблере - идея такая себе. Но с вкраплениями ассемблера, почему бы и нет. Особенно что, вопреки тому что говорит столяров, С довольно не идеален на практике. С изначально был разработан под компьютер PDP и оптимизирован под его инструкции. Перенос языка на компилятор для x86-64 вносит некоторый хаос. Возьмём следующий фрагмент кода на языке С:
int x = 1;
x = x << sizeof(int) ⚹ 8;
Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным "1". Т.е. один и тот же код, на разных системах будет выдавать разный результат. Кроме того, компилятор под x86-64 терят довольно много производительности, так как в каком то смысле является костылем. Для решения проблем начали делать оптимизаторы, и тут отпитизаторы оказались довольно опасной штукой - создатель каждого оптимизатора сам решает каким путем оптимизировать. Т.е. в некоторых случаях, а твоей программе компилятор мог бы взять и заменить код на уязвимый, а порой может быть и вовсе работающий некорректно. Получается что программируя на С, ты не можешь гарантировать, что твоя программа будет работать вообще.
Также сам по себе С испольщует стеклвый фрейм, так что частое выполнение функций и trunk-функций даёт о себе знать в узких горлышках программы. Пока фрейм подготовится, пока процессор распердиться - на всё это уходит довольно много тактов процессора. И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда. Ассемблер, мне кажется мог бы помочь, именно вот в таких узких местах.
Интересный тред. Надеюсь ОП создаст что-то прикольное.
А почему нет? На чистом ассемблере - идея такая себе. Но с вкраплениями ассемблера, почему бы и нет. Особенно что, вопреки тому что говорит столяров, С довольно не идеален на практике. С изначально был разработан под компьютер PDP и оптимизирован под его инструкции. Перенос языка на компилятор для x86-64 вносит некоторый хаос. Возьмём следующий фрагмент кода на языке С:
int x = 1;
x = x << sizeof(int) ⚹ 8;
Попробуем предположить, какой результат у нас получится. Допустим, мы скомпилировали этот код для процессоров архитектуры ARM. Инструкция битового сдвига в рамках этой аппаратной платформы определена так, что итоговым значением переменной "x" должен быть "0". С другой стороны, мы можем транслировать нашу программу в машинный код архитектуры x86. И уже там битовый сдвиг реализован таким образом, что значение "x" не изменится и останется равным "1". Т.е. один и тот же код, на разных системах будет выдавать разный результат. Кроме того, компилятор под x86-64 терят довольно много производительности, так как в каком то смысле является костылем. Для решения проблем начали делать оптимизаторы, и тут отпитизаторы оказались довольно опасной штукой - создатель каждого оптимизатора сам решает каким путем оптимизировать. Т.е. в некоторых случаях, а твоей программе компилятор мог бы взять и заменить код на уязвимый, а порой может быть и вовсе работающий некорректно. Получается что программируя на С, ты не можешь гарантировать, что твоя программа будет работать вообще.
Также сам по себе С испольщует стеклвый фрейм, так что частое выполнение функций и trunk-функций даёт о себе знать в узких горлышках программы. Пока фрейм подготовится, пока процессор распердиться - на всё это уходит довольно много тактов процессора. И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда. Ассемблер, мне кажется мог бы помочь, именно вот в таких узких местах.
Интересный тред. Надеюсь ОП создаст что-то прикольное.
80 Кб, 673x800>>4935
Что такое trunk-функция? Не гуглится вообще никак.
А ты уверен, что это написано в стандарте? На x64 есть всякие fastcall-конвенции, которые кучу аргументов кидают через регистры.
Хотя, конечно, иногда вызовы функций могут быть дорогими. Константин Владимиров, например, любит показывать, как Сишный qsort сосёт у std::sort приплюснутого, потому что компиляторы C++ имеют доступ к типу объекта переданного в качестве функтора, и вследствие могут заинлайнить вызов. А компиляторы Си не могут, потому что информация о типе затирается тут, кстати, забавно вышло — я как будто говорю о компиляторах C++ и C как о разных программах, лол.
Но тут, надо понимать, имеется в виду косвенный вызов функции. А на явных, наверное, особо нет смысла экономить.
Интерполяция текстур по треугольнику на процессоре? Софтвейр рендер делаешь что-ли? Тут, наверное, уже мало что поможет...
> trunk-функций
Что такое trunk-функция? Не гуглится вообще никак.
> Также сам по себе С испольщует стеклвый фрейм
А ты уверен, что это написано в стандарте? На x64 есть всякие fastcall-конвенции, которые кучу аргументов кидают через регистры.
Хотя, конечно, иногда вызовы функций могут быть дорогими. Константин Владимиров, например, любит показывать, как Сишный qsort сосёт у std::sort приплюснутого, потому что компиляторы C++ имеют доступ к типу объекта переданного в качестве функтора, и вследствие могут заинлайнить вызов. А компиляторы Си не могут, потому что информация о типе затирается тут, кстати, забавно вышло — я как будто говорю о компиляторах C++ и C как о разных программах, лол.
Но тут, надо понимать, имеется в виду косвенный вызов функции. А на явных, наверное, особо нет смысла экономить.
> И если ты делаешь графический рендер для своей игры, то на момент интерполяции текстур по треугольнику, для тебя важна каждая миллисекунда
Интерполяция текстур по треугольнику на процессоре? Софтвейр рендер делаешь что-ли? Тут, наверное, уже мало что поможет...
>>4943
Ну, типо варпер функция, которая вызвает другую функцию, чисто для инкапсуляции. Просто в дизассемблере она почему-то thunk называется, я поэтому так привык называть.
Насколько я понял, в стандарте вроде бы не написано ничего вообще. Т.е. стандарт компилятора С специально оставляет "пустые места" для того чтобы разработчики сами могли решить как им реализовать ту или иную конструкцию. Из-за этого код и становится нестабильным, потому что на олной платформе он использует одни решения, а на другом - другие.
Да)) Но мне просто интересно, вот в half-life был же вариант "software render". И всё нормально работало, не тормозило. Получается програмные рендеры всё таки в теории можно как-то оптимизировать, мб распараллелить. Почему то у меня только тормознутое говно получилось, сколько бы я не старался.
Ещё нужно изучить drm-kmod драйвера, чтобы можно было напрямую с видеокартой работать. Тогда можно аппаратный рендер добавить. Типо софтверный - общий для всех, а аппаратный - если повезёт.
>Что такое trunk-функция? Не гуглится вообще никак.
Ну, типо варпер функция, которая вызвает другую функцию, чисто для инкапсуляции. Просто в дизассемблере она почему-то thunk называется, я поэтому так привык называть.
>А ты уверен, что это написано в стандарте?
Насколько я понял, в стандарте вроде бы не написано ничего вообще. Т.е. стандарт компилятора С специально оставляет "пустые места" для того чтобы разработчики сами могли решить как им реализовать ту или иную конструкцию. Из-за этого код и становится нестабильным, потому что на олной платформе он использует одни решения, а на другом - другие.
>Софтвейр рендер делаешь что-ли? Тут, наверное, уже мало что поможет...
Да)) Но мне просто интересно, вот в half-life был же вариант "software render". И всё нормально работало, не тормозило. Получается програмные рендеры всё таки в теории можно как-то оптимизировать, мб распараллелить. Почему то у меня только тормознутое говно получилось, сколько бы я не старался.
Ещё нужно изучить drm-kmod драйвера, чтобы можно было напрямую с видеокартой работать. Тогда можно аппаратный рендер добавить. Типо софтверный - общий для всех, а аппаратный - если повезёт.
>>4935
Да ты ёбу дал, это понятие не C, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет (...кхм... ну, что-нибудь...), и написать под неё компилятор C. Более того, компилятору под «нормальные» платформы тоже не запрещено вместо стекового фрейма реализовать вызовы и локальные переменные как-то по другому; банально функция, заинлайненная в другую функцию, или функция, «вызванная» из другой функции последним действием через jmp вместо call — примеры таких «вызовов» без фрейма. Если под trunk-функциями имелись в виду leaf-функции, то это ТОЖЕ чисто понятие платформы. (А, ок.)
Играл я в неё недавно, и софтварный рендер выставлял... На высоких разрешениях он тормозит именно так, как от него можно ожидать. Старые ЭЛТ-мониторы умели нормально отображать низкие разрешения на весь экран.
>>4943
...И даже соглашения платформы можно не соблюдать, если не хочется: 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, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет (...кхм... ну, что-нибудь...), и написать под неё компилятор C. Более того, компилятору под «нормальные» платформы тоже не запрещено вместо стекового фрейма реализовать вызовы и локальные переменные как-то по другому; банально функция, заинлайненная в другую функцию, или функция, «вызванная» из другой функции последним действием через jmp вместо call — примеры таких «вызовов» без фрейма. Если под trunk-функциями имелись в виду leaf-функции, то это ТОЖЕ чисто понятие платформы. (А, ок.)
>в half-life был же вариант "software render". И всё нормально работало, не тормозило.
Играл я в неё недавно, и софтварный рендер выставлял... На высоких разрешениях он тормозит именно так, как от него можно ожидать. Старые ЭЛТ-мониторы умели нормально отображать низкие разрешения на весь экран.
>>4943
>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 с достаточно охуевшими флагами, я не разбираюсь) тоже мог бы это сделать.
>>4935
Да ты ёбу дал, это понятие не C, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет (...кхм... ну, что-нибудь...), и написать под неё компилятор C. Более того, компилятору под «нормальные» платформы тоже не запрещено вместо стекового фрейма реализовать вызовы и локальные переменные как-то по другому; банально функция, заинлайненная в другую функцию, или функция, «вызванная» из другой функции последним действием через jmp вместо call — примеры таких «вызовов» без фрейма. Если под trunk-функциями имелись в виду leaf-функции, то это ТОЖЕ чисто понятие платформы. (А, ок.)
Играл я в неё недавно, и софтварный рендер выставлял... На высоких разрешениях он тормозит именно так, как от него можно ожидать. Старые ЭЛТ-мониторы умели нормально отображать низкие разрешения на весь экран.
>>4943
...И даже соглашения платформы можно не соблюдать, если не хочется: 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, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет (...кхм... ну, что-нибудь...), и написать под неё компилятор C. Более того, компилятору под «нормальные» платформы тоже не запрещено вместо стекового фрейма реализовать вызовы и локальные переменные как-то по другому; банально функция, заинлайненная в другую функцию, или функция, «вызванная» из другой функции последним действием через jmp вместо call — примеры таких «вызовов» без фрейма. Если под trunk-функциями имелись в виду leaf-функции, то это ТОЖЕ чисто понятие платформы. (А, ок.)
>в half-life был же вариант "software render". И всё нормально работало, не тормозило.
Играл я в неё недавно, и софтварный рендер выставлял... На высоких разрешениях он тормозит именно так, как от него можно ожидать. Старые ЭЛТ-мониторы умели нормально отображать низкие разрешения на весь экран.
>>4943
>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 с достаточно охуевшими флагами, я не разбираюсь) тоже мог бы это сделать.
>>4964
Так тогда и получается, что на одной платформе, допустим битовый сдвиг будет спамит 11 в новые биты, а на другой 00. Т.е. если мы битовые сдвиги используем для расчета света, то на одной платформе текстура может оказаться белой, а на другой зелёной. В чём я не прав?
>Да ты ёбу дал, это понятие не C, а платформы и её соглашений, тебе никто не запрещает придумать свою платформу, на которой вместо стекового фрейма будет
Так тогда и получается, что на одной платформе, допустим битовый сдвиг будет спамит 11 в новые биты, а на другой 00. Т.е. если мы битовые сдвиги используем для расчета света, то на одной платформе текстура может оказаться белой, а на другой зелёной. В чём я не прав?
>>4964
Или вот по-лучше есть пример как раз в учебнике сторярыча. Там он демонстрирует пример остаточной рекурсии. Так вот, если программу написать не используя остаточную рекурсию, т.е. чтобе стек рос по мере вызова функций, то получается, на некоторых платформах где стек не используется, программа может отработать стабильно и даже пройти все юнит тесты. Но стоит эту программу портировать на другую платформу - она рухнет со "стек оверфлоу". Насколько я знаю высокоуровневые языки типо Java эти вопросы решают при помощи собственной среды выполнения jvm, именно поэтому ими в энтерпрайсе и пользуются. А С - нет, не обязан. Т.е. имея ввиду как раз специфику и минималистичность языка, мы получаем на выходе неоднозначные компиляторы.
Или вот по-лучше есть пример как раз в учебнике сторярыча. Там он демонстрирует пример остаточной рекурсии. Так вот, если программу написать не используя остаточную рекурсию, т.е. чтобе стек рос по мере вызова функций, то получается, на некоторых платформах где стек не используется, программа может отработать стабильно и даже пройти все юнит тесты. Но стоит эту программу портировать на другую платформу - она рухнет со "стек оверфлоу". Насколько я знаю высокоуровневые языки типо Java эти вопросы решают при помощи собственной среды выполнения jvm, именно поэтому ими в энтерпрайсе и пользуются. А С - нет, не обязан. Т.е. имея ввиду как раз специфику и минималистичность языка, мы получаем на выходе неоднозначные компиляторы.
269 Кб, 1448x2048>>4967
Во-первых, «а вы так не делайте». 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 функция возвращает фигню. Это оставит тебе пространство для манёвра; ты сможешь даже поменять мужика; у нового мужика будет другой размер ч радиус или другие значения вне радиуса, но это неважно, ведь ты оставил за собой право вернуть фигню.
Метафорично, ты / Столик предлагаете мне пожертвовать возможностью прыгать по хуям ради штабильности того, что меня и ебать-то не должно.
Во-первых, «а вы так не делайте». 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 функция возвращает фигню. Это оставит тебе пространство для манёвра; ты сможешь даже поменять мужика; у нового мужика будет другой размер ч радиус или другие значения вне радиуса, но это неважно, ведь ты оставил за собой право вернуть фигню.
Метафорично, ты / Столик предлагаете мне пожертвовать возможностью прыгать по хуям ради штабильности того, что меня и ебать-то не должно.
67 Кб, 665x475>>4987
Да, при том что я вот не понимаю в чём фишка якобы "платформо-независимой" java если ошибка StakOverflow таки возникает. Т.е. вот коллеги мне мимо делом нарассказывал, что С++ - фигня, байтоёбство для дрочеров памяти, а вот в java смазка выделяется сама! ни о какой памяти думать не нужно. Но стоит сделать while(1) { new.. так сразу программа вылетает с ошибкой Out of memory. А що таке?! Почему сборщик мусора не спас? Вернее.. зачем нужен сборщик мусора, если он спасает не от всего. Получается, что вот вы сделали "высокоуровневый язык" для быстрой корпоративной разработки... казалось бы, значит нам не обязательно знать "что там под капотом". Но фактически то это не так, всё равно приходится знать что там под капотом, понимать концепции стека pop, push чтобы хоть что-то написать. Так тогда бы почему не выкинуть эту жаву и не начать байтоёбствовать. Ведь если понимать все нюансы работы с памятью, то ошибок утечки памяти избежать легко.
Ну так то мне кажется что гибкость программы идёт в разрез с её производительностью. Т.е. чем более программа примитивна, тем более она производительна. Так что каждый раз надо бы задуматься "а нужна ли универсальность в конкретно этом случае". И если функция известна заранее, почему бы не использовать готовый результат в виде таблицы, а промежуточные варианты просто с интерполировать. Даже если взять банально вычисление квадратного корня - програмно его фиг высчитаешь.
А я чё, я даже не программист. Просто сижу тут уши грею.
Столярову вообще ничего помоему не нравиться - на всё ворчит, все у него гниды и предатели, всех пристрелить "маленькими и в кроватках".
>платформозависимом коде можно положиться на конкретное поведение
Да, при том что я вот не понимаю в чём фишка якобы "платформо-независимой" java если ошибка StakOverflow таки возникает. Т.е. вот коллеги мне мимо делом нарассказывал, что С++ - фигня, байтоёбство для дрочеров памяти, а вот в java смазка выделяется сама! ни о какой памяти думать не нужно. Но стоит сделать while(1) { new.. так сразу программа вылетает с ошибкой Out of memory. А що таке?! Почему сборщик мусора не спас? Вернее.. зачем нужен сборщик мусора, если он спасает не от всего. Получается, что вот вы сделали "высокоуровневый язык" для быстрой корпоративной разработки... казалось бы, значит нам не обязательно знать "что там под капотом". Но фактически то это не так, всё равно приходится знать что там под капотом, понимать концепции стека pop, push чтобы хоть что-то написать. Так тогда бы почему не выкинуть эту жаву и не начать байтоёбствовать. Ведь если понимать все нюансы работы с памятью, то ошибок утечки памяти избежать легко.
>так что если функция всё-таки НЕ нужна для произвольного x, то ты можешь не делать argument reduction, а вместо этого сказать, что при x > π/2 функция возвращает фигню. Это оставит тебе пространство для манёвра; ты сможешь даже поменять мужика
Ну так то мне кажется что гибкость программы идёт в разрез с её производительностью. Т.е. чем более программа примитивна, тем более она производительна. Так что каждый раз надо бы задуматься "а нужна ли универсальность в конкретно этом случае". И если функция известна заранее, почему бы не использовать готовый результат в виде таблицы, а промежуточные варианты просто с интерполировать. Даже если взять банально вычисление квадратного корня - програмно его фиг высчитаешь.
>Метафорично, ты / Столик предлагаете мне пожертвовать возможностью прыгать по хуям ради штабильности того, что меня и ебать-то не должно.
А я чё, я даже не программист. Просто сижу тут уши грею.
Столярову вообще ничего помоему не нравиться - на всё ворчит, все у него гниды и предатели, всех пристрелить "маленькими и в кроватках".
67 Кб, 665x475>>4987
Да, при том что я вот не понимаю в чём фишка якобы "платформо-независимой" java если ошибка StakOverflow таки возникает. Т.е. вот коллеги мне мимо делом нарассказывал, что С++ - фигня, байтоёбство для дрочеров памяти, а вот в java смазка выделяется сама! ни о какой памяти думать не нужно. Но стоит сделать while(1) { new.. так сразу программа вылетает с ошибкой Out of memory. А що таке?! Почему сборщик мусора не спас? Вернее.. зачем нужен сборщик мусора, если он спасает не от всего. Получается, что вот вы сделали "высокоуровневый язык" для быстрой корпоративной разработки... казалось бы, значит нам не обязательно знать "что там под капотом". Но фактически то это не так, всё равно приходится знать что там под капотом, понимать концепции стека pop, push чтобы хоть что-то написать. Так тогда бы почему не выкинуть эту жаву и не начать байтоёбствовать. Ведь если понимать все нюансы работы с памятью, то ошибок утечки памяти избежать легко.
Ну так то мне кажется что гибкость программы идёт в разрез с её производительностью. Т.е. чем более программа примитивна, тем более она производительна. Так что каждый раз надо бы задуматься "а нужна ли универсальность в конкретно этом случае". И если функция известна заранее, почему бы не использовать готовый результат в виде таблицы, а промежуточные варианты просто с интерполировать. Даже если взять банально вычисление квадратного корня - програмно его фиг высчитаешь.
А я чё, я даже не программист. Просто сижу тут уши грею.
Столярову вообще ничего помоему не нравиться - на всё ворчит, все у него гниды и предатели, всех пристрелить "маленькими и в кроватках".
>платформозависимом коде можно положиться на конкретное поведение
Да, при том что я вот не понимаю в чём фишка якобы "платформо-независимой" java если ошибка StakOverflow таки возникает. Т.е. вот коллеги мне мимо делом нарассказывал, что С++ - фигня, байтоёбство для дрочеров памяти, а вот в java смазка выделяется сама! ни о какой памяти думать не нужно. Но стоит сделать while(1) { new.. так сразу программа вылетает с ошибкой Out of memory. А що таке?! Почему сборщик мусора не спас? Вернее.. зачем нужен сборщик мусора, если он спасает не от всего. Получается, что вот вы сделали "высокоуровневый язык" для быстрой корпоративной разработки... казалось бы, значит нам не обязательно знать "что там под капотом". Но фактически то это не так, всё равно приходится знать что там под капотом, понимать концепции стека pop, push чтобы хоть что-то написать. Так тогда бы почему не выкинуть эту жаву и не начать байтоёбствовать. Ведь если понимать все нюансы работы с памятью, то ошибок утечки памяти избежать легко.
>так что если функция всё-таки НЕ нужна для произвольного x, то ты можешь не делать argument reduction, а вместо этого сказать, что при x > π/2 функция возвращает фигню. Это оставит тебе пространство для манёвра; ты сможешь даже поменять мужика
Ну так то мне кажется что гибкость программы идёт в разрез с её производительностью. Т.е. чем более программа примитивна, тем более она производительна. Так что каждый раз надо бы задуматься "а нужна ли универсальность в конкретно этом случае". И если функция известна заранее, почему бы не использовать готовый результат в виде таблицы, а промежуточные варианты просто с интерполировать. Даже если взять банально вычисление квадратного корня - програмно его фиг высчитаешь.
>Метафорично, ты / Столик предлагаете мне пожертвовать возможностью прыгать по хуям ради штабильности того, что меня и ебать-то не должно.
А я чё, я даже не программист. Просто сижу тут уши грею.
Столярову вообще ничего помоему не нравиться - на всё ворчит, все у него гниды и предатели, всех пристрелить "маленькими и в кроватках".
698 Кб, 692x845В общем я сдаюсь. Не могу дальше читать learncpp. Автор пишет очень косноязычно: постоянно кроет инфой, которая в ближайшее время не понадобится, очень часто в мельчийших подробностях прописывает что делают пара тривиальных строчек, очень мало заданий.
Скачал вместо этого книгу Страуструпа. Она есть во всех топах, а так же в ней много заданий. Надеюсь пойдёт так же легко, как и Паскалик.
Скачал вместо этого книгу Страуструпа. Она есть во всех топах, а так же в ней много заданий. Надеюсь пойдёт так же легко, как и Паскалик.
>>5339
А чё столярова не читануть. У него глава про С++ довольно урезана, т.е. там объясняются только самые базовые конструкции C++, не написано ничего ни про STL, ни про паттерны какие-нибудь. Но по сути, то что объясняется это и есть сам чистый С++. Потом, если охота можно и чего другого навернуть.
А чё столярова не читануть. У него глава про С++ довольно урезана, т.е. там объясняются только самые базовые конструкции C++, не написано ничего ни про STL, ни про паттерны какие-нибудь. Но по сути, то что объясняется это и есть сам чистый С++. Потом, если охота можно и чего другого навернуть.
>>5339
Не, не пойдёт. Страуструп ещё хуже.
Из того, что я видел, рекомендуют книгу Харви Дейтел, Пол Дейтел «Как программировать на C++».
Ещё лекции Константина Владимирова крутые и книжка Скотта Майерса «Эффективный и современный C++», но это для тех, кто уже смешарик.
Не, не пойдёт. Страуструп ещё хуже.
Из того, что я видел, рекомендуют книгу Харви Дейтел, Пол Дейтел «Как программировать на C++».
Ещё лекции Константина Владимирова крутые и книжка Скотта Майерса «Эффективный и современный C++», но это для тех, кто уже смешарик.