Общий синтаксис обработки исключений выглядит следующим образом:
Нет, это не так. Каждому блоку __try{...} должен соответствовать либо один блок __except(...){...}, либо один блок __finally{...}. При этом допускаются вложенные блоки. Но синтаксиса в стиле «несколько catch паровозиком» как в чистых плюсах нет.
См., например, Рихтер «Windows via C/C++», 769с:
Обратите внимание на ключевое слово __except. За блоком try всегда должен следовать либо блок finally, либо блок except. Для данного блока try нельзя указать одновременно и блок finally, и блок except; к тому же за try не может следовать несколько блоков finally или except. Однако try-finally можно вложить в try-except, и наоборот.
Насколько я понял, это просто фундаментальные ошибки. Если убрать треды из обоих верхних примеров, то проблема никуда не уйдёт.
Вызывать функцию класса из списка инициализации для поля можно только такую, которая использует лишь поля класса, что были уже инициализированы (и стоят выше этого поля).
Вызывать виртуальные функции из конструктора и деструктора вообще нельзя (вызов ведёт на ещё не построенный или уже разрушенный «верхний этаж»).
Подозреваю, что эта фича живёт только в рамках дисков с файловыми системами, которые поддерживают дополнительные стримы. Т.е. передача файла по сети — это, всё-таки, операция передачи байт основного стрима. Да и при архивации тем же WinRar, например, альтернативные стримы теряются.
Это же просто супер! Всегда хотелось, чтобы к файлам из интернета привязывался их урл, откуда они. Часто бывает, что накачаешь файлов отовсюду, а потом ссылки на оригиналы не найти, а сослаться надо. Я даже в долгосрочных планах свой колхоз хотел писать, чтобы в альтернативные стримы урлы закидывать. А оказывается, что у меня всё это уже из коробки есть, только достать нужно.
Это жесть, конечно. Но научиться всё это видеть и отсекать лишнее можно.
Не намерены останавливаться/стоять — большая часть знаков сразу отсекается.
Увидели сам лежачий или знак — ограничения скорости отсекаются (по нему просто и так нужно проезжать меньше 20, не помню, есть ли это в ПДД, но это просто разумно).
Пешеходные и «осторожно, дети» — тоже не сильно важная инфа, судя по внешнему виду улицы, пешеходы и так появиться на проезжей части там могут в любой момент — гнать и терять внимание нельзя и так.
Так, на уровне идеи:
Можно решить проблему выедания пользователем ресурсов тем, что сделать их платными (за операцию/единицу памяти или за операцию/единицу памяти сверх лимита, и т.п.). При этом платой может быть какой-нибудь внутриигровой ресурс, который пользователями же и будет добываться в игровом мире, эдакое топливо для бота. Что-то по примерной аналогии с gas в Ethereum.
При этом для разработчика такой системы возникнет много интересных задач на подумать, как всё это дело отбалансить, а для игроков потом — как оптимизировать свой код и сколько тактов из него выделить на добычу топлива.
Сочувствую, сталкивался с такой же проблемой, почти один в один. Но несмотря на то, что я знал все ответы (и оригинальный пароль, который точно не менялся, и ответ на секретный вопрос, и дату создания аккаунта), меня всё равно не пускали в аккаунт, потому что обнаружили «подозрительную активность», повода для которой я реально не давал. Скорее всего, их роботы посчитали подозрительным, что я заходил в акк через хром в инкогнито или что-нибудь ещё.
Мне в итоге очень повезло, т.к. акк мне восстановили, но геморроя я поимел изрядно. Восстановить получилось через гуглфорум, вот здесь можно почитать мою историю со всеми деталями, возможно, кому-нибудь поможет в аналогичных ситуациях.
Причём, что любопытно, в этот форум особо-то из справки и шаблонных ответов гугла не попадёшь. Т.е. чтобы найти такую возможность, её нужно искать. Ещё интереснее, если копнуть глубже: «поддержка» этого форума — не работники гугла, а энтузиасты. Как я понял, гугл обещал им какие-то призрачные плюшки за статистику (которую там все активно выпрашивают, копипастя устаревшие инструкции гугла и выпрашивая +1), и вот они там сидят, активничают. Но, если повезёт, там можно встретить и человека, у которого есть реальный доступ к сотрудникам гугла (не роботам). И, опять же, если повезёт, то последние порешают твою проблему.
И это вовсе не парадокс, а образец абсолютно корректного следования всеми уважаемому стандарту IEEE 754.
Числа с плавающей запятой в интерпретации IEEE — вообще не числа. Математика требует ассоциативности от операции их сложения.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Похожие особенности есть не только у чисел с плавающей запятой. Встроенные целые числа реализованы не лучше.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Чутье подсказывает, что переполнение даст 0x0000. Однако такой исход не задокументирован ни в одном мировом стандарте. В обработке этой операции все ориентируются на подход C и семейства процессоров x86.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
В качестве альтернативных вариантов может получиться 0xFFFF или будет вызвано прерывание, или некий специальный, указывающий на переполнение бит будет сохранен в особом месте.
А это — другие стандарты.
Такие моменты вообще нигде не рассматриваются, и правила обработки подобных операций отличается от языка к языку.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
overflowed 9999
underflowed 0
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Разве такие вычисления не будут работать медленнее? Да, будут.
Минус пласт пользователей языка.
Насколько я могу судить, типичный программист 21 века нечасто решает дифференциальные уравнения.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
Часть заголовков неправильно отображается в мобильной версии из-за ошибок
в проектировании универсальных компонентов.
МЕТА ДАННЫЕ: SECRETMRKT-578, SECRETMRKT-602
Мне кажется, что тут возникла небольшая ошибка. Коммит — не то, что должно быть сделано, а то, что уже сделано. Что нужно сделать должно быть написано в таске где-то или в требованиях. Как я понял, в этом примере такая информация находится в SECRETMRKT-578, SECRETMRKT-602. Т.е. верный вариант будет
fix(products): поправлена длина строки с ценой
Часть заголовков неправильно отображались в мобильной версии из-за ошибок
в проектировании универсальных компонентов.
МЕТАДАННЫЕ: SECRETMRKT-578, SECRETMRKT-602
И тогда автоформирование Change Log уже взлетит само собой.
UPD: Да, не дочитал. В статье об этом есть в конце. Но мне всё равно кажется это несколько странным.
Подход с шаблонами сразу не прокатит, т.к. нужно знать n именно во время компиляции. А если мы знаем n во время компиляции, то мы просто можем написать
print(n--);
n+1 раз.
Просматривая протоколы собеседований на позицию разработчика, обнаружил такую задачу
Это задачка с искусственными ограничениями (в том плане, что вряд ли они встретятся в реальной задаче компании), поэтому давать её на собеседовании, конечно, можно, но ИМХО только в случае собеседования в клуб извращенцев.
Кстати, вы могли бы этот таск переклассифицировать из баги в фичреквест и не спешить закрывать. Ведь на самом деле ситуация показательная и с другой стороны: лог анализатора не дал трём с половиной программистам понять, что же происходит. Т.е. анализатор умён, спору нет, но мысль свою до людей он не донёс. Может быть, стоит на такие проблемы в логических выражениях выдавать другую ошибку? Какую-нибудь одну, красивую, которая подсветит сереньким цветом выражения, не влияющие на истинность условия, или как-то так? Ведь, насколько я понимаю, вы же всё равно строите деревья разборов этих условий, т.е. самая сложная часть уже есть и отлично работает.
Вот да. Правда, второй вариант не всегда может прокатить, не каждый символ можно так просто добавить в исходник — и в таких случаях я бы рекомендовал завести константы с говорящими именами, типа BIG_LETTER_A или FIRST_BIG_LETTER_EN, а в них уже можно любые коды засовывать, всё равно далее исходник будет читаемым.
А вот третий вариант лично я бы рекомендовал почти всем и всегда. А то и в отдельный метод IsLetterOrDigit.
Ошибку, кстати, нашёл, нарисовав интервалы на прямой, но изначально ожидал от задачи подвох в стиле дефайна скобки в начале файла или чего-то такого.
Абсолютно точно.
То ли в 2014, то ли в 2015 у нас налоговая приняла законы, по которым XML-ины электронной отчётности по размеру стали допустимы до 10гб (вроде бы с изначального «копеечного» лимита 10-100мб), так все решения на DOM'ах очень красиво посыпались, когда пошли клиенты с громадными «контролируемыми сделками» и «книгами для ндс». Потому что DOM одной только памяти жрёт х10 от размера файла, и если раньше (100мб-1гб) на это закрывались глаза, то на 100гб глаза уже не закроешь, не говоря уже о платформе х86.
Делал в те времена в системе электронной отчётности проект по уходу с DOM (легаси было крепко на него завязано, XPath и прочие плюшки активно использовались) на SAX в один пробег, с «эмуляцией» плюшек или обоснованным отказом от них — веселья было много. Теперь в резюме указываю тег XML, а на собеседованиях периодически посмеиваются, мол, что там знать-то, древовидная структура, теги/атрибуты и всё. Так-то оно да, но, как и в физическом мире, когда масса объекта пересекает определённые границы, проявляется много интересных эффектов, о которых даже не думаешь, щупая маленькие объекты.
Хотя, кстати, запамятовал: NP-полная задача — задача какой-либо оптимизации стратегии с известной заранее лентой фигур. И разумное приближение как раз, наверное, будет в том, что состояние стакана в итерации будет фиксировано, а известны будут только текущая и следующая фигуры — т.е. естественные ограничения игры. А все такие комбинации расположения двух фигур можно, думаю, и просто перебрать. Но, всё-таки, рано или поздно ИИ всё равно должен проиграть. arxiv.org/pdf/cs/0210020.pdf
Нет, это не так. Каждому блоку __try{...} должен соответствовать либо один блок __except(...){...}, либо один блок __finally{...}. При этом допускаются вложенные блоки. Но синтаксиса в стиле «несколько catch паровозиком» как в чистых плюсах нет.
См., например, Рихтер «Windows via C/C++», 769с:
Вызывать функцию класса из списка инициализации для поля можно только такую, которая использует лишь поля класса, что были уже инициализированы (и стоят выше этого поля).
Вызывать виртуальные функции из конструктора и деструктора вообще нельзя (вызов ведёт на ещё не построенный или уже разрушенный «верхний этаж»).
А после этого не обращались с тем, что теперь фамилия, имя или отчество не влезает?
Не намерены останавливаться/стоять — большая часть знаков сразу отсекается.
Увидели сам лежачий или знак — ограничения скорости отсекаются (по нему просто и так нужно проезжать меньше 20, не помню, есть ли это в ПДД, но это просто разумно).
Пешеходные и «осторожно, дети» — тоже не сильно важная инфа, судя по внешнему виду улицы, пешеходы и так появиться на проезжей части там могут в любой момент — гнать и терять внимание нельзя и так.
Можно решить проблему выедания пользователем ресурсов тем, что сделать их платными (за операцию/единицу памяти или за операцию/единицу памяти сверх лимита, и т.п.). При этом платой может быть какой-нибудь внутриигровой ресурс, который пользователями же и будет добываться в игровом мире, эдакое топливо для бота. Что-то по примерной аналогии с gas в Ethereum.
При этом для разработчика такой системы возникнет много интересных задач на подумать, как всё это дело отбалансить, а для игроков потом — как оптимизировать свой код и сколько тактов из него выделить на добычу топлива.
Мне в итоге очень повезло, т.к. акк мне восстановили, но геморроя я поимел изрядно. Восстановить получилось через гуглфорум, вот здесь можно почитать мою историю со всеми деталями, возможно, кому-нибудь поможет в аналогичных ситуациях.
Причём, что любопытно, в этот форум особо-то из справки и шаблонных ответов гугла не попадёшь. Т.е. чтобы найти такую возможность, её нужно искать. Ещё интереснее, если копнуть глубже: «поддержка» этого форума — не работники гугла, а энтузиасты. Как я понял, гугл обещал им какие-то призрачные плюшки за статистику (которую там все активно выпрашивают, копипастя устаревшие инструкции гугла и выпрашивая +1), и вот они там сидят, активничают. Но, если повезёт, там можно встретить и человека, у которого есть реальный доступ к сотрудникам гугла (не роботам). И, опять же, если повезёт, то последние порешают твою проблему.
Математика не требует. Требуется то, что описано в стандарте. Т.к. это «вообще не числа», то и непротиворечивые правила можно вводить свои, которые, собственно, были введены в стандарте. Притом оно — неплохое приближение действительных чисел «с обеих сторон» в ограниченных условиях. Если на пальцах, то по своей сути оно ближе к сути действительных чисел: как в теории действительных чисел (см. матан) есть неопределённости, бесконечности и всякие стремления к нулю слева, так и в реализации стандарта они есть. Если реально нужны не действительные числа, а рациональные, то нужно использовать готовые/писать свои реализации приближения рациональных, а не натягивать сову.
Ну потому что это тоже не совсем целые числа, а либо просто их конечное подмножество, либо кольцо вычетов по модулю, либо ещё что-нибудь в зависимости от интерпретации.
Так получается, что подход C — один из мировых стандартов, где исход задокументирован.
А это — другие стандарты.
И, собственно, главный вопрос: а как новый язык решит эту проблему? [Здесь комикс про универсальный стандарт]
Что это вообще такое? Если состояния, то, собственно, чем оно лучше NaN и +Inf, когда мы получаем оспариваемое состояние? Если поведение, то чем оно лучше переполнения, когда мы получаем оспариваемое поведение? Да и, собственно, подобные обрезки точности можно просто реализовать на базовых типах в готовых языках, для этого не нужно изобретать ещё один язык, или они даже есть из коробки: тип DECIMAL(N,M) в SQL или currency в некоторых языках.
Минус пласт пользователей языка.
Минус ещё один пласт пользователей языка.
Т.е. в итоге мы получаем ещё один язык 21 века, у которого другой синтаксис, который вводит новые костыли, новые стандарты и правила, но при этом не отказывается от костылей, стандартов и правил 20 века, и реализации на котором медленнее? Можно не надо?
Мне кажется, что тут возникла небольшая ошибка. Коммит — не то, что должно быть сделано, а то, что уже сделано. Что нужно сделать должно быть написано в таске где-то или в требованиях. Как я понял, в этом примере такая информация находится в SECRETMRKT-578, SECRETMRKT-602. Т.е. верный вариант будет
И тогда автоформирование Change Log уже взлетит само собой.
UPD: Да, не дочитал. В статье об этом есть в конце. Но мне всё равно кажется это несколько странным.
Это задачка с искусственными ограничениями (в том плане, что вряд ли они встретятся в реальной задаче компании), поэтому давать её на собеседовании, конечно, можно, но ИМХО только в случае собеседования в клуб извращенцев.
А вот третий вариант лично я бы рекомендовал почти всем и всегда. А то и в отдельный метод IsLetterOrDigit.
Ошибку, кстати, нашёл, нарисовав интервалы на прямой, но изначально ожидал от задачи подвох в стиле дефайна скобки в начале файла или чего-то такого.
То ли в 2014, то ли в 2015 у нас налоговая приняла законы, по которым XML-ины электронной отчётности по размеру стали допустимы до 10гб (вроде бы с изначального «копеечного» лимита 10-100мб), так все решения на DOM'ах очень красиво посыпались, когда пошли клиенты с громадными «контролируемыми сделками» и «книгами для ндс». Потому что DOM одной только памяти жрёт х10 от размера файла, и если раньше (100мб-1гб) на это закрывались глаза, то на 100гб глаза уже не закроешь, не говоря уже о платформе х86.
Делал в те времена в системе электронной отчётности проект по уходу с DOM (легаси было крепко на него завязано, XPath и прочие плюшки активно использовались) на SAX в один пробег, с «эмуляцией» плюшек или обоснованным отказом от них — веселья было много. Теперь в резюме указываю тег XML, а на собеседованиях периодически посмеиваются, мол, что там знать-то, древовидная структура, теги/атрибуты и всё. Так-то оно да, но, как и в физическом мире, когда масса объекта пересекает определённые границы, проявляется много интересных эффектов, о которых даже не думаешь, щупая маленькие объекты.
arxiv.org/pdf/cs/0210020.pdf