Digispark + ds18b20 + шим

Мне нравится ход ваших мыслей. Но это не моя тема. Раз работает - значит все ок.

Пы.Сы. Не, не нравится. в данной ситуации не сработает правило "от перемены мест слагаемых..."
Если разбить операцию на три шага, из которых она и состоит, оно не получится.
Слава компилятору!

 

C - очень низкоуровневый язык. Писать на нём с отрывом от архитектуры вычислительного ядра не получится.

 

Да блин, в Си еще со времен моего децтва операнды меньше размером чем int приводились к типу int по умолчанию. В данном конкретном случае ошибки нет, сначала байт расширяется до слова, потом оно сдвигается.

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

• Если какой-либо из операндов имеет тип unsigned long, то другой операнд преобразуется в тип unsigned long.
  
  
• Если вышеуказанное условие не выполняется, при этом один из операндов имеет тип long , а второй — тип unsigned int , то оба операнда преобразуются в тип unsigned long .
  
  
• Если два вышеуказанных условия не выполняются, а один из операндов имеет тип long , то второй операнд преобразуется в тип long .
  
  
• Если три вышеуказанных условия не выполняются и какой-либо из операндов имеет тип unsigned int, то другой операнд преобразуется в тип unsigned int.
  
  
• Если ни одно из вышеуказанных условий не соблюдается, то оба операнда преобразуются в тип int.

 

... вечер переставал быть томным
Значит не компилятор?

 

на восьмибитках?

 

Да, скорее всего.

Писец, кстати, он вот такой:

 

Да, а что?

Какая разница сколькибитки, если это требование языка?

 

Нет.

 

Языку.

Зато в других ситуация отлично срабатывает. Попробуйте и убедитесь, что:

Код (C++):

int a[10];

// Вот это
for (int i = 0; i < 10; i++)  a[i] = i+101;

// 100% эквиваленто вот этому
for (int i = 0; i < 10; i++)  i[a] = i+101;

Ну, разве не прелестно?

 

потому как размерность слова связана с размерностью шины процессора.

 

это сахар. И я бы его точно нигде не использовал потому как во втором случае массив из цикла не вытащишь.

 

со времен седой древности (помнишь i8031, i8080? А я помню) принято, что int по умолчанию имеет размер указателя, поэтому он, канеш, зависит от ширины шины, но не шины данных, а шины адреса.

 

Зззххххх, вырвались кони на свободу!

Код (C++):

int a[10]; // Массив а из десяти элементов

// Вот это
for (int i = 0; i < 10; i++)  a[i] = i+101; // Так дохтор прописывает

// 100% эквиваленто вот этому
for (int i = 0; i < 10; i++)  i[a] = i+101;  // В скобках(!) локальный i, что гуляет от 0 до 9
// А (необъявленный массив???) "i[?]" после скобок - требует объяснения и уголовной ответственности по статье 117 за истязание кода и кодеров.
 

 

Вы меня не слышите. Приводить к "не короче, чем int" - требование ЯЗЫКА. Каким боком тут шины, процессоры и прочие мультиплексоры?

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

 

Ни разу. Это фундаментально свойство операции сложения - коммутативность.
Сахар здесь - сама по себе операция взятия элемента по индексу.

Я не понимаю, что означает фраза "массив из цикла не вытащишь", но опять же отмечу, что Вы меня не слышите. Как я уже сказал, эти два случая абсолютно эквивалентны. Если что-то вытащишь (не вытащишь) в одном, то тоже самое и в другом.

Написать a[3] или 3[a] - абсолютно одинаково - никакой разницы!

 

Ещё хлеще написать 3[a] вместо a[3]. Видимо, массив 3 - не объявлен ))

 

Нельзя интригу заводить так далеко. Отбивает желание читать учебники: "сколько ни учись, все равно дураком помрешь"

 

Наданапицца.

 

Блин, простите, я был уверен, что Вы всё знаете, просто подыгрываете мне.

Ну, там всё просто, в С++ (и в С тоже) на самом деле нет как таковой операции «взятие элемента по индексу», вернее, она есть, но она производная - определена через операцию сложения (тот самый «синтаксический сахар»).

Давайте посмотрим документ ISO/IEC 14882:2020.

В §7.6.1.2(1) прямоговорится: «... The expression E1[E2] is identical (by definition) to *((E1)+(E2)) ...».

Т.е. операция взятия элемента по индексу определяется («by definition»!!!) как сложение указателя с индексом с последующим разыменованием. Сложение же, как известно, коммутативно – ему не важен порядок следования операндов!

Здесь, можно было бы и остановится. Если это, на самом деле, сложение, то не должно быть никакой разницы между a[3] и 3[a]. Первое эквивалентно *(a+3), а второе – *(3+a) – разницы никакой. Но, поскольку это необычно, авторы стандарта решили дать отдельное, особое пояснение на этот счёт. Его мы видим в §7.6.1.2(3): «Despite its asymmetric appearance, subscripting is a commutative operation».

Всё! Операция взятия элемента по индексу коммутативна, это сказано прямым текстом. Вопрос закрыт!

Дальнейшее можно не читать, если не хотите вдаваться в

Спойлер: «совсем уж тонкости»

Когда я говорю, что между a[3] и 3[a] нет никакой разницы, я всё-таки немного лукавлю. Разница есть, но она очень тонкая. Дело в том, что для операции сложения порядок вычисления операндов не определён, а вот для взятия по индексу – определён: при подготовке операндов выражения E1(E2), E1 вычисляется раньше, чем E2. Иногда это важно.

Например, если процедуры вычисления E1 и E2 содержат побочные эффекты, то эффекты E1 будут влиять на вычисление E2, а не наоборот. Пример нужен? Мне не трудно.

Тот факт, что «E1 вычисляется раньше, чем E2» может также повлиять на эффективность кода в случае автоматического распараллеливания на многоядерных установках. Вот смотрите, если мы напишем через сложение: *((E1)+(E2)), компилятор может организовать параллельное вычисление E1 и E2 – например, раскидать их вычисление по разным ядрам (т.к. при сложении порядок вычисления операндов не определён). А вот если мы напишем E1[E2], то хренушки – он обязан гарантировать, что E1 будет вычислено раньше, чем E2.

 

Я DIY-щик, возможно чуть продвинутый. Мой уровень познания языка - один учебник, периодически забываемый. Замыслил что-то - подчитал, не делаю долго - забыл.

В учебнике нет таких тонкостей. Постоянно в моей памяти лишь что название массива - указатель на его адрес. Доступ возможен сложением с указателем, еще немного таких же неглубоких знаний, но они позволяют писать код IFTTT.

Программирование на языке ХХХ(любом) - не мое хобби.

А за таблетницу - еще одно спасибо. Полгода на аккумуляторе 18650 - полет нормальный. Выручает