Интеркал — самый худший язык программирования из существующих.

Тихо, сам с собою я веду беседу... Вы о чём?

простая скалярная переменная это прежде всего скаляр, простите за тавтологию. А уж потом это скаляр-строка, или скаляр-длинное_целое. В скриптах так вообще все переменные можно считать строками, различие «целого» от «строки» скрыто от программиста. Потому ваше сомнение не очень уместно.

Всё как обычно ИМХО. Я не претендую на истину в последней инстанции, я не Дональд Кнут.

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

ну может быть. Я хотел объяснить, что UB это не баг, а фича.

Международный это когда internacio, а тут межкаловый :)

незнакомому с встроенным языком 1С он может показаться страшным

Тогда голосую за Java (как худший язык). Ибо позволяет такую фигню:

public static void main(String[] args) {
    double π = Math.PI /\u002A
    System.out.println(π);

    /* previous string doesn't work */
    ;
}

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

С такой спекой сразу же видно, что язык намеренно ухудшали.

Неее. Наоборот улучшили. Чтобы в зависимости от наличия оптимизации работа программы не менялась. Причём данный язык будет даже соответствовать стандарту С. Так как UB может быть и 42 и pi. Можно вообще сделать на любое UB сразу Segmentation fault. Тогда хотя бы если работает, то работает всегда. А не «как повезёт».

Интеркал — самый худший язык программирования из существующих

А этот чем лучше? :) — Новый эзотерический язык программирования — SvyniachaMova

Ну, если улучшать, то пусть выражения не компилируются, а тихо определить их в спеке во что-то контринтуитивное - сомнительное «улучшение», больше похоже на плохую шутку.

println закомментирован? Жаву не знаю.

ну может быть. Я хотел объяснить, что UB это не баг, а фича.

Да понятно что хотели как лучше.

println закомментирован

Ага. Жава позовляет писать символы как \u002A. В результате то, что похоже на деление нак самом деле является /*.

тихо определить их в спеке во что-то контринтуитивное - сомнительное «улучшение», больше похоже на плохую шутку.

Когда

int table[4];
bool exists_in_table(int v)
{
  for (int i = 0; i <= 4; i++) {
    if (table[i] == v) return true;
  }
  return false;
}

компилируется в

bool exists_in_table(int v)
{
  return true;
}

Вот это действительно похоже на плохую шутку. И это допустимо для современного стандарта C (и C++)

ну может быть. Я хотел объяснить, что UB это не баг, а фича.

Да понятно что хотели как лучше.

и получилось лучше: оптимизирующий компилятор отработает

x++ + ++other_x;

именно так, как это быстрее всего в этой платформе. Я смотрел код для 80586, так он распараллелен, в первых пнях было одно ядро, но два ALU, т.е. можно было выполнить две команды за один такт. Для 80486 код совсем другой, т.к. ALU там одно.

Если-бы в стандарте было-бы не UB в этом месте, то в каком-то случае(в зависимости от раскрытия UB) код получился-бы не оптимальным.

А вот быдлокодеры пишущие x++ + ++x; должны страдать, и они страдают, т.к. в зависимости от типа CPU результат говнокода разный.

int table[4];

for (int i = 0; i <= 4; i++) {

if (table == v) return true;

дык это же UB, т.к. i==4 в конце цикла. В последнем+1 элементе читается HEX, и оптимизирующий компилятор полагает, что HEX это «сколько угодно», т.е. например v. Ну и оптимизирует.

Твоя беда в том, что ты не понимаешь, что UB == неопределённое ПОВЕДЕНИЕ, а вовсе не «какой-то мусор прочитает». Как видишь, не читает и не пытается читать.

ЗЫЖ по стандарту можно table, без чтения, для упрощения кодирования многих алгоритмов. Но если читаешь == UB. Всё, код накрылся ЖПП.

по стандарту можно table

по стандарту можно table, т.е. прибавить к указателю table число 4. И это допустимо. А вот table это уже UB.

x++ + ++other_x;

Здесь нет UB.

А вот быдлокодеры пишущие x++ + ++x;

...могут получить вместо ожидаемого 2*x+1 ... 2*x+2, например, всегда 0, если это будет удобно компилятору.

Например,

struct timeval tv;
unsigned long junk;
 
gettimeofday(&tv, NULL);
srandom((getpid() << 16) ^ tv.tv_sec ^ tv.tv_usec ^ junk);

struct timeval tv;
unsigned long junk;
 
gettimeofday(&tv, NULL);
getpid();
srandom(0);

Так как результат вычисления с неинициализированной переменной — UB.

Твоя беда в том, что ты не понимаешь, что UB == неопределённое ПОВЕДЕНИЕ

Я понимаю. Но мне не нравится, что в стандарте неопределённое = произвольное. Скажем в ANSI Common Lisp есть implementation defined, но там чётко указан возможный диапазон действий.

А UB в C позволяет делать замечательные вещи типа:

int table[4];
bool exists_in_table(int v)
{
  for (int i = 0; i <= 4; i++) {
    if (table[i] == v) return true;
  }
  return false;
}

int main()
{
   for (int i = 0; i < 255; i++)
      if(exists_in_table(i)) printf("%i in table\n", i);
}

и получить, что все 255 чисел равны тому самому table[4]

Или такой прикол:

#include <stdio.h>
#include <stdlib.h>

int main() {
int *p = (int*)malloc(sizeof(int));
int *q = (int*)realloc(p, sizeof(int));
*p = 1;
*q = 2;
if (p == q)
   printf("%d %dn", *p, *q);
}



$ clang -O realloc.c ; ./a.out 
1 2

два значения по одному адресу. Это нормально?

Здесь нет UB.

о том и речь:

1. корректный код выполняется по разному, но даёт одинаковый результат. Самым быстрым способом.

2. некорректный код выполняется тоже по разному, но и результат разный. Проблема на вашей стороне.

А вот быдлокодеры пишущие x++ + ++x;

могут получить

ВСЁ ЧТО УГОДНО!, блжад.

ракету земля-воздух в сторону кетая например. Зависит только от того, что может делать данный код. Если ракеты запускает, может и ракету запустить.

17bit integers, because we can! Это победа

Но мне не нравится, что в стандарте неопределённое = произвольное.

это не баг, а фича. Перечитай выше, зачем так сделано. В примере типа x-- - --x компилятор не проверяет, что x тут одинаковое. Это позволяет увеличить скорость и упростить оптимизатор. А значит добиться большей глубины оптимизации.

Скажем в ANSI Common Lisp есть implementation defined, но там чётко указан возможный диапазон действий.

ну если стандарт говорит «тут можно оптимизировать», компилятор оптимизирует. Для этого ему надо менять код. Для этого в стандарте должно быть UB, что-бы оптимизатор выбрал верный путь вычисления.

От программиста требуется только одно: что-бы его код при любом порядке(предусмотренном стандартом конечно) выполнялся правильно.

Если ты ограничишь UB, компилятор не сможет выбирать правильные пути.

А UB в C позволяет делать замечательные вещи типа:

это глубокая оптимизация связанная с тем, что компилятор помнит про константность(даже если ты const не вписал), и если он сравнивает два числа, и оба const, он выкидывает проверку. У тебя тут особый случай, одно число HEX. Ради тебя, говнокодера, вставлять в код оптимизатора проверку особого случая?! Нет пути. Просто потому, что таких вот ляпов возможно Over9000, оптимизатор твой код неделями будет проверять.

два значения по одному адресу. Это нормально?

ну компилируй с -O0, оно так делать не будет, и у тебя там будет одно мусорное значение, причём неизвестно какое. Да ещё и медленно.

Вкусная паста. Ну а питон чем тебе плох?

Анальным навязыванием ООП и своим солдафонским синтаксисом.

Perl изящен и гибок, а Python - это какой-то старшина Петров на марше: перекачанный, стреляет хорошо, но до того прямолинейный и тупой...

Вот это действительно похоже на плохую шутку. И это допустимо для современного стандарта C (и C++)

Это плохая шутка, согласен, но если бы в стандарте было специфицировано такое поведение для всех компиляторов, было бы еще хуже. Текущее UB хотя бы позволяет некоторым компиляторам выдать что-то более вменяемое.

В примере типа x-- - --x компилятор не проверяет, что x тут одинаковое.

Если бы было так... Он как раз проверяет. И если может доказать, что есть UB, то заменяет на наиболее удобную ему инструкцию. Например, x-- - --x гарантированно заменится на константу. Но в случае x++ + ++x, не определён не порядок вычислений, а результат. Поэтому компилятор может заменить на x=0 (или вообще на пустую операцию) и будет по стандарту прав. Если бы он не проверял, что x тут одинаковое, то у него не было бы права выкидывать вычисления.

это глубокая оптимизация связанная с тем, что компилятор помнит про константность(даже если ты const не вписал), и если он сравнивает два числа, и оба const, он выкидывает проверку.

Ну-ну. Кто из них const? table, который может меняться между вызовами exists_in_table или v, который передаётся в параметре?

Если-бы в стандарте было-бы не UB в этом месте, то в каком-то случае(в зависимости от раскрытия UB) код получился-бы не оптимальным.

Какая разница: быстро UB отработает, медленно. Результат все равно не определен.

А вот быдлокодеры пишущие x++ + ++x; должны страдать, и они страдают, т.к. в зависимости от типа CPU результат говнокода разный.

Пока что страдают все.

С третьей страницы тут должен быть плюсо-борще-срач

17bit integers, because we can! Это победа

Уже есть в C.

Текущее UB хотя бы позволяет некоторым компиляторам выдать что-то более вменяемое.

Тогда зачем вообще нужен стандарт? Отсутствие стандарта тем более позволяет некоторым компиляторам выдать что-то более менее вменяемое.

А сейчас, выход за границы массива даже Valgrind'ом не отловить. Потому как компилятор имеет право трактовать a, где i за границами массива как a[0], например. Или вообще как угодно.

И отладка становится адовой: в том же примере с realloc. Указатели совпадают, а их разыменование нет. Из-за особенностей оптимизации и отладки данное поведение никогда не будет проявляться в отладочной версии, но всегда в рабочей. Причём на многие виды UB даже -Wall не реагирует.

старшина Петров

стреляет хорошо

в основном, сигареты

ракету земля-воздух в сторону кетая например.

Вот это и плохо. Когда выход за границы массива, если компилятор сможет его доказать, может повлечь запуск ракеты.

Давай всё остальное также проектировать. Например, в автомобильном стандарте не указано, что должен делать стояночный тормоз во время движения. Предлагаю его заминировать: «быдлокодеры, пишущие x++ + ++x; использующие стояночный тормоз на ходу, должны страдать» (с) emulek

Нет. Самый худший ЯП с точки зрения читабельности - piet, тут даже спорить нечего.

piet, тут даже спорить нечего.

А как же whitespace?

Да, тоже тот ещё подарок. Но он хоть в текстовом редакторе открывается.

Глянул, не впечатлило. Сомневаюсь, что что-то может быть хуже С++.

Например, x-- - --x гарантированно заменится на константу. Но в случае x++ + ++x, не определён не порядок вычислений, а результат.

не понял твою логику.

Если бы он не проверял

я смотрел ассемблерный выхлоп: компилятор выдаёт такой же код, как будто компилирует x++ + ++other_x; Получается естественно бред.

Ну-ну. Кто из них const? table, который может меняться

а вот ты возьми, и измени на argc (argc это в любом случае неизвестная во время компиляции, её компилятор не заоптимизирует). В твоём коде НЕ меняется.

И да, почему компилятор функцию не выкинул целиком? GCC выкидывает такое. Сдаётся мне, ты что-то скрываешь ☺

или v, который передаётся в параметре?

может и v, если функция inline И v константное и известное во время компиляции.

Какая разница: быстро UB отработает, медленно. Результат все равно не определен.

имеется ввиду, что для выражения x-- - --x; ты в стандарте зафиксируешь какой-то один из трёх возможных вариантов. Т.е. вынудишь компилятор к примеру сначала делать декременты(слева-направо, и никак иначе), потом вычитание. Тогда выражение x-- - --y будет выполнятся не оптимально в 66% платформ, т.к. вариантов тут три, и вероятность правильного выбора ⅓. Сейчас компилятор выбирает правильный путь в 100% случаев, а если получается UB, то выдаёт warning(обычно, да, UB оно такое, по стандарту не обязан).

Пока что страдают все.

я не страдаю. В сомнительных случаях я пишу что-то вроде:

int tmp = x--;
res = tmp - --x;

А сейчас, выход за границы массива даже Valgrind'ом не отловить.

возьми std::vector + at() или сам напиши проверку к сишному массиву.

И отладка становится адовой: в том же примере с realloc

кто же тебе гарантировал, что realloc(3) вернёт другой указатель? Возвращать тот же быстрее на порядок. Тут уж либо трусы, либо крестик.

Причём на многие виды UB даже -Wall не реагирует.

ну что ты хотел? Realloc она вообще слева, в glibc.

Предлагаю его заминировать: «быдлокодеры, использующие стояночный тормоз на ходу, должны страдать» (с) emulek

я сам не водятил, но вот нагуглил такое на каком-то автофоруме:

если ручник сильно держит- то или тросик порвется или в канаву улетишь. если не сильно держит- то плавно остановишься.

а если на повороте дернешь- то получится управляемый занос, плавно переходящий в полет в овраг

На велосипеде тоже всё зависит от кучи причин, если на ходу по тискам. Одно скажу точно: это не просто UB, а UB в реанимации. А может и сразу на южное. Тормозить на ходу надо вообще ОЧЕНЬ аккуратно, а ручник такого не умеет, он не для этого нужен.

Т.ч. ты лучше с UB в машине не экспериментируй, ограничься C/C++…

Сомневаюсь, что что-то может быть хуже С++.

Что касается C++, то всё зависит от кодера. Необходим не один год практики, что-бы писать на C++ нормальный код, а не говно.

Но в случае x++ + ++x, не определён не порядок вычислений, а результат.

не понял твою логику.

int foo()
{
  x = 7;
  return x++ + ++x;
}

Я согласен, когда данный код возвращает 15 (сначала x++) или 16 (сначала ++x). Но так как это формально UB, то компилятор соответствующий стандарту имеет право вернуть 0. Или 42. А это уже очень внезапно.

я смотрел ассемблерный выхлоп: компилятор выдаёт такой же код, как будто компилирует x++ + ++other_x;

Зависит от компилятора и опций оптимизации. Имеет право выкидывать вычисления.

Сдаётся мне, ты что-то скрываешь

Ну да. Здесь выкинет вызов функции. Но семантика останется: table[4] = i, для всех i.

И v константное и известное во время компиляции.

В данном случае v берётся из цикла for (int i = 0; i < 255; i++) — или это для тебя тоже «константа»?

возьми std::vector + at() или сам напиши проверку к сишному массиву.

То есть «массивам в C/C++ не пользуйтесь». Логично.

кто же тебе гарантировал, что realloc(3) вернёт другой указатель?

Ты код смотрел? realloc вернул тот же указатель. Там же проверка на равенство выполняется:

if (p == q)
   printf("%d %dn", *p, *q);
}

Но по одному и тому же адресу оказываются разные значения (на выводе «1 2»). Так как в стандарте написано про UB в данной ситуации, то компилятор выкидывает (оптимизирует) адресную арифметику и реализует только вариант p != q при использовании *p и *q.

а если на повороте дернешь- то получится управляемый занос, плавно переходящий в полет в овраг

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

Необходим не один год практики, что-бы писать на C++ нормальный код

Причём практика нужна не для того, чтобы узнать что делать, а чтобы узнать, чего не делать: Не используйте указатели. Не используйте массивы. Не используйте case без break. Не используйте int. Ловите все исключения в конструкторе, даже если их не обрабатываете...

Проще сделать новый язык (rust?) в котором нет этих ненужных вещей (если их всё равно нельзя использовать).

Я согласен, когда данный код возвращает 15 (сначала x++) или 16 (сначала ++x). Но так как это формально UB, то компилятор соответствующий стандарту имеет право вернуть 0. Или 42. А это уже очень внезапно.

привыкай, это сишка. Для меня это тоже было неожиданно.

И дело даже не в том, что «компилятор вернёт 0» В ЭТОМ месте, это ладно. Интересно, когда нормальный код перестаёт работать В ДРУГОМ месте, совершенно не связанном с UB. ИЧСХ, само UB ведёт себя так, как мне хотелось.

Впрочем, оно вполне ожидаемо, если подумать. Оптимизация много чего затрагивает, и кагбэ не удивительно, что UB влияет на совершенно не связанные(казалось-бы) части.

x++ + ++other_x;

Зависит от компилятора и опций оптимизации. Имеет право выкидывать вычисления.

я в курсе, но не про то. Тут три операции, и он пытается выполнить две сразу на пентиуме. Причём не важно, одна тут переменная, или две. Если одна(UB), то код ессно терпит fail.

Ну да. Здесь выкинет вызов функции. Но семантика останется: table[4] = i, для всех i.

увы, открою тайну: оптимизатор смотрит намного дальше. И у тебя тут не «для всех», а «хотя-бы для одного».

Очевидно, корректность кода на UB проверяется задолго до оптимизатора, а оптимизатор работает так, как будто-бы никаких UB не бывает и быть не может. Что, впрочем, и следовало-бы ожидать.

В данном случае v берётся из цикла for (int i = 0; i < 255; i++) — или это для тебя тоже «константа»?

а потом передаётся в функцию? Тогда наверное нет. Но точнее можно сказать лишь изучив листинг дизассемблера. Меня уже компилятор ничем не удивит, там Over9000 видов оптимизаций, из которых я знаю только 1%. И да, циклы gcc умеет раскатывать, и очень неплохо, если в твоём цикле от i ничего не зависит, то и цикла не будет, если зависит чёт/нечёт, то будет два прохода: для 0 и для 1. Но не удивлюсь, что и цикл от 17 до 29, с шагом 11.

Тут три операции, и он пытается выполнить две сразу на пентиуме. Причём не важно, одна тут переменная, или две. Если одна(UB), то код ессно терпит fail.

Если бы дело было только в параллельности, то они просто выполнились бы последовательно (в том порядке, в котором сформированы ассемблерные команды). Это не такой уж fail. Не буду больше повторяться.

И у тебя тут не «для всех», а «хотя-бы для одного».

Для всех. Он не одну строчку выведет «есть в таблице», а все 256.

оптимизатор работает так, как будто-бы никаких UB не бывает и быть не может

Вот эта строчка в стандарте мне и не нравится.

а потом передаётся в функцию? Тогда наверное нет.

Я же тебе написал код:

int table[4];
bool exists_in_table(int v)
{
  for (int i = 0; i <= 4; i++) {
    if (table[i] == v) return true;
  }
  return false;
}

int main()
{
   for (int i = 0; i < 255; i++)
      if(exists_in_table(i)) printf("%i in table\n", i);
}

Но точнее можно сказать лишь изучив листинг дизассемблера. Меня уже компилятор ничем не удивит, там Over9000 видов оптимизаций, из которых я знаю только 1%.

А листинг полностью совпадает с листингом программы

int main()
{
   for (int i = 0; i < 255; i++)
      printf("%i in table\n", i);
}

там Over9000 видов оптимизаций, из которых я знаю только 1%

Вот ещё замечательная оптимизация:

enum {N=32};
int a[N], pfx[N];
void prefix_sum()
{
  int i, accum;
  for (i=0, accum=a[0]; i < N; i++, accum+=a[i])
    pfx[i] = accum;
}

gcc-4.8 здесь выкидывает проверку i < N. Можешь попробовать угадать, почему.

То есть «массивам в C/C++ не пользуйтесь». Логично.

в 99% случаев можно строго доказать, что выхода за границу НИКОГДА не будет. В 80% это очевидно. Для 1% можно assert поставить на всякий.

Ну и да, массивы C/C++ это часто преждевременная оптимизация, что есть зло.

Так как в стандарте написано про UB в данной ситуации, то компилятор выкидывает (оптимизирует) адресную арифметику и реализует только вариант p != q при использовании *p и *q.

это ИМХО баг. Gcc даёт 2 2. Какую «арифметику» тут можно выкинуть?

Впрочем, может твой realloc это какой-то кривой макрос, который заставляет думать компилятор, что всегда p!=q ?

Тут три операции, и он пытается выполнить две сразу на пентиуме. Причём не важно, одна тут переменная, или две. Если одна(UB), то код ессно терпит fail.

Если бы дело было только в параллельности, то они просто выполнились бы последовательно (в том порядке, в котором сформированы ассемблерные команды). Это не такой уж fail. Не буду больше повторяться.

ещё раз: последовательно код выполнялся-бы на 80486, причём выполнялся-бы с тем же результатом(всегда) как на пентиуме, но медленнее аналога специально для 80486, и даже медленнее, чем вообще без оптимизаций.

А я говорю о том, что _результат_ другой получается, компилятор действует так, как будто-бы x-- - --x это два _разных_ x, и они друг на друга никак не влияют. Например, если не брать в расчёт результат этого выражения, а посмотреть само значение x, очевидно, x←x-2, т.к. декрементов 2шт. А получается x←x-1, либо вообще x не меняется..

А листинг

да. нет там вообще никаких намёков на проверку

 80483aa:	31 db                	xor    ebx,ebx
 80483ac:	8d 74 26 00          	lea    esi,[esi+eiz*1+0x0]
 80483b0:	89 5c 24 04          	mov    DWORD PTR [esp+0x4],ebx
 80483b4:	c7 04 24 f0 85 04 08 	mov    DWORD PTR [esp],0x80485f0
 80483bb:	e8 d0 ff ff ff       	call   8048390 <printf@plt>
 80483c0:	43                   	inc    ebx
 80483c1:	81 fb ff 00 00 00    	cmp    ebx,0xff
 80483c7:	75 e7                	jne    80483b0 <main+0x10>

 8048379:	8d b4 26 00 00 00 00 	lea    esi,[esi+eiz*1+0x0] /* i(eax)=0 */
 8048380:	89 14 85 00 98 04 08 	mov    DWORD PTR [eax*4+0x8049800],edx /* pfx[i]=accum(edx) */
 8048387:	40                   	inc    eax /* i++ */
 8048388:	03 14 85 80 98 04 08 	add    edx,DWORD PTR [eax*4+0x8049880] /* accum+=a[i] */
 804838f:	83 f8 20             	cmp    eax,0x20 /* i<N */
 8048392:	75 ec                	jne    8048380 <main+0x10>

gcc (GCC) 4.8.3

ничего не выкидывает

gcc (GCC) 4.8.3

4.8.0 выкидывает https://gcc.gnu.org/bugzilla/show_bug.cgi?format=multiple&id=53265