Перейти к содержанию

    

GetSmart

Участник
  • Публикаций

    4 009
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о GetSmart

  • Звание
    .

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    Россия
  1. Алгоритмический нежданчик. Кусочно-линейная интерполяция fixed-point, выполняющаяся быстрее одного (!) софтового деления int на int, например в ARM7/CM0, которые без аппаратного. Но быстрее, если кол-во точек/изломов меньше, чем бит в int, и доступ к константам быстрый или из ОЗУ. Это такие мелочи на фоне сюрприза. int interpol(int adc) { static const unsigned char mas[] = { K0,K1,K2,K3...,0 }; int delta, res = ABC; if ((adc -= 32) >= 0) { unsigned char const *p = &mas[0]; while ((delta = *p++)) { res -= delta; if ((adc -= 32) < 0) return res - (delta*adc >> 3); } delta = 256; // наклон отриц. края } else delta = 256; // наклон полож. края return res - (delta*adc >> 3); }
  2. у продавца этот прибор назывался "Фотодиод -5012PD 5мм 940нм 35 гр." И перед созданией темы в инете я нашёл подходящий по названию только FYL-5012PD. Неужели есть другие варианты? Судя по многолетним покупкам у этого продавца, сомнений в качестве товара до сих пор не было. Кроме недорогих литиевых аккумов, которые у большинства продавцов несоответствуют надписям на них, часто раз в 10 меньше ёмкость.
  3. Имею на руках эту вещь. Почти везде на сайтах пишут, что фотодиод. Но тестером прозванивается как фототранзистор и по коэф. преобр. намного сильнее большинства фотодиодов. При смене полярности подключения тоже работает, как фототранз, с разницей в усилении как прямая и обратная бэта. Кто что скажет? Какие ещё можно провести тесты?
  4. ужжас нашего городка.... как зайти в личный кабинет? Где кнопки из шапки форума? Сейчас в самом низу страницы есть кнопки Язык и Тема. Нажатие на "Язык" сработало и сделало русский. Но нажатие на Тема-->Classic 4.5.2 написало "нет прав". Ни на какую тему нет прав. Подскажите, плиз, ссыль, как посещать форум в удобном старом формате страниц?
  5. Как буд-то родился "кошмар на улице си" index[array]. Не прочитав всю кучу документов точно и не разберёшься. Полноценный перевод этого мутного термина я не знаю. В каких-то словарях компьютерных терминов его кастрируют до <индексация>. Но в общеупотребительном смысле это слово более многогранное. Со смыслами <одобрить>, <согласиться>. Пока (если лучше версию не увижу), наверное буду считать в Си "признать массивом и индексировать". Но у буржуев есть какой-то схожий термин "superscripting" (superscription-надпись, в общеупотребительном аглицком), которе вместе (теоретически наверно) могут как-то обозначать вариации индексаций "вглубь" (для массивов) или наружу (для указателей). Но с такими тонкостями толкования я пока не пересекался. Мутность такая же, как при переводе термина bitwise (complement), о котором когда-то спорили.
  6. Это по шагам можете объяснить? Мне понятны варианты когда а[0][24] идентичен a[1][19] и идентичен a[2][14] и т.д. Если не обращать внимание на варнинги компилятора. Но a[24][0] каким образом-то? index1[index2][array_name] и index1[index2][index3][array_name] тоже разрешены? Если да, исходя из каких формулировок? То есть разрешение применения [] к любому указателю на непустой тип даёт именно первый абзац главы <6.5.2.1 Array subscripting> ? object type определён как любой, за исключением void? В стандарте есть суммарный раздел об авто-преобразованиях? Или надо шерстить весь стандарт чтобы откопать однозначность? Видимо отсюда и растут ноги у названия "подписка". Страннейшего, для необкуренных мозгов. Обозвали бы "индексация" и уловка с авто-подменой была бы недоступна. В посте 40 я ошибся, в цитате: <И уже когда к этому аргументу будет приплюсовываться число 5, то оно, проще говоря, должно быть (наиболее вероятно по вышеобозначенной инфе) индексом следующей (второй) размерности.> т.к. на следующую размерность не перейти, без применения оператора * в вариантах со сложением. Ну бред же. Для компилятора имя массива - это lvalue (кратко - объект в памяти). К нему можно применить амперсанд. &имя_массива[0] - это rvalue, к нему (здесь будет второй раз) амперсанд не применим. И для (простейше определённого) многомерного массива array_name[0] есть тоже lvalue. А, согласно этой цитаты, выражение &(array_name[0]) давало бы ошибку. Т.к. выражение в скобках, являющееся массивом авто-преобразовывалось бы в указатель. Хотя, корректней писать в <rvalue-указатель>. Всё это потверждает, что и rvalue с типом указатель на массив и lvalue с типом массив существуют без всякого sizeof, в них определена характеристика размера (для размерных), компиляторы поступают вполне разумно её проверяя на этапе компиляции, а что мешает копировать массивы выражениями вроде a=b - непонятно. В языке должна быть ясность очерёдности исполнения авто-преобразований и операторов. Например: авто-преобразования применяются компилятором в самый последний момент исполнения операторов. И не должны менять приоритеты операторов при определении очерёдности их исполнения. Хотя, с таким неполным стандартом, если по нему ясность поведения будет не определена, то, наверное, судить придётся по каким-то ещё документам, например от выдумщика языка. А то появится несогласующийся с ранее написанными правилами футбол между операторами, операндами и авто-преобразованиями. (в этой ветке я ранее писал аргументов, но терминологически точнее, видимо, операндов для операторов и аргументов/параметров для функций) Пытаясь как-то оправдать логику выдумщика и потом стандарта, когда на начальном этапе массив (array object по терминологии главы 6.5.2.1) казался избыточным и работу с массивами НАДО БЫЛО организовывать через указатели и операторы +-, которым был непринципиален порядок разношёрстных операндов, мне самому любопытно, на какой развилке не туда свернули))) Упд. Именно такая историческая цепь прослеживается при чтении стандарта, когда оператор [] определяется текстовым примером через ранее определённые выражения.
  7. В стандарте есть явные определения логики интерпретации применения [] к указателю на не массив и на не элемент массива? Никаких <почти всегда> оттуда не следует. Тем более, что что-то там преобразуется. Смысл написанного: <допускается писать такую конструкцию с такими-то вариантами, которая будет истолкована так...>
  8. <(equivalently, a pointer> в данном контексте переводится как: <(равно{значно} {допустимо}, если это указатель> фигурными скобками выделил неявный смысл, который, при желании, можно не писать. В контексте этого абзаца <equivalently> не определяет, что везде в языке оба варианта равнозначны. Ещё, из этой цитаты не понять, какое действие вызывает оператор [], применимый к обычному указателю. Даже из всей главы <6.5.2.1 Array subscripting> непонятно, какое действие по стандарту выполняет применение [] к указателю на не массив (на не элемент массива). В её вступлении написали Далее везде "если это массив или указатель на начальный элемент массива то ...". PS но я мельком прочитал эти три абзаца. Прошу опровергнуть, если я неправ. Upd Учитывая вступительную цитату, с которой я только что ознакомился моё утверждение <В цитате было (буквально) сложение с именем массива. > правильнее заменить на <В цитате вполне допускалось сложение с именем массива.>
  9. Определение дано на текстовом примере. После этого запрещать описание словами текстовых конструкций языка бессмысленно. Кроме того, в данном контексте <имя массива> более однозначно описывает <инструкцию> писателя кода. Если я напишу <массив>, то сразу подменю обсуждаемую <инструкцию> до многих вариантов текстового представления. Поэтому такие формулировки имеют право быть. Добавлять везде <в тексте> излишне, это неявно контекстно подразумевается. Скорее будет важно: до препроцессора или после, всякие области видимости, наложения имён переменных, макросов и прочего. По-умолчанию в таких формулировках разумно считать, что интерпретация текста по стандарту в том тексте выявит однозначно: имя массива, оператор сложения и целое число 5. И оператор сложения будет выполнен до всех иных операторов. Ерунда какая-то. 5*5=25
  10. Я пару раз добавил в конец предыдущих постов одно и два предложения. И один раз абзац с отметкой Upd. В последний раз даже не видел, что уже новый пост появился. Редактирование постов для уточнения мыслей и существует. Ничего криминального в этом нет. Не удержался. Третий раз дополнил предыдущий пост. Позже почитаю, после отпуска.
  11. Туда же добавил <К указателю он тоже применим, но их идентичность это не доказывает, без документального подтверждения.> Сложение с именем массива: result = *(array+5) Сложение с указателем (на тип элементов из которых состоит массив): result = *(&array[0]+5) В цитате было (буквально) сложение с именем массива. Переводится как <Определением <subscript operator []> является то, что {неявно подразумевается: выражение} E1[E2] идентично {выражению} (*((E1)+(E2)))> Из чего следует, что в текстах разрешено использовать выражения со сложениями целых чисел с именами массивов. Без оговорок на размерность массивов. Upd: А ещё точнее: с такими же ограничениями как и для оператора []. Всё это не исключает при сложениях и такой возможности: при невозможности к аргументу применить оператор [], могут быть применены другие правила (если они определены), как то: трансформация аргумента в указатель и сложение с этим указателем. То, что в определении имя заключено в круглые скобки - сути не меняет, т.к. в этом выражении они являются оператором изменения очерёдности выполнения других операторов. (чорт его знает как скобки там дословно определили) И (array)[index] по смыслу исполнения равноценно array[index], когда внутри скобок нет операторов. {неявно подразумевая: в тексте после препроцессора} ------------- Дежа-вю
  12. В вышеобсуждаемой цитата из стандарта явно указано, что такое выражение разрешено стандартом (сложение чисел с именем массива). При неуказании особых правил этого "изврата" применяются стандартные правила приоритетов и ассоциативности. Без оговорок и комментариев на уровне стандарта иначе это нельзя истолковать. Лучше даже уточнить: <Адрес> точнее будет заменить на <что-то> (неуказанное в стандарте), содержащее адрес, указывающий на вышеобозначенный тип. (пример: <сперва выполнено (E1)+(E2) и результатом будет {как заявлено в цитате из стандарта} - адрес элемента массива.> ==> <что-то> с адресом элемента массива) И к этому <что-то> применим оператор *. К указателю он тоже применим, но их идентичность это не доказывает, без документального подтверждения. Свой пред пост дополнил.
  13. В стандарте пример подобный описан или какие-то комментарии разработчиков прилагаются? Мне непонятно, для массива определены особые правила вычисления выражений? По стандартным/общим правилам для варианта 2 будет сперва выполнено (E1)+(E2) и результатом будет (как заявлено в цитате из стандарта) - адрес элемента массива. При многомерном массиве - адрес массива <размерности меньшей на единицу, чем E2>. И уже когда к этому аргументу будет приплюсовываться число 5, то оно, проще говоря, должно быть (наиболее вероятно по вышеобозначенной инфе) индексом следующей (второй) размерности. Однако, если массив одномерный, то добавление числа к адресу, указывающему не на массив, истолкуется как добавление числа к указателю такого типа. И результат для одномерного массива будет действительно похож на <2. и 3. указатель на (E1+5)-й элемент массива E2.>
  14. Там немного обновил. Отвечу так: одной из важнейших целей правил является компактность и ясность программы. Если это требует маленького исключения/особенности, то ничего плохого в этом нет. Которые там и так есть. Это точно менее кошмарно, чем index[array] и мутный do {...} while (0) в макросе. Кроме того, предельная простота совсем не гарантирует однозначности (толкования). Подскажите тогда, какой тип будут иметь вполне корректные выражения: (при E2=array, E1=index, для одномерного и многомерного массивов) 1: ((E1)+(E2)) 2: ((E1)+(E2)+5) 3: ((E1)+5+(E2)) И, если можете, дайте определение/цитату или ссыль на упомянутый термин <типоразмер E1> в тексте <целое E2 должно быть умножено на типоразмер E1>. Это размер элемента ниже по иерархии от имени или размер элемента "на самом дне массива"? Или даже размер целого массива, на который указывает имя? (<типоразмер short> я буквально понимаю как 2 байта {например в Keil for ARMv4..ARMv7}. Типоразмер E5, где E5=структура, я склонен толковать как размер всей структуры, и по этой причине типоразмер E1 (ака массива) - как всего массива целиком. Для версии <имя массива в какой-то мере адрес> считать типоразмером E1 размер адреса - в обсуждаемом контексте вообще маловероятно).
  15. Это удобно для макросов, кои были задуманы сразу же на заре Си. Чтобы не требовалась (ужжасная) обёртка do...while(0). ps в пред пост вставил <непустого>, т.к. часто видел и даже сам раньше употреблял {}; в чём-то вроде while (...) {};