Не полностью фразу написал, а поправить уже не успел. Имеется ввиду, что в nightly уже есть, так что до stable недолго. С учётом, что фича не делает глобальных изменений в коде, я надеюсь её вытащат из-под гейта без проволочек.
ПэйПасс. Как по мне, дырень из дыреней. За счёт антенны в карте спокойно работает на расстоянии «с соседнего сиденья в маршрутке сквозь карман». Я например в таком вопросе как деньги вообще не понимаю всех этих «облегчаторов». Идеально КМК — одноразовый пин на любую операцию.
Увы, это никак не предотвратит предустановку дырявых "улучшайзеров" производителями устройств и полную невозможность удалять их без "рутования" устройства.
Использовать исключения для control flow кажется мне не лучшей идеей. Особенно если функция по своей семантике возвращает или значение, или "здесь такой не проживает". Для этого и служит Option.
Если нужен именно геймдев, а не фокусы, ориентированные на производительность, я бы посоветовал смотреть в сторону Unity, Love (есть такой микро-движок с написанием кода на Lua). Проблема С++-ориентированных вещей в сложности самого языка и нескольких наследственных его проблем. Piston, как ни прискорбно, пока скорее "движок" чем "конструктор" игр.
Так держать!
Сам начал программировать лет в 13-14. Хотел тут понаписывать всяких "умных" советов, но оставлю, пожалуй, только один. Почаще задавай себе вопрос "как это устроено?".
Багов много из-за гадости под названием "неявное приведение". Уберите неявное приведение между знаковыми и беззнаковыми — и всё внезапно становится гораздо лучше. Хотя в Java оно может и не так сильно нужно.
Проблема в том, что С++ — это easy unsafe, hard safe. А Java и многие другие платформы — наоборот. На С++ надо постараться, чтобы не отстрелить себе ногу.
А какова «стойкость» этой памяти? Т.е. сколько в среднем живёт такая ячейка без самопроизвольного изменения состояния?
Вообще было бы очень приятно получить хорошую замену как минимум флэш-памяти и жёстким дискам. Первая дорогая и не слишком надёжная, вторые большие, медленные и боятся механических воздействий. Однако, несмотря на количество проектов неволатильной памяти, ни одна не вышла на широкий рынок. Максимум — нишевые решения. Так что я повременю радоваться пока не выпустят хоть одну небольшую серию потребительских железок.
Я извиняюсь за немного оффтопный вопрос.
Почему большинство скриптовых языков работают поверх ВМ с динамической типизацией? Есть ли какие-то ограничения кроме сложности реализации?
Вопрос возник в связи с осмотром моддабельности очередной игрушки на Lua. Проблема — 0 документации. В условиях языков со статической типизацией можно было бы что-то прочесть хотя бы по сигнатурам. Здесь же номер не проходит.
Что я могу сказать. Не нравится — не используйте. Как указывалось много раз выше, перемещение включается в конкретных, чётко описанных ситуациях.
Если же вопрос в "плохо спроектировано" — в каком-то смысле да. Основная проблема — старое местоположение остаётся доступным, даже после мува. Если бы это блокировалось компилятором, то и мув-конструкторов, пожалуй, не понадобилось бы. Но сделать старое местоположение недоступным в рамках семантики С++ нельзя — любое значение является прежде всего пачкой байт, которые можно копировать во все концы. А конструкторы перемещения, операторы присваивания и т.п. представляют собой своего рода хуки на эти действия.
С ним банально неудобно работать. Один из кейсов, пусть и редких — набить с помощью вектора массив данных и скормить вместе с владением какой-нибудь функции.
Если вы таскаете по стеку структуру на 100500 полей, вы делаете что-то не так. А мув служит для почти бесплатного перемещения контейнеров, у которых маленьая часть на стеке и большая в куче. Простой пример — вектор на пару сотен килобайт. Без мува, при отдаче владения в функцию, у вас будет копирование. Толстое. С выделением ещё одного куска на пару сотен килобайт и копированием всего содержимого. С мувом — старый вектор отдаст новому владение буфером. И будет "копирование" 1 указателя. С занулением его на старом месте.
Проблема в том, что это просто тяжело осилить одним куском. Это примерно как God Class. Класс, отвечающий за всё и сразу. А помнить о всех тёмных уголках стандарта придётся — даже тем, кому эти мат. функции не нужны.
Не полностью фразу написал, а поправить уже не успел. Имеется ввиду, что в nightly уже есть, так что до stable недолго. С учётом, что фича не делает глобальных изменений в коде, я надеюсь её вытащат из-под гейта без проволочек.
Так на nightly уже
Информации мало. В целом, мне кажется крайне мутным то, что администрация сайта "неожиданно" обнаружила задолженность за 3 (!) месяца.
Увы, это никак не предотвратит предустановку дырявых "улучшайзеров" производителями устройств и полную невозможность удалять их без "рутования" устройства.
Использовать исключения для control flow кажется мне не лучшей идеей. Особенно если функция по своей семантике возвращает или значение, или "здесь такой не проживает". Для этого и служит Option.
Если нужен именно геймдев, а не фокусы, ориентированные на производительность, я бы посоветовал смотреть в сторону Unity, Love (есть такой микро-движок с написанием кода на Lua). Проблема С++-ориентированных вещей в сложности самого языка и нескольких наследственных его проблем. Piston, как ни прискорбно, пока скорее "движок" чем "конструктор" игр.
Так держать!
Сам начал программировать лет в 13-14. Хотел тут понаписывать всяких "умных" советов, но оставлю, пожалуй, только один. Почаще задавай себе вопрос "как это устроено?".
Отличный перевод прекрасного выноса мозга :)
Багов много из-за гадости под названием "неявное приведение". Уберите неявное приведение между знаковыми и беззнаковыми — и всё внезапно становится гораздо лучше. Хотя в Java оно может и не так сильно нужно.
На С++ возможно писать надёжный код. Но это не делает его оптимальным для такой цели.
Проблема в том, что С++ — это easy unsafe, hard safe. А Java и многие другие платформы — наоборот. На С++ надо постараться, чтобы не отстрелить себе ногу.
Вообще было бы очень приятно получить хорошую замену как минимум флэш-памяти и жёстким дискам. Первая дорогая и не слишком надёжная, вторые большие, медленные и боятся механических воздействий. Однако, несмотря на количество проектов неволатильной памяти, ни одна не вышла на широкий рынок. Максимум — нишевые решения. Так что я повременю радоваться пока не выпустят хоть одну небольшую серию потребительских железок.
Я извиняюсь за немного оффтопный вопрос.
Почему большинство скриптовых языков работают поверх ВМ с динамической типизацией? Есть ли какие-то ограничения кроме сложности реализации?
Вопрос возник в связи с осмотром моддабельности очередной игрушки на Lua. Проблема — 0 документации. В условиях языков со статической типизацией можно было бы что-то прочесть хотя бы по сигнатурам. Здесь же номер не проходит.
Что я могу сказать. Не нравится — не используйте. Как указывалось много раз выше, перемещение включается в конкретных, чётко описанных ситуациях.
Если же вопрос в "плохо спроектировано" — в каком-то смысле да. Основная проблема — старое местоположение остаётся доступным, даже после мува. Если бы это блокировалось компилятором, то и мув-конструкторов, пожалуй, не понадобилось бы. Но сделать старое местоположение недоступным в рамках семантики С++ нельзя — любое значение является прежде всего пачкой байт, которые можно копировать во все концы. А конструкторы перемещения, операторы присваивания и т.п. представляют собой своего рода хуки на эти действия.
С ним банально неудобно работать. Один из кейсов, пусть и редких — набить с помощью вектора массив данных и скормить вместе с владением какой-нибудь функции.
Если вы таскаете по стеку структуру на 100500 полей, вы делаете что-то не так. А мув служит для почти бесплатного перемещения контейнеров, у которых маленьая часть на стеке и большая в куче. Простой пример — вектор на пару сотен килобайт. Без мува, при отдаче владения в функцию, у вас будет копирование. Толстое. С выделением ещё одного куска на пару сотен килобайт и копированием всего содержимого. С мувом — старый вектор отдаст новому владение буфером. И будет "копирование" 1 указателя. С занулением его на старом месте.
Проблема в том, что это просто тяжело осилить одним куском. Это примерно как God Class. Класс, отвечающий за всё и сразу. А помнить о всех тёмных уголках стандарта придётся — даже тем, кому эти мат. функции не нужны.