В эмбеде — никак. Потому что подобный эмбед на 99.(9)% — голый C, как я понимаю. Который в принципе не умеет tail call optimization — и даже не понимает, что это такое.
Не полностью фразу написал, а поправить уже не успел. Имеется ввиду, что в nightly уже есть, так что до stable недолго. С учётом, что фича не делает глобальных изменений в коде, я надеюсь её вытащат из-под гейта без проволочек.
ПэйПасс. Как по мне, дырень из дыреней. За счёт антенны в карте спокойно работает на расстоянии «с соседнего сиденья в маршрутке сквозь карман». Я например в таком вопросе как деньги вообще не понимаю всех этих «облегчаторов». Идеально КМК — одноразовый пин на любую операцию.
Увы, это никак не предотвратит предустановку дырявых "улучшайзеров" производителями устройств и полную невозможность удалять их без "рутования" устройства.
Использовать исключения для control flow кажется мне не лучшей идеей. Особенно если функция по своей семантике возвращает или значение, или "здесь такой не проживает". Для этого и служит Option.
Если нужен именно геймдев, а не фокусы, ориентированные на производительность, я бы посоветовал смотреть в сторону Unity, Love (есть такой микро-движок с написанием кода на Lua). Проблема С++-ориентированных вещей в сложности самого языка и нескольких наследственных его проблем. Piston, как ни прискорбно, пока скорее "движок" чем "конструктор" игр.
Так держать!
Сам начал программировать лет в 13-14. Хотел тут понаписывать всяких "умных" советов, но оставлю, пожалуй, только один. Почаще задавай себе вопрос "как это устроено?".
Багов много из-за гадости под названием "неявное приведение". Уберите неявное приведение между знаковыми и беззнаковыми — и всё внезапно становится гораздо лучше. Хотя в Java оно может и не так сильно нужно.
Проблема в том, что С++ — это easy unsafe, hard safe. А Java и многие другие платформы — наоборот. На С++ надо постараться, чтобы не отстрелить себе ногу.
А какова «стойкость» этой памяти? Т.е. сколько в среднем живёт такая ячейка без самопроизвольного изменения состояния?
Вообще было бы очень приятно получить хорошую замену как минимум флэш-памяти и жёстким дискам. Первая дорогая и не слишком надёжная, вторые большие, медленные и боятся механических воздействий. Однако, несмотря на количество проектов неволатильной памяти, ни одна не вышла на широкий рынок. Максимум — нишевые решения. Так что я повременю радоваться пока не выпустят хоть одну небольшую серию потребительских железок.
Я извиняюсь за немного оффтопный вопрос.
Почему большинство скриптовых языков работают поверх ВМ с динамической типизацией? Есть ли какие-то ограничения кроме сложности реализации?
Вопрос возник в связи с осмотром моддабельности очередной игрушки на Lua. Проблема — 0 документации. В условиях языков со статической типизацией можно было бы что-то прочесть хотя бы по сигнатурам. Здесь же номер не проходит.
Что я могу сказать. Не нравится — не используйте. Как указывалось много раз выше, перемещение включается в конкретных, чётко описанных ситуациях.
Если же вопрос в "плохо спроектировано" — в каком-то смысле да. Основная проблема — старое местоположение остаётся доступным, даже после мува. Если бы это блокировалось компилятором, то и мув-конструкторов, пожалуй, не понадобилось бы. Но сделать старое местоположение недоступным в рамках семантики С++ нельзя — любое значение является прежде всего пачкой байт, которые можно копировать во все концы. А конструкторы перемещения, операторы присваивания и т.п. представляют собой своего рода хуки на эти действия.
В эмбеде — никак. Потому что подобный эмбед на 99.(9)% — голый C, как я понимаю. Который в принципе не умеет tail call optimization — и даже не понимает, что это такое.
А в чём там ограниченность? Действительно не в курсе. Я думал, что всё сводится к анонимизации исходного типа — так это уже вроде есть.
Да
fn iota(n: u32) -> impl Iterator<Item=u32>Значение неважно какого типа, поддерживающее указанный trait bound
Не полностью фразу написал, а поправить уже не успел. Имеется ввиду, что в nightly уже есть, так что до stable недолго. С учётом, что фича не делает глобальных изменений в коде, я надеюсь её вытащат из-под гейта без проволочек.
Так на nightly уже
Информации мало. В целом, мне кажется крайне мутным то, что администрация сайта "неожиданно" обнаружила задолженность за 3 (!) месяца.
Увы, это никак не предотвратит предустановку дырявых "улучшайзеров" производителями устройств и полную невозможность удалять их без "рутования" устройства.
Использовать исключения для control flow кажется мне не лучшей идеей. Особенно если функция по своей семантике возвращает или значение, или "здесь такой не проживает". Для этого и служит Option.
Если нужен именно геймдев, а не фокусы, ориентированные на производительность, я бы посоветовал смотреть в сторону Unity, Love (есть такой микро-движок с написанием кода на Lua). Проблема С++-ориентированных вещей в сложности самого языка и нескольких наследственных его проблем. Piston, как ни прискорбно, пока скорее "движок" чем "конструктор" игр.
Так держать!
Сам начал программировать лет в 13-14. Хотел тут понаписывать всяких "умных" советов, но оставлю, пожалуй, только один. Почаще задавай себе вопрос "как это устроено?".
Отличный перевод прекрасного выноса мозга :)
Багов много из-за гадости под названием "неявное приведение". Уберите неявное приведение между знаковыми и беззнаковыми — и всё внезапно становится гораздо лучше. Хотя в Java оно может и не так сильно нужно.
На С++ возможно писать надёжный код. Но это не делает его оптимальным для такой цели.
Проблема в том, что С++ — это easy unsafe, hard safe. А Java и многие другие платформы — наоборот. На С++ надо постараться, чтобы не отстрелить себе ногу.
Вообще было бы очень приятно получить хорошую замену как минимум флэш-памяти и жёстким дискам. Первая дорогая и не слишком надёжная, вторые большие, медленные и боятся механических воздействий. Однако, несмотря на количество проектов неволатильной памяти, ни одна не вышла на широкий рынок. Максимум — нишевые решения. Так что я повременю радоваться пока не выпустят хоть одну небольшую серию потребительских железок.
Я извиняюсь за немного оффтопный вопрос.
Почему большинство скриптовых языков работают поверх ВМ с динамической типизацией? Есть ли какие-то ограничения кроме сложности реализации?
Вопрос возник в связи с осмотром моддабельности очередной игрушки на Lua. Проблема — 0 документации. В условиях языков со статической типизацией можно было бы что-то прочесть хотя бы по сигнатурам. Здесь же номер не проходит.
Что я могу сказать. Не нравится — не используйте. Как указывалось много раз выше, перемещение включается в конкретных, чётко описанных ситуациях.
Если же вопрос в "плохо спроектировано" — в каком-то смысле да. Основная проблема — старое местоположение остаётся доступным, даже после мува. Если бы это блокировалось компилятором, то и мув-конструкторов, пожалуй, не понадобилось бы. Но сделать старое местоположение недоступным в рамках семантики С++ нельзя — любое значение является прежде всего пачкой байт, которые можно копировать во все концы. А конструкторы перемещения, операторы присваивания и т.п. представляют собой своего рода хуки на эти действия.