Более того, я несколько раз делал очень серьезные изменения/улучшения в чужие проекты, но их авторы морозились и не приняли изменения.
Тому могли быть самые разные причины.
Например, владельцу проекта сейчас некогда критически осмысливать ваши изменения, а неосмысленные он принимать не хочет, потому что они могут что-то сломать.
Или владелец не хочет «загрязнять» свой проект изменениями от других разработчиков, у которых может не быть права лицензировать эти изменения под нужной лицензией (это вполне реальная проблема — например, SQLite принимает изменения только при соблюдении условий, описанных тут в разделе Contributed Code).
Чтобы уменьшить разочарование от отказа принимать ваши изменения, часто помогает сначала отправить какое-нибудь мелкое исправление, чтобы понять, готов ли владелец принимать изменения. И да, всегда остается шанс, что ваше творчество не примут.
1. Скорее всего, отверстие, оставляемое буром, имеет диаметр немного больший, чем внешний диаметр трубы, иначе трение не позволит протолкнуть такую длинную трубу. Если диаметр отверстия «с запасом», то потом грунт должен осесть. Если работа ведется, например, под дорогой, получается, что насыпь, балласт и покрытие дороги тоже должны осесть. Как с этим борятся?
2. Предположим, на пути бура оказывается большой камень (например, валун диаметром метр или более). Что дальше?
Пробрасывание исключений через код на C — изначально плохая идея. Даже если предположить, что исключение «просто пролетит», очевидно, что код на C никак не сможет на него отреагировать — в результате код на C, который собирался изменить состояние программы после возврата управления из callback-функции, сделать это не сможет, данные программы могут оказаться в рассогласованном состоянии.
Airbus confirms that SQLite is being used in the flight software for the A350 XWB family of aircraft.
Видите, ПО для управления пассажирскими самолетами делают с использованием открытого кода (SQLite в общественном достоянии), видимо, качество достаточно высокое (и это подтверждается разносторонним тестированием).
И даже если у вас есть доказательство того, что ни одна программа управления космическими аппаратами не использует открытый код, из этого лишь следует, что до настоящего момента ни одна такая программа не использовала открытый код.
Этот подход подойдет для системы, у которой атакующий может измерять только время ответа. Если атака идет на систему вроде смарт-карты, у которой атакующий может также измерять энергопотребление, ситуация усложняется — переход от активных вычислений к пассивному ожиданию, возможно, будет сопровождаться заметным изменением энергопотребления, в этом случае осуществима та же атака по времени, но время нужно будет измерять не до момента выдачи ответа, а до момента снижения энергопотребления.
Вот. Мутное определение, холивары и «если принять». Раз в Стандарте не прописано ясно и четко, как вы можете доказать, что volatile lvalue обязывает обращаться с соответствующим объектом как будто тот имеет квалификатор volatile?
Нет, я не говорю, что ваши рассуждения лишены здравого смысла, но пока что-то не прописано в Стандарте, утверждать, что именно так правильно и все реализации должны именно так работать, нельзя.
These collectively are referred to as the observable behavior of the program.
В /8 говорится про необходимость обеспечить выполнение операций доступа к volatile objects (objects — это переменные (1.8/1)), эти операции относятся к наблюдаемому поведению, которое необходимо сохранять, а в /12 говорится, что определенный набор действий относится к побочным эффектам, про их относимость к наблюдаемому поведению и необходимость их сохранить ничего не сказано.
Подскажите, пожалуйста, где именно в Стандарте написано, что при манипуляции с переменной через volatile lvalue компилятор обязан обращаться с ней так, как будто сама переменная объявлена volatile.
Насколько мне известно, такие решения обычно принимают на основании результатов профилирования или других измерений, а не на основании субъективной оценки переживаний.
В данном случае векторизация кода не страшна — для блоков одного размера векторизованный код будет всё равно работать одинаково долго.
Зависит от реализации. Даже если magic — переменная редукции, ничто не помешает добавить проверку результатов вычисления на части массива magic_for_array_part == UCHAR_MAX и быстрый возврат результата, потому что такая проверка на результат не повлияет. Будет ли от этого выгода и сделает ли так конкретный компилятор — вопрос, но техническая возможность есть.
Например, владельцу проекта сейчас некогда критически осмысливать ваши изменения, а неосмысленные он принимать не хочет, потому что они могут что-то сломать.
Или владелец не хочет «загрязнять» свой проект изменениями от других разработчиков, у которых может не быть права лицензировать эти изменения под нужной лицензией (это вполне реальная проблема — например, SQLite принимает изменения только при соблюдении условий, описанных тут в разделе Contributed Code).
Чтобы уменьшить разочарование от отказа принимать ваши изменения, часто помогает сначала отправить какое-нибудь мелкое исправление, чтобы понять, готов ли владелец принимать изменения. И да, всегда остается шанс, что ваше творчество не примут.
1. Скорее всего, отверстие, оставляемое буром, имеет диаметр немного больший, чем внешний диаметр трубы, иначе трение не позволит протолкнуть такую длинную трубу. Если диаметр отверстия «с запасом», то потом грунт должен осесть. Если работа ведется, например, под дорогой, получается, что насыпь, балласт и покрытие дороги тоже должны осесть. Как с этим борятся?
2. Предположим, на пути бура оказывается большой камень (например, валун диаметром метр или более). Что дальше?
Видите, ПО для управления пассажирскими самолетами делают с использованием открытого кода (SQLite в общественном достоянии), видимо, качество достаточно высокое (и это подтверждается разносторонним тестированием).
И даже если у вас есть доказательство того, что ни одна программа управления космическими аппаратами не использует открытый код, из этого лишь следует, что до настоящего момента ни одна такая программа не использовала открытый код.
Нет, я не говорю, что ваши рассуждения лишены здравого смысла, но пока что-то не прописано в Стандарте, утверждать, что именно так правильно и все реализации должны именно так работать, нельзя.
В /8 говорится про необходимость обеспечить выполнение операций доступа к volatile objects (objects — это переменные (1.8/1)), эти операции относятся к наблюдаемому поведению, которое необходимо сохранять, а в /12 говорится, что определенный набор действий относится к побочным эффектам, про их относимость к наблюдаемому поведению и необходимость их сохранить ничего не сказано.