Oberon space

Если не компилируются, то дело не статическом анализаторе. Во-первых, gcc использует свой диалект, и в общем случае собранное в gcc гарантированно собирается только gcc. Во-вторых, VS использует диалект Си, который является расширением подмножества стандартного Си.

Твой тезис имел бы смысл, сформулируй ты его иначе: эта ошибка возможна в любом языке, для которого можно написать транслятор из с++, полностью сохранающий семантику исходной программы.

Ну так для хаскелла, выходит, такого транслятора нельзя создать, потому что семантика не сохраняется.
Более того, подозреваю, что разные компиляторы с++ могут по разному компилировать эту программу, по разному понимая семантику этой программы. Где-то будет получаться эта ошибка, где-то не будет...

Вы уверждаете, что транслятор С++, написанный на Хаскелле вместе с программой на С++, всунутой в строку в исходнике на Хаскелле, не является программой, написанной на Хаскелле? Если нет, то что не так? Обратите внимание, что речь не о практической достижимости, а о принципиальной возможности. Конечно, такой принципиальной возможности можно достичь гораздо более простым путём, чем создание транслятора C++, но версия с транслятором веселей и наглядней.

Хе-хе. Вирта задолбало и он вернул тайпдефы?

Судя по описанию - это всего лишь синтаксическое послабление, но семантика осталась прежней.

Цитата: kkkk от Сентябрь 28, 2016, 12:08:50 pm

О таком фокусе я знаю, но в общем случае резерва не требуется, в то время как в Си - он обязателен.

Какие-то странные представления о Си. Конечно же и в Си это не обязательно.

У меня действительно странные представления о Си - основаны на логике и опыте ежедневного использования, к счастью и к сожалению. В Си в невыделенной памяти  ничего работать не будет и это очевидно. Даже если программист перепил чаю и забыл выделить память, после первого же неудачного запуска он это исправит. В С++ с вектором в большинстве случаев можно не волноваться, Tefal думает за вас. Но иногда это выливается в непонимание, как работает программа и приходится тратить немало времени, чтобы выяснить причину проблемы. Речь об этом.
 

Выделить сразу памяти столько сколько будет необходимо в общем случае либо невозможно, либо слишком ресурсоёмко для подобных классов задачек как минимум.

В общем случае - нет, а в частном зачастую есть асимптотические формулы, позволяющие найти достаточно хорошее приближение сверху, и именно такое выделение будет самым эффективным по скорости. И памяти нужно в 1.5-2 раза меньше, чем с саморасширяющимся вектором(при удачных для вектора раскладах - одинаковое). К тому же, не надо во время вычисления обрабатывать отказ от выделения очередной порции памяти - хватит или нет ясно в самом начале.

На тему явного и очевидного, то в Си в реальном коде, это смотрелось бы примерно так, на самом деле.

Код: [Выделить]

g_array_index(ts, bor, v).mp[x] = go();
...
int go() {
        bor b;
        init(&b);
        g_array_append_val(ts, b);
        return ts->len-1;
}
И ровно с той же семантикой.

Даже при повторении семантики один в один, проблема в Си видна гораздо лучше, потому что в нём нет возможности для самописных структур и функций мимикрировать под массивы, а потому вводить в заблуждение.

Никто по сто раз писать один и тот же велосипед для банального динамического массива/вектора не будет ни в одном из языков. Все либо пишут свои либы, либо используют уже написанные.

А я реализовал нечто подобное, только коллеги это отвергли.

Ну, то есть по сути ты говоришь, что это не С++ плохой как язык и им не надо пользоваться, а это использование готовых либ плохо и ими не следует пользоваться в любом языке, следует максимально на каждый чих писать велосипед.

Нет, я этого не говорю, да и что такое плохой язык, я тоже плохо понимаю.

Причем сколько мест использования подобного кода, столько велосипедов в проекте и должно быть. Так сказать, по велосипеду отдельному на каждое место использования :-)

А это зависит от задачи, решаемой библиотекой или велосипедом. Для банального кода лучше велосипед по месту без запрета на переиспользование неподалёку. Нередко оказывается экономичней помнить базовые принципы и уметь их быстро воплощать, чем помнить и разбираться в нюансах редкоиспользуемой библиотеки с постоянным сверением с документацией.  Для нетривиального кода, например, компрессора данных - однозначно нужно использовать готовое решение, если оно достаточно хорошо для твоей задачи.
Есть ещё вопрос лицензий. Я, как пролетарий, сталкиваюсь с тем, что часто не могу использовать свой старый код. Чтобы переиспользовать нужно получить непростое разрешение на выкладывание в Open Source. Дело благородное, но также сопряжено с дополнительными затратами на оформление кода, соответствующее уровню компании, как в ней это видят. И вот для такой банальщины, как вектор,  проще всего оказывается наколбасить по месту либо использовать ещё более простое решение, и часто это работает.

Не понимаю, как это могло привести к падению программы?

1. сначала была выполнена  tr[v].mp[x] , которая ссылалась на массив, использованный в vector в текущем состоянии.
2. затем go() добавила новый элемент в tr, что потребовало выделения нового массива и освобожения старого
3.  наконец было выполнено присваивание tr[v].mp[x] = go() , которое произвело запись в освобождённую память

tr[v].mp[x] = go();
Очевидная проблема в этом месте, так как go() изменяет tr.
Если изменить на
int tmp = go();
tr[v].mp[x] = tmp;
То всё нормально. Да, проблема в плохом понимании работы универсальных решений. И в наличии состояния, конечно 

Где версия для Оберона?