Нет, это именно часть календаря. Этот способ принят в двух календарях, юлианском и грегорианском. Возможно, что были еще другие солнечные календари, в которых были подобные поправки, но я ничего о них не знаю. В лунных и лунно-солнечных месяца (и года) определяются по другому, так что там свои заморочки с отсчетом. В еврейском календаре, например, високосный год отличается не на день, а на месяц.
Возвращаяь к високосным годам, юлианский календарь, по сути, от грегорианского отличается только правилами компенсации. В юлианском високосным считается каждый 4-й год, что дает среднюю продолжительность года в 365,25 дней. В грегорианском же средняя продолжительность 365,2425, что дает меньшую ошибку, особенно на продолжении многих веков.
Високосные года — особенность отдельных календарей. Т.е. нам нужны модули дат для каждого календаря, учитывающие особенности их построения? И даты нужно будет приводить друг к другу?
Может лучше иметь базовый тип времени, который не зависит от календаря? А календарно-зависимые операции переложить на модули соответствующих календарей?
За исключением того, что исходя из самого популярного календаря, каждый год, чей номер делится на четыре, на день длиннее. За исключением тех, которые делятся на сотню. Они нормальные. Кроме случая когда они делятся на 400. Тогда они не нормальные.
Об этом кто должен знать? Модуль с датами? Или с календарем?
А если эта фича будет добавлена в какой-нибудь популярный хедер, то ВСЕ его использующие получат пенальти на скорость компиляции, даже если им фича не нужна
А модули не помогут? Или с высокой вероятностью их примут и реализуют уже после этой фичи?
Обеспечивая бурный рост Dodo IS, мы нередко предпочитали скорость разработки всему остальному. Иногда это происходило в ущерб системной логике, архитектуре и инфраструктуре.
Типичная ситуация, разработчики как раз тут чаще всего не особо виноваты, хотя часто оказываются "крайними". Скорее тут похвально то, что не стали наказывать за косяки, допущенные из-за построения процесса разработки.
При хранении мороженная рыба теряет в массе. Это зовется "естественная убыль". Та самая "утечка, усушка, утряска". Соответсвенно за счет этого масса уменьшиться значительно сильнее, чем ошибка округления.
А вот отрицательная естественная убыль — это хороший повод поинтересоваться, что на самом деле они там под видом рыбы продают.
С PC плохо выйдет — слишком много разных конфигураций. С консолями еще как-то возможно, но тоже не очень.
Можно, конечно, ограничить графику ровно тем, что одинаково поддерживается везде. Но даже в этом случае полного совпадения может и не быть. Из-за багов, разного понимания спецификаций, просто немного разных алгоритмов разные устройства с разными драйверами могут выдавать похожую, но немного отличающуюся картинку.
Для борьбы с этим можно применять простой способ — подтверждение требует ввода слова, а само слово указано в тексте сообщения. Причем для разных серверов слово может быть разным. Что может спасти в ситуации "перепутал сервер".
Так вроде бы разница между чайником и админом еще и в том, что последний сначала читает, что написано, а потом делает, а не наоборот. И не надо допускать чайников к администрированию важных серверов
На счет единой системы взаимодействия задумываются уже. Более вероятна ситуация "модели для разных стран/регионов не могут использоваться в других странах/регионах". Регуляторы, скажем, в России примут один стандарт, в Европе же будет другой, а в Штатах третий. Возможно, в автопилот будут зашиты все возможные варианты, но тут уже нужно полагаться на добросовестность производителей. А им разделение на регионы выгодно.
Основная проблема в том, что типичные создатели античитов большие поклонники "security through obscurity". Пользователь должен установить бинарный блоб, который требует повышенных прав в системе. Что там внутри никто не знает. Это вызывает закономерное недоверие со стороны всех остальных. Параноиком можно и не быть, но ожидать, что там не будет багов, позволяющих выполнить произвольных код, несколько сложно.
Давайте представим себе айфон, но без телефона… Что-то это мне напоминает. Ах да, это же айпод тач. И что-то статистика продаж не подтверждает ваши слова. Айфоны стабильно популярны, а айпод стал диковинкой. Продажи падали последние годы.
Вы, надеюсь, понимаете, что есть язык, а есть некое подмножество, которое можно использовать для официальных документов? И что это подмножество создано искусственно, в отличии от языка?
Законами страны еще можно попытаться контроллировать язык в пределах этой страны (и это сомнительная с точки зрения этичности практика), но остальным от этого ни холодно, ни жарко.
Я не против названия "Беларусь", звучит куда лучше "Белоруссии". Но это мои предпочтения. Язык же разивается коллективно, усилиями его носителей. Не посредством законотворчества (хотя многим бы хотелось). И даже не усилиями составителей правил языка (хотя еще более многим хотелось).
В общем, чем пытаться носителям языка указать на законы, лучше применять другие способы популяризации названия. В конечном счете, мат сколько пытаются запретить, а вот @#$ бы там.
А если Бундестаг примет закон о том, что все жители Земли должны каждый год выплачивать процент с дохода в казну Германии, то что? Все будут оплачивать?
А очевидный факт должен показать, что из примера "поиск строки в массиве строк" совсем не следует оправданность применения хэш-таблиц.
Ситуации могут быть разные.
Если нам требуется выполнить одноразовый поиск в массиве, то очень запросто может оказаться, что проход по массиву со сравнением будет куда быстрее, чем создание хэш-таблицы (или хэш-множества) из-за высокой трудоемкости первоначального создания хэш-таблицы.
Есть ситуации, когда хэш-таблицы эффективнее. И их использование следует из логики выполнения, не из удобства для реализации. Если разработчик не увидел этого, это говорит о разработчике, не о языке.
Нет, это именно часть календаря. Этот способ принят в двух календарях, юлианском и грегорианском. Возможно, что были еще другие солнечные календари, в которых были подобные поправки, но я ничего о них не знаю. В лунных и лунно-солнечных месяца (и года) определяются по другому, так что там свои заморочки с отсчетом. В еврейском календаре, например, високосный год отличается не на день, а на месяц.
Возвращаяь к високосным годам, юлианский календарь, по сути, от грегорианского отличается только правилами компенсации. В юлианском високосным считается каждый 4-й год, что дает среднюю продолжительность года в 365,25 дней. В грегорианском же средняя продолжительность 365,2425, что дает меньшую ошибку, особенно на продолжении многих веков.
Високосные года — особенность отдельных календарей. Т.е. нам нужны модули дат для каждого календаря, учитывающие особенности их построения? И даты нужно будет приводить друг к другу?
Может лучше иметь базовый тип времени, который не зависит от календаря? А календарно-зависимые операции переложить на модули соответствующих календарей?
За исключением того, что исходя из самого популярного календаря, каждый год, чей номер делится на четыре, на день длиннее. За исключением тех, которые делятся на сотню. Они нормальные. Кроме случая когда они делятся на 400. Тогда они не нормальные.
Об этом кто должен знать? Модуль с датами? Или с календарем?
А модули не помогут? Или с высокой вероятностью их примут и реализуют уже после этой фичи?
Типичная ситуация, разработчики как раз тут чаще всего не особо виноваты, хотя часто оказываются "крайними". Скорее тут похвально то, что не стали наказывать за косяки, допущенные из-за построения процесса разработки.
ICountedEnumerable уже есть, только называется IReadOnlyCollection
При хранении мороженная рыба теряет в массе. Это зовется "естественная убыль". Та самая "утечка, усушка, утряска". Соответсвенно за счет этого масса уменьшиться значительно сильнее, чем ошибка округления.
А вот отрицательная естественная убыль — это хороший повод поинтересоваться, что на самом деле они там под видом рыбы продают.
С PC плохо выйдет — слишком много разных конфигураций. С консолями еще как-то возможно, но тоже не очень.
Можно, конечно, ограничить графику ровно тем, что одинаково поддерживается везде. Но даже в этом случае полного совпадения может и не быть. Из-за багов, разного понимания спецификаций, просто немного разных алгоритмов разные устройства с разными драйверами могут выдавать похожую, но немного отличающуюся картинку.
Для борьбы с этим можно применять простой способ — подтверждение требует ввода слова, а само слово указано в тексте сообщения. Причем для разных серверов слово может быть разным. Что может спасти в ситуации "перепутал сервер".
Конечно же. В хабах же jQuery, а не Javascript. Для настоящих jQuery-программистов.
Так вроде бы разница между чайником и админом еще и в том, что последний сначала читает, что написано, а потом делает, а не наоборот. И не надо допускать чайников к администрированию важных серверов
Есть еще decimal, для которого подобное округление нужно. Видимо для общности интерфейса решили сделать одинаковые методы.
На счет единой системы взаимодействия задумываются уже. Более вероятна ситуация "модели для разных стран/регионов не могут использоваться в других странах/регионах". Регуляторы, скажем, в России примут один стандарт, в Европе же будет другой, а в Штатах третий. Возможно, в автопилот будут зашиты все возможные варианты, но тут уже нужно полагаться на добросовестность производителей. А им разделение на регионы выгодно.
Основная проблема в том, что типичные создатели античитов большие поклонники "security through obscurity". Пользователь должен установить бинарный блоб, который требует повышенных прав в системе. Что там внутри никто не знает. Это вызывает закономерное недоверие со стороны всех остальных. Параноиком можно и не быть, но ожидать, что там не будет багов, позволяющих выполнить произвольных код, несколько сложно.
Нет, пока не выяснилось, что появление айфона убило рынок айподов.
Давайте представим себе айфон, но без телефона… Что-то это мне напоминает. Ах да, это же айпод тач. И что-то статистика продаж не подтверждает ваши слова. Айфоны стабильно популярны, а айпод стал диковинкой. Продажи падали последние годы.
Таким образом, невозможно аутсорсить, по сути, только топ-менеджмент и пару слоев пониже?
Вы, надеюсь, понимаете, что есть язык, а есть некое подмножество, которое можно использовать для официальных документов? И что это подмножество создано искусственно, в отличии от языка?
Законами страны еще можно попытаться контроллировать язык в пределах этой страны (и это сомнительная с точки зрения этичности практика), но остальным от этого ни холодно, ни жарко.
Я не против названия "Беларусь", звучит куда лучше "Белоруссии". Но это мои предпочтения. Язык же разивается коллективно, усилиями его носителей. Не посредством законотворчества (хотя многим бы хотелось). И даже не усилиями составителей правил языка (хотя еще более многим хотелось).
В общем, чем пытаться носителям языка указать на законы, лучше применять другие способы популяризации названия. В конечном счете, мат сколько пытаются запретить, а вот @#$ бы там.
А если Бундестаг примет закон о том, что все жители Земли должны каждый год выплачивать процент с дохода в казну Германии, то что? Все будут оплачивать?
А очевидный факт должен показать, что из примера "поиск строки в массиве строк" совсем не следует оправданность применения хэш-таблиц.
Ситуации могут быть разные.
Если нам требуется выполнить одноразовый поиск в массиве, то очень запросто может оказаться, что проход по массиву со сравнением будет куда быстрее, чем создание хэш-таблицы (или хэш-множества) из-за высокой трудоемкости первоначального создания хэш-таблицы.
Есть ситуации, когда хэш-таблицы эффективнее. И их использование следует из логики выполнения, не из удобства для реализации. Если разработчик не увидел этого, это говорит о разработчике, не о языке.