На всякий случай сохронил
02.12.2022, 08:35
человек, который способен использовать такое в реальной жизни, при этом не иднус, а осознанно готовый к любым последствиям, достоит валгаллы (вариант, что он умрёт не насильственной смертью мы не рассматриваем в виду малых шансов)
В реальной жизни такое не нужно.
Так что достоин он максимум хороших таких пизюлей за нечитабельность кода.
Так что достоин он максимум хороших таких пизюлей за нечитабельность кода.
i = 13 ?
Хотя не, 14
Если не ошибаюсь первым идут операторы ++, потом операторы сложения. Т.е. сначала, 2 раза ++, т.е. i =7 и потом i+i, т.е. 14
мало того, что это по разному регламентировано в разных языках, так это может отличаться ещё и в разных компиляторах для одного языка. но 13 самый правильный ответ из всех правильных
Это зависит от языка, коимпилятора, фазы луны...
Копипаста с лурка
"В данном примере происходит неоднократное изменение переменной в пределах одной точки следования, такая ситуация описывается в стандартах C и С++ как UB. Иными словами, даже попытки ответить на этот вопрос иначе как «UB» демонстрируют недостаточную квалификацию отвечающего. Другое дело, что после «UB» можно указать некоторые подробности, и мы этим займёмся, поскольку не утоленное вовремя любопытство приводит к драмам в обсуждении.
Конкретно неопределённость в этой, как некоторым кажется, кристально ясной конструкции в данном случае заключается в том, что, согласно стандартам С и С++, побочные эффекты (то есть инкремент в данном случае) могут быть применены в любой удобный для компилятора момент между двумя точками следования. Конструкцию i = ++i + ++i; компилятор вправе понять и как
tmp=i; tmp++; i = tmp; tmp++; i += tmp;
и как
tmp=i; tmp++; tmp++; i = tmp + tmp;
и какими-нибудь другими способами. Нужна такая свобода для проведения низкоуровневых оптимизаций в обычных случаях типа a = ++b + ++c;, дабы между делом сэкономить пару тактов на халяву.
Хотя, оптимизатор тут вообще не при чём. Дело в том, что наше интуитивное понимание работы этого кода основывается на том, что прединкремент возвращает значение, получившееся после прибавления единицы. На самом же деле любой нормальный прединкремент возвращает не получившееся значение, а ссылку на эту же переменную. Поэтому мы складываем не числа, а две одинаковые ссылки, то есть переменную i саму с собой! Иными словами происходит буквально следующее:
1. Левый ++i прибавляет единицу к i и возвращает ссылку на неё. I = 6.
2. Правый ++i прибавляет ещё одну единицу к i и также возвращает ссылку на неё. I = 7.
3. Оператор сложения разыменовывает ссылки, получая i = i + i. Так как после второго шага I = 7, то извлекается именно это число, давая выражение i = 7 + 7, откуда и получается 14."
Копипаста с лурка
"В данном примере происходит неоднократное изменение переменной в пределах одной точки следования, такая ситуация описывается в стандартах C и С++ как UB. Иными словами, даже попытки ответить на этот вопрос иначе как «UB» демонстрируют недостаточную квалификацию отвечающего. Другое дело, что после «UB» можно указать некоторые подробности, и мы этим займёмся, поскольку не утоленное вовремя любопытство приводит к драмам в обсуждении.
Конкретно неопределённость в этой, как некоторым кажется, кристально ясной конструкции в данном случае заключается в том, что, согласно стандартам С и С++, побочные эффекты (то есть инкремент в данном случае) могут быть применены в любой удобный для компилятора момент между двумя точками следования. Конструкцию i = ++i + ++i; компилятор вправе понять и как
tmp=i; tmp++; i = tmp; tmp++; i += tmp;
и как
tmp=i; tmp++; tmp++; i = tmp + tmp;
и какими-нибудь другими способами. Нужна такая свобода для проведения низкоуровневых оптимизаций в обычных случаях типа a = ++b + ++c;, дабы между делом сэкономить пару тактов на халяву.
Хотя, оптимизатор тут вообще не при чём. Дело в том, что наше интуитивное понимание работы этого кода основывается на том, что прединкремент возвращает значение, получившееся после прибавления единицы. На самом же деле любой нормальный прединкремент возвращает не получившееся значение, а ссылку на эту же переменную. Поэтому мы складываем не числа, а две одинаковые ссылки, то есть переменную i саму с собой! Иными словами происходит буквально следующее:
1. Левый ++i прибавляет единицу к i и возвращает ссылку на неё. I = 6.
2. Правый ++i прибавляет ещё одну единицу к i и также возвращает ссылку на неё. I = 7.
3. Оператор сложения разыменовывает ссылки, получая i = i + i. Так как после второго шага I = 7, то извлекается именно это число, давая выражение i = 7 + 7, откуда и получается 14."
Язык СИ компилятор gcc, linux ubunta 20.04 64 бит процессор Intel® Core™ i7-10850H CPU @ 2.70GHz × 12
#include
int main ( void )
{
unsigned int i = 1;
i += ++i + ++i;
printf ( "I = %u", i);
return 0;
}
I = 9
Все то же самое, только тип меняем на unsigned char:
#include
int main ( void )
{
unsigned char i = 1;
i += ++i + ++i;
printf ( "I = %u", i);
return 0;
}
I = 8
знатоки помогайте
#include
int main ( void )
{
unsigned int i = 1;
i += ++i + ++i;
printf ( "I = %u", i);
return 0;
}
I = 9
Все то же самое, только тип меняем на unsigned char:
#include
int main ( void )
{
unsigned char i = 1;
i += ++i + ++i;
printf ( "I = %u", i);
return 0;
}
I = 8
знатоки помогайте
Зависит от реализации языка(если там есть такая конструкция) и для С - от компилятора. Тащемта, суть в том, сохраняется ли значение первого аргумента где-то в регистре после его вычисления, или же используется то же, что и во втором.
Обычно - сохраняется, и будет 13. Но это не точно.
Обычно - сохраняется, и будет 13. Но это не точно.
Смотри
Ты же в курсе что компы все считают в двоичной системе. Тип 0 = 0, 1 = 1, 2 = 10, 3 = 11, 4 = 100 и тд.
Тут начинается проблема с дробями. 1/2, 1/4 -- это норм, это можно без проблем записать в двоичной системе. А вот когда доходит до 1/10 тут вылезает проблемма, тк мы привыкли считать в десятичной системе и делить соответственно тоже. А там из-за того что комп не может нормально делить на 5, 3, 7 и тд вылазит вот такая незаметная доля.
Сразу прошу прощения за неточности, пытался простым языком объяснить
Вот ссылка если хочется глубже в тему:
https://betterprogramming.pub/why-is-0-1-0-2-not-equal-to-0-3-in-most-programming-languages-99432310d476
Ты же в курсе что компы все считают в двоичной системе. Тип 0 = 0, 1 = 1, 2 = 10, 3 = 11, 4 = 100 и тд.
Тут начинается проблема с дробями. 1/2, 1/4 -- это норм, это можно без проблем записать в двоичной системе. А вот когда доходит до 1/10 тут вылезает проблемма, тк мы привыкли считать в десятичной системе и делить соответственно тоже. А там из-за того что комп не может нормально делить на 5, 3, 7 и тд вылазит вот такая незаметная доля.
Сразу прошу прощения за неточности, пытался простым языком объяснить
Вот ссылка если хочется глубже в тему:
https://betterprogramming.pub/why-is-0-1-0-2-not-equal-to-0-3-in-most-programming-languages-99432310d476
иди дальше, человек
А потом потребуют изуродовать точнейшее вычисление и обрезать до двух знаков после запятой.
это что то на программерском?
ошибка компиляции
особенности хранения дробных чисел в памяти компьютера.
Если я ещё что-то помню и понимаю в принципиальных схемах, то это какой-то передатчик. Правда ооооочень корявый и абсолютно не рабочий. Транзистор в обрыве, колебательный контур вообще гдето в воздухе, вместо микрофона розетка IR(?) да и остальное непонятно как и зачем.
Понятно что художник рисовал что-то рандомное с рандомной схемы по принципу "лишь бы было похоже", но что-то смутно похожее на передатчик угадывается.
Понятно что художник рисовал что-то рандомное с рандомной схемы по принципу "лишь бы было похоже", но что-то смутно похожее на передатчик угадывается.
Чтобы написать коммент, необходимо залогиниться
