KISS языки

>что же еще нужно?

Научиться писать название языка без ошибок?

Scheme,
можешь посмотреть Tcl, интересный язык.

scheme

у меня сложилось впечатление, что чтобы нормально писать на С, требуется быть параноиком и исходить из того, что НИЧЕГО ДЕЛАТЬ НЕЛЬЗЯ, кроме того, что в явном виде разрешено стандартом; интуиция «это сделано так, потому, что на низком уровне так» требует *больших* знаний и тренировки

как кот ученый ходишь по цепи, шаг влево-вправо — расстрел

а вот определено ли в семантике SML переполнение целого?

> а вот определено ли в семантике SML переполнение целого?

Бросают Overflow, AFAIK.

smlnj бросает исключение, например.

удобно писать быстро работающий и при этом надежно работающий код можно только на языке, имеющем

1. прямой доступ к байтам

2. мощную систему типов (читай: запретов)

3. мощную обвеску из мат. логики

попытки сделать это в стиле С обречены на провал

> Бросают Overflow, AFAIK.

ок, тогда следующий вопрос:

можно ли там доказать компилятору, что в данном классе случаев (или хотя бы в данном случае) переполнения не будет?

именно доказать, а не голословно заявить «мамой клянусь»

> можно ли там доказать компилятору, что в данном классе случаев (или хотя бы в данном случае) переполнения не будет?

Не знаю, хотя думаю, что нет. Но я честно сказал - на SML не программировал.

наверно язык с (неотключаемыми) исключениями при переполнении лучше языка без оных

но как минимум еще нужен целый тип «по модулю 2**32», где исключения не проверяются (и его знаковые вариации, и по модулю 2**8, 2**16, 2**64)

дешево и сердито

Manhunt, расскажи что за переполнение было

мой либастрал подсказывает, что *если бы не оптимизатор*, то все было бы хорошо

типа того, что оптимизатор выбросил условие в for(int i=1; i*=3; i<32000)

я хотел сказать for(int16 i=1; i*=3; 0<i && i<32000)

> расскажи что за переполнение было

У меня переполнения не было :) Просто читаю время ото времени багзиллу gcc, и охреневаю. Типа такого: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736

> Типа такого: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736

хех, либастрал не соврал — герои драмы «переполнение и оптимизатор»

int until = 40001;

for(short from = 0; from < until; from++) printf («%d\n», from);

ИМХО эта идиотская манера стандарта сувать везде undefined behaviour; я бы предложил в стандарте закрепить практику

либо 1. писать нормальный оптимизатор, как в жцц, дающий варнинг

либо 2. «не можешь оптимизировать — не суйся!» если у разрабов нет времени на нормальный оптимизатор

подозреваю, что undefined behaviour выходит *только* из-за оптимизатора, т.к. вообще арифметика по модулю 2**М ничего общего с undefined behaviour не имеет

а еще эта идиотское якобы «абстрагирование от конкретной архитектуры» — типа имеется в виду, что переполнение может быть на машине, где представление чисел не в двоичном дополнительном коде, а х.з. как, и в результате получается не арифметика по модулю 2**М

нахрен эти дебильные абстракции — все по модулю 2**М, и точка. как щас в большинстве железа.

> нахрен эти дебильные абстракции — все по модулю 2**М, и точка. как щас в большинстве железа.

На большинстве железа так и будет, чем ты недоволен?

> На большинстве железа так и будет, чем ты недоволен?

На железе - будет, на Си - нет.

> а еще эта идиотское якобы «абстрагирование от конкретной архитектуры»

Либо «идоитское абстрагирование», либо «виртуальная машина» - выбирай.

> На большинстве железа так и будет, чем ты недоволен?

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

Это из той же серии, что с++ якобы абстрагируется от деталей побайтовой реализации производного класса — т.е. по стандарту возможно что

сlass A { int a; };
class B: A { int b; };

реализуется в виде

сlass RealA { int a; };
class RealB2 { int b; };
class RealB { int a; Real B2* __child; };

_____________________________________________

Это НЕ значит, что код может бесконтрольно враппиться через 2**М или лезть в байтовую структуру класса (она, кстати, м.б. сложнее) — а значит, что интерфейсы что к враппу, что к байтовой структуре должны быть определены в языке (в первом случае как минимум 2 типа — с отловом враппа и без оного)

Fortran 77.

> На большинстве железа так и будет, чем ты недоволен?

стандарт разрешает быдлоразботчикам быдлокомпилятора сваять быдлооптимизатор, который не будет учитывать возможность переполнения, и толкнуть свое быдлоподелие как «сооствествующее стандарту ИСО»

в то время как правильно «не можешь — не оптимизируй».

> Либо «идоитское абстрагирование», либо «виртуальная машина» - выбирай.

не понял необходимости выбора

Forth

>> На большинстве железа так и будет, чем ты недоволен?

На железе - будет, на Си - нет.

Пример?

http://www.airs.com/blog/archives/120

для Ъ

int f()
{
    int i;
    int j = 0;
    for(i = 1; i > 0; i += i)
        ++j;
    return j;
}

This code is assuming that if it keeps doubling a positive number, it will eventually get a negative number. That is, it expects signed overflow to behave in a certain way. Current mainline gcc will see that the signed overflow can not occur in a correct program, and will compile this code into an infinite loop.

Ну и как я понял то, что у gcc под это дело есть ключики — это его личная заслуга, а не требование стандарта ИСО.

> Ну и как я понял то, что у gcc под это дело есть ключики — это его личная заслуга, а не требование стандарта ИСО.

И? Отключи оптимизацию - получишь ожидаемое поведение. Оптимизация в Си (а может, и везде) основывается на некоторых предположениях об исходной программе. Подумай о strict-aliasing, например - тут _прогер_ явно говорит «мамой клянус, всё хорошо». Единственное, что gcc сделал не так- не включил -Wstrict-overflow в -Wall.

> И? Отключи оптимизацию - получишь ожидаемое поведение

в стандарте что-то сказано насчет «если оптимизации нет, то UB при переполнении отменяется»?

Оптимизация в Си (а может, и везде) основывается на некоторых предположениях об исходной программе.

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

в случае си, если оно пытается быть кроссплатформенным ассемблером,

1. необходим тип целых чисел по модулю 2**16 с его поддержкой оптимизатором или хотя бы БЕЗ ДУРИ оптимизатора (так как такой тип есть в любом ассемблере)

2. если уж такого типа нет, так хоть стандарт на флаги компилятору как в жцц

>> И? Отключи оптимизацию - получишь ожидаемое поведение

в стандарте что-то сказано насчет «если оптимизации нет, то UB при переполнении отменяется»?

В здравом смысле сказано «оптимизатор пытается угадать, что имел в виду прогер». Если не угадывает... ты проиграл.

1. необходим тип целых чисел по модулю 2**16 с его поддержкой оптимизатором или хотя бы БЕЗ ДУРИ оптимизатора (так как такой тип есть в любом ассемблере)

Если тебе нужен ассемблер вместо оптимизирующего компилятора, используй -O0.

Примеры дури без оптимизации будут?

> В здравом смысле

о здравом смысле может идти речь только в том контексте, что стандарт не соответствует здравому смыслу,

а не в том, что стоит полагаться на здравый смысл там, где стандарт *явно* говорит про UB

В здравом смысле сказано «оптимизатор пытается угадать, что имел в виду прогер». Если не угадывает... ты проиграл.

И что я проиграл? 10% производительности? это не страшно. А вот если цикл из 32 итераций стал бесконечным — это уже совсем другое.

Си, как он щас есть — это не рулетка «угадает оптимизатор или нет».

Программер клянется не переполнять знаковые целые, не стоить логику на порядке вычисления аргументов функций (и прочие неочевидные вещи :-), а компилятор клянется все это оптимизиовать без искажения смысла. Если компилятор клятву не соблюдает — есть багзилла. Да и вообще маловероятен баг в изъежженном вдоль и поперек оптимизаторе.

Если тебе нужен ассемблер вместо оптимизирующего компилятора, используй -O0.

Подтвердить эти слова стандартом, я так понимаю, ты не собираешься? Ну так у тебя еще есть возможность подтвердить их хотя бы официальными заявляениями разработчиков жцц или ицц.

Ну и еще остается случай, когда мне нужен И ассемблер И оптимизирующий компилятор в одном флаконе.

> Примеры дури без оптимизации будут?

мне они не известны, и моя гипотеза именно в том, что они проявляются из-за оптимизации

... и кстати — ты в своих советах «юзай -О0» опирался на мою гипотезу, а она еще и не доказана!

> Си, как он щас есть — это не рулетка «угадает оптимизатор или нет».

(пожимая плечами) Ты знаешь о нем что-то такое, чего не знаю я.

Если тебе нужен ассемблер вместо оптимизирующего компилятора, используй -O0.

Подтвердить эти слова стандартом, я так понимаю, ты не собираешься?

Нет, конечно. Я и так чувствую себя Капитаном Очевидность.

Ну и еще остается случай, когда мне нужен И ассемблер И оптимизирующий компилятор в одном флаконе.

Сделай. А я посмотрю, можно ли будет пользоваться результатом.

> ты в своих советах «юзай -О0» опирался на мою гипотезу, а она еще и не доказана!

Бгг. Я в своем совете «используй -O0» опирался на багрепорты, которые привели ты и Manhunt.

> Бгг. Я в своем совете «используй -O0» опирался на багрепорты, которые привели ты и Manhunt.

логика есть?

1. The C and C++ language standards say that overflow of a signed value is undefined behaviour.

2. Мы привели примеры, что undefined behaviour реализуется через допустим О2

отсюда НЕ СЛЕДУЕТ, что -O0 спасет от undefined behaviour

>> Подтвердить эти слова стандартом, я так понимаю, ты не собираешься?

Нет, конечно. Я и так чувствую себя Капитаном Очевидность.

При том, что в стандарте четко говорится UB, а ты говоришь — «да ниче страшного, юзай -О0»

Ну и еще остается случай, когда мне нужен И ассемблер И оптимизирующий компилятор в одном флаконе.

Сделай. А я посмотрю, можно ли будет пользоваться результатом.

честно говоря, я в такие дебри лезть не собирался, но подумать можно

что можно сделать — это выставлять опции жцц для тех функций, где учавствуют переполняемые типы

а еще я надеюсь, что у жцц внутри переполняемые типы отличаются от непереполняемых — в противном случае как он будет корректно инлайнить функции, чье тело передается не в хедере, а в библиотеке или объектном файл (я емнип читал о такой оптимизации)

все-таки та надежда маловероятна

а вот еще можно, опираясь на типы, резать функции на куски и компилить их с разными флагами

такие вот костыли

> отсюда НЕ СЛЕДУЕТ, что -O0 спасет от undefined behaviour

Проверь свою логику, ок? Я (да и ты) с самого начала сказал «на большинстве железа». А стандарт (какая неожиданность) не для «большинства железа» пишется.

И кстати... уясни разницу между UB и IDB.

При том, что в стандарте четко говорится UB

Главу стандарта или ссылку на багрепорт. Вот цитата из багрепорта, на который сослался Manhunt:

«that is _not_ undefined, but rather implementation-defined, and GCC has chosen to define the conversion as modulo operation».

Хочешь дополнить стандарт? Вперед. Облегчит ли твое дополнение жизнь прогеру? Нет.

Мои 5 копеек: уж лучше потратить капельку времени и все же выучить полезные фишки языка чем сидеть с простым языком и париться в реализации простейших вещей. Обычно используют небольшое подмножество сложного языка...

> Главу стандарта или ссылку на багрепорт.

The C and C++ language standards say that overflow of a signed value is undefined behaviour. In the C99 standard this is in section 6.5.

конкретно:

If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined.

Вот цитата из багрепорта, на который сослался Manhunt: «that is _not_ undefined, but rather implementation-defined, and GCC has chosen to define the conversion as modulo operation».

ха. конверсия из инта в шорт уж точно не будет UB, а там речь про нее:

There is a conversion (from int to short) where the value is not representable by the target type, but that is _not_ undefined, but rather implementation-defined, and GCC has chosen to define the conversion as modulo operation.

из того же бага:

I think this is a bug, because although signed overflow is undefined behaviour, that should affect only the value of 'from',

> Хочешь дополнить стандарт? Вперед. Облегчит ли твое дополнение жизнь прогеру? Нет.

действие вторично — пока что мы выясняем, что стандарт негоден

насчет необлегчения жизни прогеру — не понял

Проверь свою логику, ок? Я (да и ты) с самого начала сказал «на большинстве железа». А стандарт (какая неожиданность) не для «большинства железа» пишется.

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

кстати, чувак, сделавший опции, вообще считает, что

There is a clear difference on a processor which does not use ordinary twos-complement arithmetic: -fwrapv requires twos-complement overflow, and -fno-strict-overflow does not. However, no such processor is in common use today.

>Мои 5 копеек: уж лучше потратить капельку времени и все же выучить полезные фишки языка чем сидеть с простым языком и париться в реализации простейших вещей.

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

вообще весь мой пафос (с цитированием стандарта) в том, что *стандартные* си и с++ это не совсем то, или даже совсем не то, что

1. о них думают практические программисты

2. хотели бы видеть в них практические программисты

а разумно было как раз сделать из них именно то, что хотели бы видеть в них практические программисты,

вопрос только как

> не понял необходимости выбора

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

> определение поведения при переполнении целого, это прибитие гвоздями к одной конкретной категории архитектур

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

1. Зачем?

2. _Какое_ поведение?

3. Ты дисскусию вообще читал или просто решил потупить?

1. Чтобы обосновать, что «прибитие гвоздями» в данном случае влечет хоть какие-то проблемы.
2. Арифметика по модулю 2^N при переполнении знаковых целых.
3. Читал.

Это диалект Форта штоле?

hq9+

Нет. Отличий не в пример больше, чем сходств.

афаик, ни среди авторов, ни среди пользователей фортистов нет вообще.