Поэтому в этот раз я проделал довольно много дополнительной работы, чтобы исключить из отчёта ранее найденные ошибки.
Как-то это плохо стыкуется с утверждениями из статей про внедрение PVS Studio на больших проектах, о том, что можно запустить анализ, пометить всё ошибки как "базовый уровень", и в последующих анализах видеть только новые ошибки. Я думал, это делается в несколько кликов.
Так это просто для иллюстрации того, сколько раз выполняется сравнение. Когда коллекция большая, а сравнение медленное, могут возникнуть проблемы, там где их не ждёшь. А захват тут не при чем.
Кроме того, это никак р-не противоречит моему доводы о том, что "простая мнемоника никогда не делайте multiple enumeration по enumerable" снимает не все проблемы.
Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны. И то, что несколько человек на этом попались, опровергает тезис "нельзя".
Увы не полностью. С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца, но легко упустить, что после Where мы имеем дело не с массивом (как вы уже написали ниже), и обход будет полным. Так что пусть пример несколько синтетический, но полезная информация в нём определённо есть, чтобы не попадаться на таких ловушках.
цинк-65, чья радиоактивность будет гораздо выше на начальном этапе и, соответственно, спадет быстрее. Но этот изотоп составляет лишь примерно половину природного цинка, поэтому для военного применения его пришлось бы обогащать.
Вряд ли его стали бы обогащать, если бы решили использовать в качестве оружия. Просто смирились бы с КПД 1/2 от теоретического (если конечно можно назвать такое "действие" "полезным")
Так ведь есть исследования, что будучи изолированным от внешней среды (например, в пещере), организм имеет тенденцию переходить на удлинённый цикл сна/бодрствования. Там, конечно, много факторов оказывают влияние, но в межзвёздных странствиях нет объективных предпосылок против установления размера цикла в 100 Кс (27:46 на наши деньги). Жаль в СИ не предусмотрено стандартной приставки для 100 000
Проблемы с календарями во многом вызваны стремлением сохранить привязку к природным циклам - т.е. приравнять год к периоду обращения Земли вокруг Солнца, а сутки - к периоду оборота вокруг оси. В, условно, стандартном галактическом времени это не имело бы смысла, там логичнее было бы измерять время кило-, мега-, гигасекундами. Например, в течение одной Мс рабочему предоставляется 300Кс выходных, кроме того ему полагается оплачиваемый отпуск в 1Мс один раз в 20Мс... Операции с датами станут тривиальными, а вот перевод в архаичные земные единицы останется всё таким же заморочным.
(Удивляет, что во всякой космической фантастике продолжают считать время земными единицами; впрочем, я тут не очень начитан)
Поддержу. У нас американский ПМ, когда отключается от созвона, обычно говорит "I'm bailing". Brolly в значении "зонтик" буквально недавно впервые услышал, причём от британцев.
Я когда сыроделием увлекался, столкнулся со сложностями перевода. В русском языке на разных стадиях вы имеет дело со сгустком, сырным зерном, сырной массой, сырным тестом. А в английском это всё называется curd. И творог тоже curd (либо cottage cheese). И омонимичность слов "плесень" и "форма" (то и другое mold) тоже иногда мешает, впрочем, не слишком сильно, обычно из контекста понятно.
Мне кажется, дело тут не столько в том, насколько "умён" DI-фреймворк, а в том, что в разных ситуациях разработчику может требоваться разное поведение - иногда ему принципиально важно получить один и тот же экземпляр, внедряя зависимость по любому из его интерфейсов, а в других случаях - принципиально важно, чтобы создавался новый экземпляр. DI от Microsoft предоставляет возможность это сделать, а значит свою задачу решает (пусть и не самым интуитивным образом). Тем более что в подавляющем большинстве случаев это вообще не имеет значение, т.к. класс регистрируется по одному интерфейсу.
Да и я бы не сказал, что принцип дурацкий; при написании кода мы практически всегда стараемся в той или иной мере ему следовать, пуусть и неосознанно. Например (в C#), переопределяя метод ToString, обычно никто не будет выбрасывать исключений, а спроси почему это плохая идея - ответят, что вызывающий код может не знать, что объект такого типа требует особого обращения, и вызвать ToString, и неожиданно упасть. Или, к примеру, реализуя метод Equals, технически мы можем делать всё что угодно, хоть картинки котиков показывать, но обычно мы туда помещаем логику сравнения объектов, потому что это именно то, что ожидает потребитель интерфейса.
Так это же и есть проявления принципа Лисков, к которым мы привыкли и воспринимаем как данность. Ну так и многие "принципы", "паттерны", "законы" лишь формализуют то, что давно известно и применяется. Так вот живешь и не знаешь, что всю жизнь говорил прозой.
При таком подходе даже если вы что-то напишете не так, то быстро и легко сможете это поправить. Есть еще дополнительный бонус от такого подхода. Когда программист что-то долго пишет и где-то в начале уходит не туда, он может идти не туда целую неделю и даже больше. В результате накопленный негативный эффект будет слишком большой. Но если бы он вливал в main очень маленькими кусочками, то вы бы намного раньше увидели, что он пошел не в ту сторону, и поправили это.
Вот тут не могу согласиться. Одно дело, когда разработчик неделю писал в своей ветке что-то не то - да, он потратил время, но ущерб проекту на этом заканчивается. И совсем другое дело, когда он за эту неделю сделал 50 мелких коммитов в trunk (параллельно с десятком-другим разработчиков, делающих свои коммиты) , и их надо творчески отреверсить, ничего не пропустив и не сломав никакого кода, который потенциально с ним связан. Риски, что что-то "отъедет", весьма велики.
Как технику тяжело читать при таком количестве грубых англицизмов. Неужели так трудно соблюдать строгость терминологии и при переводе применять полный нативный термин, как это принято во всей академической литературе.
На эту тему попадался короткий рассказ - довольно забавный, но я не помню ни автора, ни названия. Там в Солнечную систему прибыли представители негуманоидной цивилизации, у которых восприятие времени на несколько порядков более медленное, чем у нас. С их точки зрения, буквально на их глазах, на одной из планет возникла и взрывоподобно развилась разумная жизнь на основе углерода.
закончилось печально
Космический корабль землян обнаружил пришельцев, по-видимому, чрезвычайно древний. Признаков жизни ре обнаружено, всё обитатели представляют собой окаменелости, которые было решено выставить в музее.
И только уборщик недоумевал, почему эти окаменелости периодически оказывались сдвинуты на несколько миллиметров, и раз за разом ставил их на место.
Как-то это плохо стыкуется с утверждениями из статей про внедрение PVS Studio на больших проектах, о том, что можно запустить анализ, пометить всё ошибки как "базовый уровень", и в последующих анализах видеть только новые ошибки. Я думал, это делается в несколько кликов.
А мне персонаж Сутеева представлялся
Собственно, данная статья и работает в пользу приведения ожиданий людей к реальности.
Так это просто для иллюстрации того, сколько раз выполняется сравнение. Когда коллекция большая, а сравнение медленное, могут возникнуть проблемы, там где их не ждёшь. А захват тут не при чем.
Кроме того, это никак р-не противоречит моему доводы о том, что "простая мнемоника никогда не делайте multiple enumeration по enumerable" снимает не все проблемы.
Речь про беглый анализ кода, при котором легко ошибочно заключить что x.Last(predicate) и x.Where(predicate).Last() эквивалентны. И то, что несколько человек на этом попались, опровергает тезис "нельзя".
Увы не полностью. С единственным вызовом Last() можно ожидать, что сравнение будет одно, т.к. обход будет идти с конца, но легко упустить, что после Where мы имеем дело не с массивом (как вы уже написали ниже), и обход будет полным. Так что пусть пример несколько синтетический, но полезная информация в нём определённо есть, чтобы не попадаться на таких ловушках.
Вряд ли его стали бы обогащать, если бы решили использовать в качестве оружия. Просто смирились бы с КПД 1/2 от теоретического (если конечно можно назвать такое "действие" "полезным")
Так ведь есть исследования, что будучи изолированным от внешней среды (например, в пещере), организм имеет тенденцию переходить на удлинённый цикл сна/бодрствования. Там, конечно, много факторов оказывают влияние, но в межзвёздных странствиях нет объективных предпосылок против установления размера цикла в 100 Кс (27:46 на наши деньги). Жаль в СИ не предусмотрено стандартной приставки для 100 000
Проблемы с календарями во многом вызваны стремлением сохранить привязку к природным циклам - т.е. приравнять год к периоду обращения Земли вокруг Солнца, а сутки - к периоду оборота вокруг оси. В, условно, стандартном галактическом времени это не имело бы смысла, там логичнее было бы измерять время кило-, мега-, гигасекундами. Например, в течение одной Мс рабочему предоставляется 300Кс выходных, кроме того ему полагается оплачиваемый отпуск в 1Мс один раз в 20Мс... Операции с датами станут тривиальными, а вот перевод в архаичные земные единицы останется всё таким же заморочным.
(Удивляет, что во всякой космической фантастике продолжают считать время земными единицами; впрочем, я тут не очень начитан)
Поддержу. У нас американский ПМ, когда отключается от созвона, обычно говорит "I'm bailing". Brolly в значении "зонтик" буквально недавно впервые услышал, причём от британцев.
Я когда сыроделием увлекался, столкнулся со сложностями перевода. В русском языке на разных стадиях вы имеет дело со сгустком, сырным зерном, сырной массой, сырным тестом. А в английском это всё называется curd. И творог тоже curd (либо cottage cheese). И омонимичность слов "плесень" и "форма" (то и другое mold) тоже иногда мешает, впрочем, не слишком сильно, обычно из контекста понятно.
Мне кажется, дело тут не столько в том, насколько "умён" DI-фреймворк, а в том, что в разных ситуациях разработчику может требоваться разное поведение - иногда ему принципиально важно получить один и тот же экземпляр, внедряя зависимость по любому из его интерфейсов, а в других случаях - принципиально важно, чтобы создавался новый экземпляр. DI от Microsoft предоставляет возможность это сделать, а значит свою задачу решает (пусть и не самым интуитивным образом). Тем более что в подавляющем большинстве случаев это вообще не имеет значение, т.к. класс регистрируется по одному интерфейсу.
Да и я бы не сказал, что принцип дурацкий; при написании кода мы практически всегда стараемся в той или иной мере ему следовать, пуусть и неосознанно. Например (в C#), переопределяя метод ToString, обычно никто не будет выбрасывать исключений, а спроси почему это плохая идея - ответят, что вызывающий код может не знать, что объект такого типа требует особого обращения, и вызвать ToString, и неожиданно упасть. Или, к примеру, реализуя метод Equals, технически мы можем делать всё что угодно, хоть картинки котиков показывать, но обычно мы туда помещаем логику сравнения объектов, потому что это именно то, что ожидает потребитель интерфейса.
Так это же и есть проявления принципа Лисков, к которым мы привыкли и воспринимаем как данность. Ну так и многие "принципы", "паттерны", "законы" лишь формализуют то, что давно известно и применяется. Так вот живешь и не знаешь, что всю жизнь говорил прозой.
Вот тут не могу согласиться. Одно дело, когда разработчик неделю писал в своей ветке что-то не то - да, он потратил время, но ущерб проекту на этом заканчивается. И совсем другое дело, когда он за эту неделю сделал 50 мелких коммитов в trunk (параллельно с десятком-другим разработчиков, делающих свои коммиты) , и их надо творчески отреверсить, ничего не пропустив и не сломав никакого кода, который потенциально с ним связан. Риски, что что-то "отъедет", весьма велики.
Какая ирония
Точно! Спасибо большое! Поставлю прямую ссылку https://lleo.me/arhive/fan2004/na_mesto.shtml
На эту тему попадался короткий рассказ - довольно забавный, но я не помню ни автора, ни названия. Там в Солнечную систему прибыли представители негуманоидной цивилизации, у которых восприятие времени на несколько порядков более медленное, чем у нас. С их точки зрения, буквально на их глазах, на одной из планет возникла и взрывоподобно развилась разумная жизнь на основе углерода.
закончилось печально
Космический корабль землян обнаружил пришельцев, по-видимому, чрезвычайно древний. Признаков жизни ре обнаружено, всё обитатели представляют собой окаменелости, которые было решено выставить в музее.
И только уборщик недоумевал, почему эти окаменелости периодически оказывались сдвинуты на несколько миллиметров, и раз за разом ставил их на место.
Прочитал статью и пролистывал комментарии, недоумевая, почему никто не указал на очевидную абсурдность бенчмарка.
Вы все неправильно поняли!
Вот так правильно
Монитор захлопнул и домой.