>[оверквотинг удален]
>> -- это ССЗБ. И виноват в последствиях будет тот, кто допустил
>> UB, а не тот, кто поменял поведение компилятора, если он работает
>> в рамках стандарта.
> Это вы говорите про непосредственного виновника. Непосредственный виновник - это тот, кто
> создал UB. Точно также, как непосредственный виновник ДТП - тот, кто
> первым нарушил ПДД.
> Тем не менее, на дороге, как правило, авария происходит из-за нескольких ошибок
> разных людей. И, как правило, если все выполняют известное правило ДДД,
> аварии не происходит. Поэтому, разумно кроме непосредственного виновника инцидента выделять
> и косвенных виновников.Прошу без автомобильных аналогий, ибо я лишь пешеход (до работы пешком идти 15 минут). Однако насколько я понимаю, следование ПДД всеми участниками движения не гарантирует невозникновение аварийных ситуаций (где уже кто-то будет тупо вынужден в кого-то врезаться и стать в результате нарушителем), в то время как следование стандарту языка гарантирует правильную работу кода (при корректном компиляторе). Поправьте, если не прав, ибо я не знаю ПДД. К тому же, когда ты пишешь код и ты видишь UB, то у тебя есть возможность его исправить, а когда случилось ДТП -- у тебя уже нет возможности его исправить. А если же ты не видишь UB (а оно есть), значит ты, грубо говоря, хреновый программист и виноват сам.
> И, таки, оптимизаторы gcc становятся косвенными виновниками падения
> bind'а.
Даватйе ещё эффект бабочки вспомним. В принципе, можно сказать что виноват вообще Ленин. Если бы не он, тогда какой-нибудь талантливый инженер (уже при Сталинском режиме) мог переехать куда-нибудь в США и в будущем помочь развитию bind-а, что помогло бы избежать именно этой проблемы с UB. Но Ленин, как и разработчики gcc, лишь выполнял свою задачу. Делать его ответственным за баг в bind-е -- это по меньшей мере нелепо.
Разработчики gcc не должны думать о таких вот эффектах. Задача gcc - корректно транслировать код. И он это делает. Не вижу что тут обсуждать. Не вижу никакой вины со стороны разработчиков gcc.
Более того, всем ведь известно, что нельзя использовать критические вещи версии "x.y.0". Если кто-то компилировал bind с помощью gcc 4.9.0, то он ССЗБ. Если же нет, то и проблемы нет. Сейчас о проблеме gcc4.9-vs-bind уже известно и пока не исправили bind нужно его тупо компилить с помощью gcc4.8.
> Ещё простой вопрос - у нас есть debug и release сборки. Какая
> из них должна быть более "хрупкой"? Легче падающей при прочих равных?
Что такое "хрупкая" сборка? Естественно ветка вводимая в production должна работать надёжно. А обычно это release-сборки, а следовательно...
P.S.: Кстати говоря извиняюсь, работаю за ноутом, где не настроен Compose-key, в результате длинный дефис делаю через два минуса и т.п.
