В любом учебнике, отдельно что потокам, что управлению памятью больше информации даётся. Тут всё очень поверхностно, чисто для рекламы курсов. Ещё и RAII зачем-то натягивается на си. Стоит объяснять людям, что не любой ресурс надо освобождать. Если программа запускается, выполняет одну задачу и завершается, ничего освобождать не нужно, ОС всё сделает за вас. Если программа аллоцирует ресурсы, а потом работает с ними в цикле (и в цикле никакие ресурсы не выделяются), то тоже ничего освобождать не нужно. Для управления памятью можно использовать не стандартный malloc, а arena allocator, да не всегда, но когда можно, жизнь он упрощает, ещё и работает быстрее, чем malloc. Потому что не нужно следить за жизнью 1000 ресурсов, потому что можно одним вызовом free освободить сразу всю 1000. Иногда можно использовать scratch arena (не знаю, как на русский перевести), там вообще можно ничего не освобождать. Передал в функцию копию аллокатора (не ссылку), функция что-то там повыделяла, но менялась при этом только копия аллокатора, а значит после завершения функции, вся память, ею выделенная считается доступной. Надо про это рассказывать, а не про то, как натягивать сову RAII на глобус Си.
UPD: ну и как выше заметили, про статическое выделение памяти тоже надо рассказывать. Многие вещи можно вообще без аллокаций сделать: например сетевые клиенты или игровые движки
Насколько я помню, в SFML есть не только создание окна и 2d рендеринг. Там ещё есть поддержка различных графических форматов и вывода аудио. Так что смысл всё же имеется (некоторые предпочитают SDL, но он имеет сишный интерфейс).
Можно инициализировать OpenGL контекст и весь рендеринг с его помощью делать, а SFML использовать для создания окна, обработки ввода и проигрывания аудио.
Всегда интересно читать историю разработки какого-нибудь проекта. Первая статья, конечно, мало чем отличается от типичного гайда по SFML, ну так ведь это первая статья из цикла. Надеюсь, дальше будет интереснее
У меня просто не возникало причин его использовать. Развернуть проект локально очень просто (ставим rbenv, mysql, redis, rabbitmq, а потом bundle install). Хотфикс вимом у нас никто не делает, только merge request в master, а потом деплой через ci/cd. Стенды мы ансиблом поднимаем, проблем не возникает.
Сложилось такое впечатление из-за этого предложения
Я пришел в компанию, уже 2 года назад, можно сказать для построение IT направление. По началу - это GitHub + Vercel(да-да, и фронт и бек в рамках 1 проекта), позже новый бек, новый фронт - уже два проекта
Около 20 сервисов на данный момент, в процессе распила основного бека
У нас их штук 10, и докер мы не используем, деплой пишется тоже очень просто. Поэтому мне и стало интересно, а зачем вообще докер нужен
А зачем вам в данной ситуации kubernetes? Я так понял, он нужен, когда у вас куча микросервисов, у каждого из которых может быть несколько инстансов, и всё это дело на разных хостах запускается. У вас же есть только бекенд. Есть ещё вопрос к знающим людям, а зачем вообще использовать в таких простых случаях докер, можно же взять какой-нибудь capistrano и точно так же деплоить из CI?
Менуэт - это же танец, а автор - Фин. Самое очевидное, что мне приходит в голову, вряд ли пришло бы в голову автору, так как русский он не знает. Может тут что-то менее очевидное?
Я тоже долгое время на VimPlug сидел, потому что лень было разбираться с lua плагинами. Но в этой конфигурации не хватает, как минимум, Coc.nvim или встроенного lsp. Без lsp большие проекты очень сложно разрабатывать.
Опять статья про установку плагинов в (Neo)Vim. Сколько можно? От языка программирования вообще ничего не меняется, я как человек, который языков 10 в виме попробовал говорю. Ну и смысл тогда писать очередную статью про установку плагинов для %language name%?
Ну не знаю, рано или поздно новичку придётся решать конфликты в зависимостях (это же всё ещё rolling release). Интересно, справится ли он, и не надоест ли это ему после n-го раза?
Тут согласен. Плюс rolling release иногда выстреливает в ногу, если долго не обновляться, и приходится решать конфликты в зависимостях. Я поэтому ушёл с арча на федору, с ней пока ни разу не возникало таких проблем
На самом деле ничего сложного в том, чтобы поставить арч нет, надо просто следовать инструкциям с вики, но согласен новичку оно нафиг не надо. Можно взять голую федору, например, и на неё поставить всё, что нужно. Я так сделал и почти ни о чём не жалею
UPD: вспомнил, что glBufferData можно и во второй версии использовать, тогда и правда интересно, что там такое из новой версии используется (мб какие-нибудь возможности glsl, которые с 3-й версии появляются)
Вопрос был, почему кто-то ради 2.5 человек с компами из 2008 должен использовать старый OpenGL? Это претензия на уровне, почему 32-х битный интел перестают поддерживать. Я не специалист в OpenGL, но смею предположить, что третья версия производительнее, чем вторая, как минимум засчёт того, что не надо точки отдельно друг от друга грузить, а можно сразу одним вызовом загрузить их все (я про glVertex3f и glBufferData).
Ну так Вам более защищённая альтернатива нужна - с управлением памятью - или полная свобода маньяка-мазохиста, где кодинг - это хождение по краю пропасти!
Мы явно друг друга не поняли. Там где можно взять Go или Kotlin не стоит вопроса брать или не брать C, C++. Ответ однозначный - не брать.
У Rust тоже есть управление памятью - но да - переложенное на плечи программиста и компилятора - маньякам-мазохистам понравится!
rand() % wordsA.size() - насчет UB не скажу, но, лично для меня, такая конструкция при индексировании массива выглядит угрожающе (выход за границы массива 99,9% не произойдет, но таки вдруг).
С чего бы ему произойти? Результат же будет лежать в интервале [0; wordsA.size() - 1]
В любом учебнике, отдельно что потокам, что управлению памятью больше информации даётся. Тут всё очень поверхностно, чисто для рекламы курсов. Ещё и RAII зачем-то натягивается на си. Стоит объяснять людям, что не любой ресурс надо освобождать. Если программа запускается, выполняет одну задачу и завершается, ничего освобождать не нужно, ОС всё сделает за вас. Если программа аллоцирует ресурсы, а потом работает с ними в цикле (и в цикле никакие ресурсы не выделяются), то тоже ничего освобождать не нужно. Для управления памятью можно использовать не стандартный malloc, а arena allocator, да не всегда, но когда можно, жизнь он упрощает, ещё и работает быстрее, чем malloc. Потому что не нужно следить за жизнью 1000 ресурсов, потому что можно одним вызовом free освободить сразу всю 1000. Иногда можно использовать scratch arena (не знаю, как на русский перевести), там вообще можно ничего не освобождать. Передал в функцию копию аллокатора (не ссылку), функция что-то там повыделяла, но менялась при этом только копия аллокатора, а значит после завершения функции, вся память, ею выделенная считается доступной. Надо про это рассказывать, а не про то, как натягивать сову RAII на глобус Си.
UPD: ну и как выше заметили, про статическое выделение памяти тоже надо рассказывать. Многие вещи можно вообще без аллокаций сделать: например сетевые клиенты или игровые движки
Насколько я помню, в SFML есть не только создание окна и 2d рендеринг. Там ещё есть поддержка различных графических форматов и вывода аудио. Так что смысл всё же имеется (некоторые предпочитают SDL, но он имеет сишный интерфейс).
Можно инициализировать OpenGL контекст и весь рендеринг с его помощью делать, а SFML использовать для создания окна, обработки ввода и проигрывания аудио.
Всегда интересно читать историю разработки какого-нибудь проекта. Первая статья, конечно, мало чем отличается от типичного гайда по SFML, ну так ведь это первая статья из цикла. Надеюсь, дальше будет интереснее
windows-only же
У меня просто не возникало причин его использовать. Развернуть проект локально очень просто (ставим rbenv, mysql, redis, rabbitmq, а потом bundle install). Хотфикс вимом у нас никто не делает, только merge request в master, а потом деплой через ci/cd. Стенды мы ансиблом поднимаем, проблем не возникает.
Сложилось такое впечатление из-за этого предложения
У нас их штук 10, и докер мы не используем, деплой пишется тоже очень просто. Поэтому мне и стало интересно, а зачем вообще докер нужен
А зачем вам в данной ситуации kubernetes? Я так понял, он нужен, когда у вас куча микросервисов, у каждого из которых может быть несколько инстансов, и всё это дело на разных хостах запускается. У вас же есть только бекенд. Есть ещё вопрос к знающим людям, а зачем вообще использовать в таких простых случаях докер, можно же взять какой-нибудь capistrano и точно так же деплоить из CI?
Менуэт - это же танец, а автор - Фин. Самое очевидное, что мне приходит в голову, вряд ли пришло бы в голову автору, так как русский он не знает. Может тут что-то менее очевидное?
Очевидно, что в совершенствовании навыков автора и в создании чего-то своего
Я тоже долгое время на VimPlug сидел, потому что лень было разбираться с lua плагинами. Но в этой конфигурации не хватает, как минимум, Coc.nvim или встроенного lsp. Без lsp большие проекты очень сложно разрабатывать.
А я думал, что Menuet умер и от него ответвился kolibrios, оказывается обе ещё живы
Опять статья про установку плагинов в (Neo)Vim. Сколько можно? От языка программирования вообще ничего не меняется, я как человек, который языков 10 в виме попробовал говорю. Ну и смысл тогда писать очередную статью про установку плагинов для %language name%?
Ну не знаю, рано или поздно новичку придётся решать конфликты в зависимостях (это же всё ещё rolling release). Интересно, справится ли он, и не надоест ли это ему после n-го раза?
Тут согласен. Плюс rolling release иногда выстреливает в ногу, если долго не обновляться, и приходится решать конфликты в зависимостях. Я поэтому ушёл с арча на федору, с ней пока ни разу не возникало таких проблем
На самом деле ничего сложного в том, чтобы поставить арч нет, надо просто следовать инструкциям с вики, но согласен новичку оно нафиг не надо. Можно взять голую федору, например, и на неё поставить всё, что нужно. Я так сделал и почти ни о чём не жалею
UPD: вспомнил, что glBufferData можно и во второй версии использовать, тогда и правда интересно, что там такое из новой версии используется (мб какие-нибудь возможности glsl, которые с 3-й версии появляются)
Вопрос был, почему кто-то ради 2.5 человек с компами из 2008 должен использовать старый OpenGL? Это претензия на уровне, почему 32-х битный интел перестают поддерживать. Я не специалист в OpenGL, но смею предположить, что третья версия производительнее, чем вторая, как минимум засчёт того, что не надо точки отдельно друг от друга грузить, а можно сразу одним вызовом загрузить их все (я про glVertex3f и glBufferData).
Мы явно друг друга не поняли. Там где можно взять Go или Kotlin не стоит вопроса брать или не брать C, C++. Ответ однозначный - не брать.
Ну не знаю, тут совсем надо быть мазохистом
С чего бы ему произойти? Результат же будет лежать в интервале [0; wordsA.size() - 1]
А про коды клавиш верно заметили