Выбор местности и удаления от города. То, что место надо выбирать не в городе и не поблизости от города – ясно с самого начала. В кризисный период большие и средние города станут зоной жестокого бедствия, и от них надо будет находиться как можно дальше. С другой стороны, переезд куда-то совсем далеко – затрудняется по техническим причинам. Разумным было выбрано расстояние в 60-80 км от Киева. В качестве второй меры пассивной защиты – выбор села не на трассе (что было бы очень удобно с транспортной точки зрения), а в стороне от трассы, как минимум километров 10. Поясню эти меры. По моему мнению, в кризисный период будет два рода движения людей из большого города. Первый – это набеги, когда человек куда-то идет с целью разжиться там продовольствием и вернуться обратно в город, где ждет голодная семья. Преимущественно это будет пешком, какой-то частью – на велосипедах; преимущественно – в одиночку или маленькими группами (2-3 человека), какой-то частью – средней величины вооруженными бандами. Главная особенность – что набег предусматривает путь «туда и обратно» за небольшой период – день-два. Длительный поход за продуктами нецелесообразен потому что за время пути съешь больше чем удастся принести. Исходя из возможностей пешего перемещения, наиболее «горячей» зоной будет 20-30 км от границ города. Окружность в 50 км – будет практическим пределом для «несколькодневных» походов и для велосипедных выездов. Дальше – с набегами придется иметь дело достаточно редко. (Напоминаю, это мои личные расчеты, кто-то может думать иначе, но я рассудил так). Второй род движения людей – это миграция. Когда люди перемещаются с семьей и пожитками. Эти люди могут зайти куда угодно, однако их поведение будет в корне отличаться от первых – будучи сами уязвимыми, они будут куда менее склонны к насилию и агрессии, чем «набежники». Основной поток людей будет перемещаться по трассе, поэтому села на трассе будут подвержены контактам с мигрантами гораздо больше, чем удаленные от трассы. Таким образом, выбор места в 70 км от Киева и 10 км от трассы является действенным и дешевым способом пассивной защиты в кризисных условиях. Что, естественно, не отменяет опасности и других средств защиты от нее.
Район был выбран Переяслав-Хмельницкий, по той причине что он не густонаселен, в нем имеются немалые лесные массивы, он чистый экологически, и, по радиационной карте, это единственный чистый район в Киевской области. Среди нескольких сел, удовлетворяющих условиям, было выбрано село Ковалин. Был найден пустующий дом на краю села, с участком 75 соток, и куплен за смешные деньги – 500 долларов.
чтобы вы зря не думали я сразу указал про chatgpt. и, разумеется, я читал этот ответ, прежде чем запостить. более чем годный ответ на поставленный вопрос. И даже у неискушенного обывателя есть шансы понять суть , в отличие от варианты с "Другой язык получится."
UB (undefined behavior) в C++ появляется, когда стандарт умышленно не задаёт результат некоторой операции/ситуации. Это не “дыра по недосмотру”, а часть дизайна языка, которая даёт компиляторам свободу для оптимизаций и поддержания производительности/портируемости.
Почему UB вообще возникает
1) Железо и ABI реально разные C++ целится работать “близко к железу” на очень разных платформах. Есть вещи, которые на одной архитектуре возможны/дешёвы, а на другой — нет или требуют дорогих проверок. Пример: выравнивание (alignment). На одних CPU невыровненный доступ просто медленнее, на других может быть исключение/крах. Стандарт не хочет навязывать единое “всегда делай медленную безопасную вещь”.
2) Производительность: “не плати за то, чем не пользуешься” Если стандарт определит поведение для всего, это часто означает обязательные проверки или дополнительные ограничения на оптимизации везде, даже там, где программист гарантирует корректность. Классика: выход за границы массива. Чтобы сделать это “определённым”, нужно либо:
проверять границы (как в безопасных языках / контейнерах с проверкой), либо
менять модель памяти так, чтобы чтение “за пределами” возвращало что-то определённое, но тогда ломаются многие низкоуровневые предположения и оптимизации.
3) UB — это инструмент оптимизатора Ключевая причина: компилятор может предполагать, что UB не происходит, и на основании этого упрощать код.
Пример (упрощённо): если компилятор знает, что p указывает на валидный объект типа T, он может переупорядочивать загрузки/выгрузки, убирать проверки на nullptr, кэшировать значения в регистрах и т.д. Если бы “разыменование nullptr” было определено как “ничего не делает” или “возвращает 0”, компилятор обязан был бы сохранять проверки/осторожность намного чаще.
4) Некоторые вещи невозможно/нецелесообразно “нормально определить” в рамках языка Например:
data race в многопоточности: чтобы “определить” результат, нужна очень жёсткая модель памяти или обязательная синхронизация → это резко удорожает параллельный код и ломает смысл “низкого уровня”.
переполнение знаковых целых (int): на распространённых CPU оно “по модулю 2^N”, но стандарт долго оставлял UB, чтобы компилятор мог, например, считать x+1 > x всегда истинным для int (это помогает оптимизациям). (В последних стандартах и компиляторах есть больше опций/практик, но идея такая.)
Почему “полностью не запретить” или не сделать всё определённым
Запретить UB “в стандарте” можно только ценой:
либо обязательных runtime-проверок (заметные накладные расходы, особенно в системном коде),
либо урезания оптимизаций (тоже производительность),
либо ломки обратной совместимости (огромный массив существующего кода и практик),
либо усложнения стандарта/модели исполнения (и всё равно останутся углы).
C++ исторически выбирает:
язык даёт мощь и скорость,
а ответственность за соблюдение “контракта” лежит на программисте (или на дополнительных инструментах).
согласен. а еще огромнейшее число суперкастомных деталей все портит. Потому что с одной стороны - это хорошо, что они есть, но с другой - их количество (одного типа) резко ограничено. В итоге ничего полезного, своего из них сделать не получается, а только то, что они делали в оригинальной модельке
почему никто еще не написал про YAGNI и KISS? просто зашли в ЗАГС перед работой и расписались за 10 минут (предварительно за месяц подали заявление на госуслугах)
я тут еще раз подумал, может реально фильтрация. когда все ливнут, а останутся лишь "идейные", то скажут: "ребята мы пошутили, не забывайте отдыхать, чтобы еще лучше работать". ну и вернутся в обычный ритм 40-50 (ну кто-то может и 60 часов), но 80 это за гранью конечно
ну почему же фильтрация. может быть и жестом доброй воли. чтобы их потом не крыли матом из каждого утюга уволенные сотрудники. а так получается, что их как бы не обидели, какие претензии? то бишь купили себе часть репутации (застраховались от негатива)
отличная статья, спасибо за систематизацию! везде согласен, вы все правильно пишете
разве что тут чуть напрягся. > По статистике увольняю примерно одного из десяти принятых. Обычно это происходит на испытательном сроке. процент из моего личного опыта будет поменьше
выиграют в итоге не те, кто сократил в три раза,
а те кто увеличил производительность в три раза...
нууу. вместо айпада или какого-нибудь хромобука вполне себе сгодится
осмелюсь порекламировать другого автора (метод Кошастого):
https://vicsrg.ho.ua/stat/ogorod.htm
этот товарищ отлично шарит
да я не обижаюсь на реакцию. просто ответил на том же уровне, что и был сам вопрос
чтобы вы зря не думали я сразу указал про chatgpt.
и, разумеется, я читал этот ответ, прежде чем запостить. более чем годный ответ на поставленный вопрос.
И даже у неискушенного обывателя есть шансы понять суть , в отличие от варианты с "Другой язык получится."
отвечает chatgpt
UB (undefined behavior) в C++ появляется, когда стандарт умышленно не задаёт результат некоторой операции/ситуации. Это не “дыра по недосмотру”, а часть дизайна языка, которая даёт компиляторам свободу для оптимизаций и поддержания производительности/портируемости.
Почему UB вообще возникает
1) Железо и ABI реально разные
C++ целится работать “близко к железу” на очень разных платформах. Есть вещи, которые на одной архитектуре возможны/дешёвы, а на другой — нет или требуют дорогих проверок.
Пример: выравнивание (alignment). На одних CPU невыровненный доступ просто медленнее, на других может быть исключение/крах. Стандарт не хочет навязывать единое “всегда делай медленную безопасную вещь”.
2) Производительность: “не плати за то, чем не пользуешься”
Если стандарт определит поведение для всего, это часто означает обязательные проверки или дополнительные ограничения на оптимизации везде, даже там, где программист гарантирует корректность.
Классика: выход за границы массива. Чтобы сделать это “определённым”, нужно либо:
проверять границы (как в безопасных языках / контейнерах с проверкой), либо
менять модель памяти так, чтобы чтение “за пределами” возвращало что-то определённое, но тогда ломаются многие низкоуровневые предположения и оптимизации.
3) UB — это инструмент оптимизатора
Ключевая причина: компилятор может предполагать, что UB не происходит, и на основании этого упрощать код.
Пример (упрощённо): если компилятор знает, что
pуказывает на валидный объект типаT, он может переупорядочивать загрузки/выгрузки, убирать проверки наnullptr, кэшировать значения в регистрах и т.д. Если бы “разыменование nullptr” было определено как “ничего не делает” или “возвращает 0”, компилятор обязан был бы сохранять проверки/осторожность намного чаще.4) Некоторые вещи невозможно/нецелесообразно “нормально определить” в рамках языка
Например:
data race в многопоточности: чтобы “определить” результат, нужна очень жёсткая модель памяти или обязательная синхронизация → это резко удорожает параллельный код и ломает смысл “низкого уровня”.
переполнение знаковых целых (
int): на распространённых CPU оно “по модулю 2^N”, но стандарт долго оставлял UB, чтобы компилятор мог, например, считатьx+1 > xвсегда истинным дляint(это помогает оптимизациям). (В последних стандартах и компиляторах есть больше опций/практик, но идея такая.)Почему “полностью не запретить” или не сделать всё определённым
Запретить UB “в стандарте” можно только ценой:
либо обязательных runtime-проверок (заметные накладные расходы, особенно в системном коде),
либо урезания оптимизаций (тоже производительность),
либо ломки обратной совместимости (огромный массив существующего кода и практик),
либо усложнения стандарта/модели исполнения (и всё равно останутся углы).
C++ исторически выбирает:
язык даёт мощь и скорость,
а ответственность за соблюдение “контракта” лежит на программисте (или на дополнительных инструментах).
я тоже печатаю вслепую на обоих языках, но совладать с телефонной клавиатурой не смогу
юридически быстро приедет пативен и возьмут за жопу. за весь трафик отвечает владелец точки...
второй заголовок не сильно лучше :)
осталось переместить эти кабины внутрь вагонов метро и будет совсем здорово :D
похоже, что в моменте таки обогнал, а потом акции oracle немного отскочили вниз
спасибо за наводку на сайт! ага.
переформулирую свою предъяву: "суперкастомные" - это те, которые "редкие" = встречаются в единичном числе наборов. вот так
да, да. я понимаю, что применения разные могут. скажем пару сотен разных видов деталей я бы пережил, но у лего их тысячи же
согласен. а еще огромнейшее число суперкастомных деталей все портит.
Потому что с одной стороны - это хорошо, что они есть, но с другой - их количество (одного типа) резко ограничено.
В итоге ничего полезного, своего из них сделать не получается, а только то, что они делали в оригинальной модельке
почему никто еще не написал про YAGNI и KISS?
просто зашли в ЗАГС перед работой и расписались за 10 минут (предварительно за месяц подали заявление на госуслугах)
я тут еще раз подумал, может реально фильтрация. когда все ливнут, а останутся лишь "идейные", то скажут:
"ребята мы пошутили, не забывайте отдыхать, чтобы еще лучше работать".
ну и вернутся в обычный ритм 40-50 (ну кто-то может и 60 часов), но 80 это за гранью конечно
ну почему же фильтрация. может быть и жестом доброй воли. чтобы их потом не крыли матом из каждого утюга уволенные сотрудники.
а так получается, что их как бы не обидели, какие претензии?
то бишь купили себе часть репутации (застраховались от негатива)
поддерживаю. абсолютно бесполезный и кликбейтный заголовок
отличная статья, спасибо за систематизацию!
везде согласен, вы все правильно пишете
разве что тут чуть напрягся.
> По статистике увольняю примерно одного из десяти принятых. Обычно это происходит на испытательном сроке.
процент из моего личного опыта будет поменьше
ну слава богу. а то мы уж чуть было не подумали, что во всем виноват AI