Увы, я в курсе, что там куча комитетов.
Я хотел бы, чтобы велась разработка не стандарта, а референсного компилятора с участием всех заинтересованных сторон. Я так же в курсе, что "не судьбец".
То, что их добавление не задерживает принятие стандарта, не повод их в стандарт добавлять. Ещё 200 страниц к талмуду. Причём с пользой для очень узкого круга пользователей.
Это был горький сарказм если что. Про то, что в стандарт засунули то, что могло спокойно сидеть в tensorflow и дальше. Зато нет целой кучи базовых строительных блоков.
Зета-функция, полиномы Лежандра и т.п. безусловно важные и нужные штуки — но применяемые в довольно узкой области.
Увы, в стандарте до сих пор нет хоть какой-то подборки готовых адаптеров итераторов. Зато с 17-го есть зета-функция Римана — ну очень важная и нужная абсолютно всем программистам на С++.
Я почему-то подозреваю, что трабл у них начинается не при парсинге выражения, а на стыке вывода типов и разрешения перегрузок. Но то, что ребята не освоили какого-нибудь Хиндли-Милнера, не извиняет их.
Кстати, может чего упустил, но вроде эта проблема была ещё во 2-й версии, и её клятвенно обещали пофиксить.
Для справки. НАСА — просто первое крупное научное агентство, пришедшее на ум. Подойдёт любое другое б/м авторитетное. Национальная принадлежность значения не имеет.
Проблема в том, что обычно мажорный релиз языка выпускают с большой подготовкой и редко — с промежутком лет эдак в 10. Питон, как пример, до сих пор тянет 2 ветки. Эппл просто выкидывает на помойку часть того что было ранее. Это не добавляет энтузиазма.
Благодарю, я читал эту фразу. Проблема в том, что эта фраза противоречит действиям Эппл, если исходить из общепринятых практик. Общепринятые практики (semver) говорят, что смена мажорной версии — сигнал об обратной несовместимости. Эппл поменяли мажорную версию — по логике 4-я должна иметь проблемы с компиляцией 3-й. Но исходя из их заявления это не так. Тогда зачем было менять мажорную версию? Короче, я подозреваю что разработчикам под экосистему Эппл таки придётся в очередной раз переписывать код.
Тогда не понятно почему 4.0
Смена мажорной версии обычно говорит об отсутствии обратной совместимости. Простой вопрос. Будет ли 4.0 компилировать 3.* без изменений и "битой семантики"?
Напрашивается сравнение с EM-Drive. Ведро с магнетроном, которое непонятно как, но работает. Причём факт работы подтверждён несколькими исследованиями, в т.ч. НАСА.
И здесь — принцип работы и разрешение дают по факту при подписи NDA. Вам ничего не кажется странным? Если бы Понс-Флейшман, Росси, Миллс нашли что-то реально стоящее — была бы проверка независимыми исследователями. Вот дайте ссылку на проверку от НАСА или кого ещё авторитетного.
Кстати о птичках. Не так давно пытался поймать презабавнейший баг при работе WPF в COM плагине для одной толстой софтинки. В зависимости от фазы луны при завершении всего этого добра, при уничтожении дескриптора нижележащего нативного окна в потоке финализаторов происходил эксепшен, который, внимание, дотнет пытался циклически преобразовать в нативный и обратно, чем вызывал переполнение стека.
Вывод: господа МС, приведите сначала в порядок свой зоопарк.
Немного возражу. Безусловно, вы не увидите разницы на единичном запуске. Зато прекрасно увидите, если данная утилита запускается раз эдак 200 подряд каким-то управляющим скриптом.
На проекте был случай — запускался набор тестов с использованием NodeJS. На каждый тест запускался отдельный инстанс. После того, как эту мини-утилитку переделали в примитивный сервер, которому все данные скармливаются через банальный сокет, время прогона уменьшилось раза в три. Просто за счёт толстого инита при запуске, который нельзя было обрезать никак.
Уточните пожалуйста, в каком режиме он живёт эти 3 дня? Если в режиме «на полке», то это, уж простите, феерическая лажа.
Galaxy Ace 2 с просевшим от старости аккумулятором (исходная ёмкость что-то около 1500mAh) можно пользоваться 3 дня в режиме «немного позвонить, немного интернета».
По идее тот, что каждый клиент может просчитывать позицию каждого игрока на поле без непрерывной "подпитки" координатами. Т.е. мы знаем, что игрок движется со скоростью V. Если от оппонента пришло событие "начал двигаться вправо", мы можем полностью просчитать его положение на основании флага движения, известной скорости и текущей координаты. Так как противник предсказуемо переместится из позиции А в позицию А + Dir V Dt. Тогда мы будем менять механику движений только при изменении "флагов движения". А вместе с командами на смену флагов можно присылать координаты точки, в которой это случилось — чтобы подкорректировать ошибки.
Т.е. мы передаём не состояния игрового мира, а события в игровом мире — что дешевле по объёму, и делать надо реже.
И интерполяция как органичное следствие, а не костыль.
А если передавать не позиции, а действия игрока?
"Игрок начал двигаться вправо"
"Игрок начал прыжок"
"Игрок закончил прыжок"
с добавкой в виде координат и метадаты для синхронизации
Ну и может таки отправлять периодически сообщения синхронизации
Тогда, по идее, и анимацию не надо передавать — она может обсчитываться на клиенте
Ладно, давайте закроем тему. Иначе сейчас будем спорить, у кого выборка репрезентативней.
Увы, я в курсе, что там куча комитетов.
Я хотел бы, чтобы велась разработка не стандарта, а референсного компилятора с участием всех заинтересованных сторон. Я так же в курсе, что "не судьбец".
То, что их добавление не задерживает принятие стандарта, не повод их в стандарт добавлять. Ещё 200 страниц к талмуду. Причём с пользой для очень узкого круга пользователей.
Это был горький сарказм если что. Про то, что в стандарт засунули то, что могло спокойно сидеть в tensorflow и дальше. Зато нет целой кучи базовых строительных блоков.
Зета-функция, полиномы Лежандра и т.п. безусловно важные и нужные штуки — но применяемые в довольно узкой области.
Увы, в стандарте до сих пор нет хоть какой-то подборки готовых адаптеров итераторов. Зато с 17-го есть зета-функция Римана — ну очень важная и нужная абсолютно всем программистам на С++.
Я почему-то подозреваю, что трабл у них начинается не при парсинге выражения, а на стыке вывода типов и разрешения перегрузок. Но то, что ребята не освоили какого-нибудь Хиндли-Милнера, не извиняет их.
Кстати, может чего упустил, но вроде эта проблема была ещё во 2-й версии, и её клятвенно обещали пофиксить.
Бесспорно, имеет. Но не каждый же год её ломать.
Проблема в том, что обычно мажорный релиз языка выпускают с большой подготовкой и редко — с промежутком лет эдак в 10. Питон, как пример, до сих пор тянет 2 ветки. Эппл просто выкидывает на помойку часть того что было ранее. Это не добавляет энтузиазма.
Благодарю, я читал эту фразу. Проблема в том, что эта фраза противоречит действиям Эппл, если исходить из общепринятых практик. Общепринятые практики (semver) говорят, что смена мажорной версии — сигнал об обратной несовместимости. Эппл поменяли мажорную версию — по логике 4-я должна иметь проблемы с компиляцией 3-й. Но исходя из их заявления это не так. Тогда зачем было менять мажорную версию? Короче, я подозреваю что разработчикам под экосистему Эппл таки придётся в очередной раз переписывать код.
Тогда не понятно почему 4.0
Смена мажорной версии обычно говорит об отсутствии обратной совместимости. Простой вопрос. Будет ли 4.0 компилировать 3.* без изменений и "битой семантики"?
И здесь — принцип работы и разрешение дают по факту при подписи NDA. Вам ничего не кажется странным? Если бы Понс-Флейшман, Росси, Миллс нашли что-то реально стоящее — была бы проверка независимыми исследователями. Вот дайте ссылку на проверку от НАСА или кого ещё авторитетного.
Чисто для справки. Безлексерный способ разбора с неограниченным бэктрекингом https://en.wikipedia.org/wiki/Parsing_expression_grammar
Кстати о птичках. Не так давно пытался поймать презабавнейший баг при работе WPF в COM плагине для одной толстой софтинки. В зависимости от фазы луны при завершении всего этого добра, при уничтожении дескриптора нижележащего нативного окна в потоке финализаторов происходил эксепшен, который, внимание, дотнет пытался циклически преобразовать в нативный и обратно, чем вызывал переполнение стека.
Вывод: господа МС, приведите сначала в порядок свой зоопарк.
Немного возражу. Безусловно, вы не увидите разницы на единичном запуске. Зато прекрасно увидите, если данная утилита запускается раз эдак 200 подряд каким-то управляющим скриптом.
На проекте был случай — запускался набор тестов с использованием NodeJS. На каждый тест запускался отдельный инстанс. После того, как эту мини-утилитку переделали в примитивный сервер, которому все данные скармливаются через банальный сокет, время прогона уменьшилось раза в три. Просто за счёт толстого инита при запуске, который нельзя было обрезать никак.
Galaxy Ace 2 с просевшим от старости аккумулятором (исходная ёмкость что-то около 1500mAh) можно пользоваться 3 дня в режиме «немного позвонить, немного интернета».
По идее тот, что каждый клиент может просчитывать позицию каждого игрока на поле без непрерывной "подпитки" координатами. Т.е. мы знаем, что игрок движется со скоростью V. Если от оппонента пришло событие "начал двигаться вправо", мы можем полностью просчитать его положение на основании флага движения, известной скорости и текущей координаты. Так как противник предсказуемо переместится из позиции А в позицию А + Dir V Dt. Тогда мы будем менять механику движений только при изменении "флагов движения". А вместе с командами на смену флагов можно присылать координаты точки, в которой это случилось — чтобы подкорректировать ошибки.
Т.е. мы передаём не состояния игрового мира, а события в игровом мире — что дешевле по объёму, и делать надо реже.
И интерполяция как органичное следствие, а не костыль.
А если передавать не позиции, а действия игрока?
"Игрок начал двигаться вправо"
"Игрок начал прыжок"
"Игрок закончил прыжок"
с добавкой в виде координат и метадаты для синхронизации
Ну и может таки отправлять периодически сообщения синхронизации
Тогда, по идее, и анимацию не надо передавать — она может обсчитываться на клиенте