Язык программирования. Какой изучить?

gooblin:

про минус 1 вопрос спорный

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

gooblin:

что есть предел точности

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

Правильным ответом на вопрос о том, как представлен float и double, скажем, в языках C и C++ является ответ "это определяется реализацией". Ни один, ни другой не принимают IEEE 754 в качестве требуемого представления.

А "самоучек от сохи", которые ночью при свете лучины разглядывали биты в памяти, "знают как устроен компьютер", и думают, что они что-то после всего этого поняли, приходятся потом переучивать с нуля, когда они впервые в жизни сталкиваются в языке С (который они считали чуть ли не ассемблером) со strict-overflow semantics, strict-aliasing semantics и тому подобным "неассемблерным" поведением. Вопли "так ведь у Коляна из третьего подъезда это точно работало, зуб даю" идут непрерывным потоком.

Mahagam:

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

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

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

Однако по какой-то мне совсем не понятной причине эта простая аксиома вызвала нешуточное "бурление фекалий" среди местной "пионэрии". Отчасти их можно понять: ясно, что не всегда можно получить в Беларуси те предметные знания, которые получают в Кремниевой Долине. Но для успешного старта - все есть.

Mahagam:

фанаты UB подвисают, когда null pointer - это вдруг бывает нормально, и строки вида int *foo = NULL; (*foo)++; - работают

Намного интереснее наблюдать подвисание "фанатов UB" когда компилятор транслирует

for (int i = 0; i >= 0; i++)
...

в бесконечный цикл, несмотря на то, что они "точно знают из ассемблера (и Колян подтвердит)", что при переполнении знаковой переменной ее значение должно стать отрицательным и цикл якобы должен завершиться.

Или когда компилятор в коде

void SomeClass::SomeMethod()
{
if (this != 0)
...
}

рассматривает условие `this != 0` как заведомо истинное и выкидывает проверку из кода вообще ("а ведь в Борланде работало" )

Или как при возвращении ссылки/указателя на локальную переменную

char *foo()
{
char hw[] = "Hello World";
return hw;
}

компилятор нагло подставляет в качество возвращаемого значения нулевой указатель ("а ведь в Борланде работало" ).

Современные компиляторы С и С++ троллят разношерстных "кул-хацкеров" в хвост и в гриву. И введение в GCC поддержки strict-aliasing semantics, и знаменитая история с направлением копирования в `memcpy`, вызвала, помнится, свое время некрасивые истерики аж со стороны примадонны Торвальдса. Но ребята из GCC лишь молча улыбаются в ответ

Вот также и ваше `int *foo = NULL; (*foo)++;` компиляторы скоро либо просто начнут выкидывать из кода, либо будут назло сегфолтить программу даже на тех платформах, на которых это раньше не сегфолтилось . Чтобы не повадно было.

P.S. Какого черта онлайнеровский форум транслирует символы внутри тега code???

Mahagam:

Korben_Dallas:

Намного интереснее наблюдать подвисание "фанатов UB" когда компилятор транслирует

for (int i = 0; i >= 0; i++)
в бесконечный цикл, несмотря на то, что они "точно знают из ассемблера (и Колян подтвердит)", что переполнении знаковой переменной ее значение должно стать отрицательным и цикл якобы должен завершиться.

это точно си?

Точно. А почему возник такой вопрос?

Mahagam:

а с чего это надо продолжать пользоваться компилятором который придумывает "правильное" поведение программы?

Вопрос не совсем ясен.

Во-первых, в придумывании "правильного" поведения программы ничего странного нет. Компилятор должен придумывать "правильное" поведение программы в ситуациях, когда имеет место implementation-defined behavior. Так было всегда.

Во-вторых, здесь ситуация еще "свободнее": согласно спецификации языка, при возникновении знакового арифметического переполнения поведение С (и С++) программы не определено (undefined behavior). А undefined behavior - это совсем другая история:

1) не существует "правильного" или "неправильного" поведения, и
2) как ни верти, а поведение программы придется "придумывать", ибо стандартом оно не определено.

Вы придумали свое поведение и почему-то решили, что оно - правильное. Тем, кто занимается такими выдумками для случаев undefined behavior (!), надо больно давать по рукам. Что GCC с радостью и делает.

Они молодцы. Не во всем, но в этом точно. Именно такими компиляторами и надо пользоваться.

olezha_:

Лол) как уже только ни пытаются обосрать айтишников: больные, кривые, косые, жирные, импотенты
Товарищи, не становитесь айтишниками! Полно профессий за попиццот! Зато точно писька стоять будет
Хоспаде, какие же идиоты бывают.

Зависть плохое чувство

gooblin:

Korben_Dallas, а кто говорит что надо пытаться угадать что будет делать компилятор в случае undefined behavior - по моему это и ежу понятно.

Я веду речь о тех идивидуумах, которые пытаются настаивать на конкретных "единственно правильных" проявлениях неопределенного поведения, ссылаясь на собственный опыт и бессонные ночи, занятые разглядыванием "ассемблера". Недостатка в них нет. И на stackoverflow, и на ru.stackoverflow, и на cyberforum.ru вопросы на эти темы всплывают часто. И если новичкам еще несложно вбить в головы правильные установки, то самозваным "икзпердам", которые "уже 20 лет так программируют", приходится разжевывать цитаты из стандарта и вбивать в голову чуть ли не кувалдой.

ИМХО. Спор ни о чем. И ежу понятно, что если делается кросс платформенная система которая должна собираться на разных системах, зачастую с разными компиляторами, и имеет жизненный цикл не пол года, а куда больше, то там нельзя полагаться ни на какие особенности поведения конкретного компилятора, даже если вы их знаете.
А на счет ребят из GCC, то они могут посмееваться над чем хотят, только им нужно помнить, что компилятор - это инструмент, а не сферический конь в вакууме. И если они будут так весело смеяться и бить по рукам, что их инструментом предпочтут не пользоваться, то им легко станет не до смеха. Я сам, в своей практике, не пишу выражений которые могут быть поняты не однозначно или требуют знаний каких-то нигде не определенных вещей. А если есть место которое не понятно сходу - ставлю поясняющий комментарий.

Mahagam:

потому что сразу возникает вопрос - как будет выкручиваться компилятор в таком случае:

for (int i = 0; i >= 0; i++) {
important_var = sqrt((double(i));
...
}

как ему удастся выдать тут бесконечный цикл? я же имею право полагать, что i у меня никогда не будет отрицательным числом.и вообще, с какого перепуга там вышел бесконечный цикл? есть этому логическое объяснение? в случае если язык - не си, то такое объяснение можно объяснить что тип int - не тот, что в си.

Korben_Dallas имел ввиду что в какой-то момент i станет равен INT_MAX, и если после этого сделать i++ то это и будет UB. То есть стандартом не гарантируется что при увеличении целого числа INT_MAX на единицу получится отрицательное число. А вы на это полагаетесь только на основании своего опыта.

По второму вашему примеру нормальный компилятор как минимум выдаст warning.

Mahagam, вы разницу между стандартом языка и его частной реализацией в виде gcc понимаете?

Mahagam, вы путаете теплое с мягким