GetSmart

Ещё вопрос: Как закрыть свою тему? В кнопке <Опции темы>, расположенной в первом сообщении темы есть только Подписаться.

Уважаемая Администрация! Я могу читать подфорум Общение, но не могу писать в него. Почему? Пару месяцев назад (на предыдущем движке) запрета не было. Дублирую нерешённую проблему отсюда https://electronix.ru/forum/index.php?app=forums&module=forums&controller=topic&id=150156 сразу в заглавии этой ветки Но суть не в "почему", а как вернуть? Упд кнопка ЛС отсутствует или неизвестно куда спряталась.

Из даркнета исчезла? Вы почему вместо него ответили? _____________ Поставив себя на место красномалиновогвардейцев, понял, что надо в названии топика проблему обозначать.

По личной просьбе товарища Сталина. Отукда, кстати, такая информация? _______________ Прошло уже столько лет с момента той затеи с запретом участникам там высказываться. Ни у кого совесть с тех пор не проснулась? Половину участников форума затягивают в свои серо-зелёные сети схемы. ____________________________ Уважаемая Администрация! Обозначьтесь. Кнопку Эдит я искал несколько дней. А все остальные кнопки, в том числе ЛС, неизвестно куда подевались. Поэтому общаться остаётся публично.

Руку дадите на отсечение, если окажется не так? Я никогда не состоял в их партии "свой-чужой", но ссылки на свои посты в Общении могу привести. Посмотрите в Анекдотах в последних нескольких сообщениях. Пост=сообщение. Спасибо за фото. Выглядит примерно так, как до смены движка я видел форум. А сейчас всё кардинально изменилось. Кнопок нет. Кроме 1-2 вверху топика. Упд. Нашёл кнопку Редактировать. _________________ Остался вопрос к администрации: <как можно участнику писать в Общении?>

Не было. Могу привести ссылки на свои посты там. Не вижу кнопки сразу после отправки поста. Что-то тут не так. скрин бы увидеть, где эта кнопка расположена. Нет такой кнопки. Вообще под сообщениями никаких кнопок. Будем исходный код страницы изучать.

ПС. Предыдущий пост адресован участникам форума. + Вопрос к администрации: Я могу читать подфорум Общение, но не могу писать в него. Почему? Пару месяцев назад запрета не было.

Не могу найти кнопку "Edit" своего поста. Видел у других постов надпись "отредактировано" (владельцем). Значит она существует. Плиз, фото со стрелкой на кнопку выложите.

Картина напоминает групповое изнасилование. Добавил бы ещё 5 воскл.знаков к названию. В новой цыфровой реальности даже спрашивать не принято "Ребят, а не хотите ли новый движок?".

Алгоритмический нежданчик. Кусочно-линейная интерполяция 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); }

у продавца этот прибор назывался "Фотодиод -5012PD 5мм 940нм 35 гр." И перед созданией темы в инете я нашёл подходящий по названию только FYL-5012PD. Неужели есть другие варианты? Судя по многолетним покупкам у этого продавца, сомнений в качестве товара до сих пор не было. Кроме недорогих литиевых аккумов, которые у большинства продавцов несоответствуют надписям на них, часто раз в 10 меньше ёмкость.

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

ужжас нашего городка.... как зайти в личный кабинет? Где кнопки из шапки форума? Сейчас в самом низу страницы есть кнопки Язык и Тема. Нажатие на "Язык" сработало и сделало русский. Но нажатие на Тема-->Classic 4.5.2 написало "нет прав". Ни на какую тему нет прав. Подскажите, плиз, ссыль, как посещать форум в удобном старом формате страниц?

Как буд-то родился "кошмар на улице си" index[array]. Не прочитав всю кучу документов точно и не разберёшься. Полноценный перевод этого мутного термина я не знаю. В каких-то словарях компьютерных терминов его кастрируют до <индексация>. Но в общеупотребительном смысле это слово более многогранное. Со смыслами <одобрить>, <согласиться>. Пока (если лучше версию не увижу), наверное буду считать в Си "признать массивом и индексировать". Но у буржуев есть какой-то схожий термин "superscripting" (superscription-надпись, в общеупотребительном аглицком), которе вместе (теоретически наверно) могут как-то обозначать вариации индексаций "вглубь" (для массивов) или наружу (для указателей). Но с такими тонкостями толкования я пока не пересекался. Мутность такая же, как при переводе термина bitwise (complement), о котором когда-то спорили.

Это по шагам можете объяснить? Мне понятны варианты когда а[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) казался избыточным и работу с массивами НАДО БЫЛО организовывать через указатели и операторы +-, которым был непринципиален порядок разношёрстных операндов, мне самому любопытно, на какой развилке не туда свернули))) Упд. Именно такая историческая цепь прослеживается при чтении стандарта, когда оператор [] определяется текстовым примером через ранее определённые выражения.

В стандарте есть явные определения логики интерпретации применения [] к указателю на не массив и на не элемент массива? Никаких <почти всегда> оттуда не следует. Тем более, что что-то там преобразуется. Смысл написанного: <допускается писать такую конструкцию с такими-то вариантами, которая будет истолкована так...>

<(equivalently, a pointer> в данном контексте переводится как: <(равно{значно} {допустимо}, если это указатель> фигурными скобками выделил неявный смысл, который, при желании, можно не писать. В контексте этого абзаца <equivalently> не определяет, что везде в языке оба варианта равнозначны. Ещё, из этой цитаты не понять, какое действие вызывает оператор [], применимый к обычному указателю. Даже из всей главы <6.5.2.1 Array subscripting> непонятно, какое действие по стандарту выполняет применение [] к указателю на не массив (на не элемент массива). В её вступлении написали Далее везде "если это массив или указатель на начальный элемент массива то ...". PS но я мельком прочитал эти три абзаца. Прошу опровергнуть, если я неправ. Upd Учитывая вступительную цитату, с которой я только что ознакомился моё утверждение <В цитате было (буквально) сложение с именем массива. > правильнее заменить на <В цитате вполне допускалось сложение с именем массива.>

Определение дано на текстовом примере. После этого запрещать описание словами текстовых конструкций языка бессмысленно. Кроме того, в данном контексте <имя массива> более однозначно описывает <инструкцию> писателя кода. Если я напишу <массив>, то сразу подменю обсуждаемую <инструкцию> до многих вариантов текстового представления. Поэтому такие формулировки имеют право быть. Добавлять везде <в тексте> излишне, это неявно контекстно подразумевается. Скорее будет важно: до препроцессора или после, всякие области видимости, наложения имён переменных, макросов и прочего. По-умолчанию в таких формулировках разумно считать, что интерпретация текста по стандарту в том тексте выявит однозначно: имя массива, оператор сложения и целое число 5. И оператор сложения будет выполнен до всех иных операторов. Ерунда какая-то. 5*5=25

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

Туда же добавил <К указателю он тоже применим, но их идентичность это не доказывает, без документального подтверждения.> Сложение с именем массива: result = *(array+5) Сложение с указателем (на тип элементов из которых состоит массив): result = *(&array[0]+5) В цитате было (буквально) сложение с именем массива. Переводится как <Определением <subscript operator []> является то, что {неявно подразумевается: выражение} E1[E2] идентично {выражению} (*((E1)+(E2)))> Из чего следует, что в текстах разрешено использовать выражения со сложениями целых чисел с именами массивов. Без оговорок на размерность массивов. Upd: А ещё точнее: с такими же ограничениями как и для оператора []. Всё это не исключает при сложениях и такой возможности: при невозможности к аргументу применить оператор [], могут быть применены другие правила (если они определены), как то: трансформация аргумента в указатель и сложение с этим указателем. То, что в определении имя заключено в круглые скобки - сути не меняет, т.к. в этом выражении они являются оператором изменения очерёдности выполнения других операторов. (чорт его знает как скобки там дословно определили) И (array)[index] по смыслу исполнения равноценно array[index], когда внутри скобок нет операторов. {неявно подразумевая: в тексте после препроцессора} ------------- Дежа-вю

В вышеобсуждаемой цитата из стандарта явно указано, что такое выражение разрешено стандартом (сложение чисел с именем массива). При неуказании особых правил этого "изврата" применяются стандартные правила приоритетов и ассоциативности. Без оговорок и комментариев на уровне стандарта иначе это нельзя истолковать. Лучше даже уточнить: <Адрес> точнее будет заменить на <что-то> (неуказанное в стандарте), содержащее адрес, указывающий на вышеобозначенный тип. (пример: <сперва выполнено (E1)+(E2) и результатом будет {как заявлено в цитате из стандарта} - адрес элемента массива.> ==> <что-то> с адресом элемента массива) И к этому <что-то> применим оператор *. К указателю он тоже применим, но их идентичность это не доказывает, без документального подтверждения. Свой пред пост дополнил.

В стандарте пример подобный описан или какие-то комментарии разработчиков прилагаются? Мне непонятно, для массива определены особые правила вычисления выражений? По стандартным/общим правилам для варианта 2 будет сперва выполнено (E1)+(E2) и результатом будет (как заявлено в цитате из стандарта) - адрес элемента массива. При многомерном массиве - адрес массива <размерности меньшей на единицу, чем E2>. И уже когда к этому аргументу будет приплюсовываться число 5, то оно, проще говоря, должно быть (наиболее вероятно по вышеобозначенной инфе) индексом следующей (второй) размерности. Однако, если массив одномерный, то добавление числа к адресу, указывающему не на массив, истолкуется как добавление числа к указателю такого типа. И результат для одномерного массива будет действительно похож на <2. и 3. указатель на (E1+5)-й элемент массива E2.>

Там немного обновил. Отвечу так: одной из важнейших целей правил является компактность и ясность программы. Если это требует маленького исключения/особенности, то ничего плохого в этом нет. Которые там и так есть. Это точно менее кошмарно, чем 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 размер адреса - в обсуждаемом контексте вообще маловероятно).

Это удобно для макросов, кои были задуманы сразу же на заре Си. Чтобы не требовалась (ужжасная) обёртка do...while(0). ps в пред пост вставил <непустого>, т.к. часто видел и даже сам раньше употреблял {}; в чём-то вроде while (...) {};

Да, но тогда переформулируя, в большинстве ЯП высокого уровня того времени. ---------------- Как сказал один мой необкуренный коллега: Что-то у вас тут недоработано © Ещё, надеюсь, в стандарте кто-нибудь догадался однозначно указать, что в разделе кода точка с запятой после закрытия непустого блока (}) выражением не считается. (из-за которого предыдущие IF потеряют возможность иметь ELSE) Upd. И это, разумеется, не касается блока инициализатора. Ещё лучше так: ... указать, что точка с запятой, интерпретируемая первым оператором после закрытия непустого блока кода (закр. фиг. скобки), - выражением не считается. Отпуск на носу. Отложу раскопки на потом.