В HTML ссылки создаются при помощи тега <a>. Текст между открывающим тегом <a> и закрывающим тегом </a> становится «кликабельной» ссылкой.
Слишком громко сказано. У тэга "A" исторически сложилось два назначения
ссылка на "якорь" содержащийся на данной странице или на другую страницу, документ, файл... в таком случае элемент обязательно должен иметь атрибут "href".
собственно "якорь" на который может вести ссылка -- даже имя тэга "A" образовано от слова Anchor -- якорь. В этом случае элемент должен иметь атрибут "id" или "name" (а ссылка на якорь будет иметь вид "#somename").
В HTML5 появилось утверждение, что A-элемент без атрибута "href" выполняет роль "ссылки-заполнителя", но без помощи Javascript такая ссылка бесполезна (её не нажать до присвоения атрибута "href").
А использование A-тэга как "якоря" никуда не девалось. Хотя вместо него можно использовать любой элемент с атрибутом "id".
Значение атрибута href тега <a> должно содержать имя файла веб-страницы на которую делается ссылка...
Не обязательно. Атрибут href может ссылаться на якорь на текущей страницы с помощью атрибута href="#somename".
Вообще непонятно, зачем современный веб-сайт строить из множества дискретных файлов. Любой сложности сайт, веб-приложение, может быть построено из одной страницы, в которую интегрированы все необходимые ресурсы (картинки в base64, отдельные "страницы" как изначально не отображаемые DIV и т.п.) Разделение на дискретные файлы имеет смысл для постепенной загрузки (страница уже есть, а картинки только грузятся, например) в условиях ограниченного по полосе пропускания канала связи в основном. Если сайт большой. Типичный сайт для ардуино (управление чем-либо) прекрасно влезет в одну страницу. А нажатия кнопок в интерфейсе могут транслироваться в XHR-запросы.
Ещё дискретные файлы нужны если предполагается устаревшие варианты html, когда не доступны ни современные CSS-селекторы (они могут организовать "навигацию" по сайту состоящему из единой страницы), ни Javascript.
PS: вообще содержимое единственной страницы сайта лучше закешировать в web storage, чтоб в следующие разы загружалось быстрей. Ну разумеется с чем-то вроде номера версии. Браузер впрочем и сам кеширует, но есть нюансы. И загрузку этой страницы реализовать через маленький начальный загрузчик (который принимает через XHR или script-тэг большой файл и вставляет его в свой DOM), маленкий начальный файл браузер точно закеширует. И добавить web application manifest, тогда можно добиться, что относительно "тяжёлый" сайт запросто будет работать даже в оффлайне. Кнопки через XHR конечно нажиматься перестанут, но остальной функционал полезный для пользователей может и остаться. Так можно построить полнофункциональное веб-приложение для управления электронными приборами или вроде того.
Возможно речь о материалах, диэлектрическая проницаемость которых увеличивается при приложении к ним электрического поля (что пока только научные эксперименты). А в увеличении диэлектрической проницаемости конструкторы антенн очень даже заинтересованы. Правда речь не о террагерцах, а несколько о более низкочастотных диапазонах. Так как материалаы с высокой диэлектрической проницаемостью позволяют конструировать антенны меньших физических размеров, но обладающих примерно теми же свойствами (ввиду изменения скорости распространения волны, коэффициента укорочения, примерно равного корню квадратному из значения относительной диэлектрической проницаемости).
И манипулируя постоянным напряжением, приложенным к антенне, предполагаю, подразумевается подстройка резонансных свойств антенны, при сохраненни постоянных физических размеров. А так же может и изменяться и пространственная характеристика антенны (в англоязычной литературе -- beam forming). Сейчас это осуществляется преимущественно путём использования антенных решёток из многих антенн и сложением сигналов антенн (или наоборот разделения, если на передачу) через специальную "матрицу", где сигналы на единичные антенные элементы поступают с разной задержкой. Но ведь если открывается возможность изменять свойства самой антенны, это в чём-то удобно.
Алиас достаточно бесполезная штука в данном случае. Он позволяет лишь создать второй символ который будет ссылаться на тот же адрес, что другой глобальный символ, уже определённый в этой единице трансляции. Такого же можно достичь без алиаса, с помощью asm-вставки: декларируем extern-символ (не обязательно функцию), а в асме его определяем где и как нужно. И его даже локальным сделать можно в асме. Но все трюки не позволят заменить один символ на другой и невозможно сделать алиас для не определённого в текущей единице трансляции символа.
Можно ещё воспользоваться программой objcopy и у ней есть опция позволяющая переименовывать символы. Соответственно, это можно сделать в мейке после компиляции, но до линковки. Такое обычно нужно, если есть конфликт по символам с внешней библиотекой.
Ещё может помочь опция линкера -Wl,--wrap=symbol, кстати. Все ссылки на symbol будут вести в __wrap_symbol (который нужно определить самостоятельно), а старую функцию можно вызвать как __real_symbol. Такое обычно используется когда нужно переопределить библиотечную функцию или делаются mock-функции.
Ссылка позволит иметь "альтернативное имя" для функции. И может ссылаться на переопределённую функцию. Что тут непонятного?
Идея в том, что например, переопределённую функцию сложно сделать static в пределах каждой единицы компиляции (чтоб не попадало в глобальные символы). А такую ссылку/указатель в каждую единицу компиляции положить можно. И в отдельную единицу компиляции функцию на которую она ссылается.
Тогда после линковки в коде может остаться и оригинальная функция, и новая, и весь код который использовал оригинальную функцию теперь будет вызывать новую. Ну тут нужно сделать так, чтоб у компилятора не было неоднозначности с определеним использовать ссылку или оригинальную функцию. Если оригинальная функция в хедерах не видна -- нет проблем. Если видна, то только при включении проблемного хедера в конкретном .c файле сделать #define function __function__, например, чтоб старая функция не конфликтовала с именем ссылки или указателя. И всё.
Террагерцы на последней миле, если между базовыми станциями всего этого нет, ничего особенного потребителю не дадут. Они нужны только опсосу для работы с очень большим числом абонентов (в помещениях, метро, вокзалах, площадях). И никакого качественного скачка с террагерцами не будет, потому, что в атмосфере есть окна радиопрозрачности:
Террагигагерцовые линки будут уступать гигагерцовым линкам, у которых намного меньше рассеяние. Уступать на пару порядков.
И найдут применение "террагигагерцовые" диапазоны связи только разве что для связи внутри помещений (торговых центрах, метро и т.п. местах где очень много народу и сложно между всеми поделить ограниченный частотный диапазон), или на очень коротких расстояниях (площади, вокзалы).
Впрочем в статье примерно это же говориться. Просто хотелось подчеркнуть, что террагерцы на последней миле сами по себе ничего не дают. Чтоб потребитель ощутил преимущества, все каналы связи должны получить качественное улучшение, чего пока не предвидится. Что толку в 1Тбит/сек между абонентом и базовой станцией, если дальше от БС сигнал будет ограничен десятками МБит/сек в лучшем случае.
Если бы не одно но. Когда требуется взять адрес функции, то её имя нужно указывать без скобок! И если имя этой функции требуется переопределять с помощью макропроцессора, то тут вариант только один, определять нужно только одно имя без скобок и каких либо аргументов.
Имя функции -- это символ с определённым типом. Никаких ограничений на счёт скобок для него нет. Может быть сколько угодно круглых скобок...
Как не используя макросы препроцессора С/С++ можно переопределить имя функции как при её вызове, так и для операции взятия адреса функции?
Операция взятия адреса для функции скорей не нужна, функция автоматически превращается в указатель на функцию в C/C++...
Как-как. Если в C++, то можно с использованием ссылки на другую функцию. Ссылки с нужным именем.
Если в голом-C, то можно с использованием константного указателя на функцию.
Юнит-тест системы часто пользуются такими методами для mocking'а функций.
PS: если нужно что-то сделать с аргументами, то сделать это в своей промежуточной функции. Если что-то сделать с аргументами нужно в месте вызова, то очевидно, это не выполнимо без макроса (или, может быть, но не всегда, шаблона в C++). И если нужен именно макрос то задача скорей решения не имеет.
PPS: сформулируйте задачу точнее. А то может в упор не видно очевидного решения.
А на чём их ещё приносить, если в виндах, да и в линуксе на отдельных чипсетах, всё ещё как-то не очень хорошо с IOMMU. Да и не только...
Дискета содержит только данные. Конечно их можно проинтерпретировать неправильно и запустить вирус. Но можно так и не делать.
А "флешка" содержит собственное программное обеспечение. Которое достаточно плотно взаимодействует с контроллером USB-шины в чипсете (а тот с железом) и с операционной системой. И чем это кончится -- никто не знает. И бывает кончается не очень. Прецеденты были.
Хуже того, "флешка" может прикинуться любым устройством. Хоть мышкой. Хоть клавиатурой. И быстренько с клавиатуры вколотить shell-код. Так быстро, что не успеешь заметить, как на экране появилось какое-то окошко и пропало. И всё.
Как у нас дела с аппаратными фаерволами для флешек? И что делать сотрудникам банка?
У дискеты меньше точек отказа. У flash-накопителя очень большой промежуточный стек протоколов, каналов связи и устройств промежуточного хранения, где может произойти искажение данных.
Существует множетство форматов дискет, а не только распространённые на компьютере IBM-PC с файловой системой FAT. И тут многие покупные эмуляторы могут не подойти. Потому, что у старых компьютеров и файловые системы свои, и форматы дискет свои, другие. Другой размер сектора, другое количество секторов. Более того, часто применяются всякие трюки, вроде записи данных между секторов. Эмулировать такие дискеты очень не просто. Есть любительские эмуляторы действительно достаточно хорошие, но это отнюдь не массовый рынок, не то, что продаётся на каждом углу.
И разработка такого эмулятора -- это отнюдь не поделка на ардуино. Это часто многолетний труд.
Да. Такие дискеты нужны для уже антиквартных компьютеров и небольшой спрос есть. В основном нужны 3.5" и 5.25" на 720кБ. На 1.2МБ -- не нужны (там дисковод другой, их можно переделать на 720кБ, но будут плохо работать), на 1.44" тоже не очень желательны (в них можно то ли заклеить, то ли просверлить отверстие и будет 720кБ, но работать будут хуже).
Между дискетой и предлагаемым переходом на flash-память в виде SD-карт и эмуляторов есть большая разница, которую многие не видят. Надёжность.
Хоть и пишут, что "дискеты не читаются", так же полно случаев когда дискеты читаются спустя несколько десятилетий: чаще не читаются некачественные дискеты которыми был завален рынок перед их пропажей с рынка, и часто проблема вообще не в дискете, а в разъюстированном дисководе с грязной головкой (когда-то были специальные чистящие дискеты...) Или вовсе может встретиться дисковод который портит дискеты -- потому и не читаются. Во многих дешевых 3.5" дисководах головка с грохотом падает на дискету в момент вставки дискеты и физически царапает верхний магнитный слой. Можно просто пальцем придерживать кнопку... В старых 5.25 аналогичная проблема. Где-то головка опускается плавно и рычагом (который спереди крутить надо), где-то электромагнитом, резко и с грохотом. Там возможно изначально якорь магнита находился в специальной вязкой жидкости, чтоб без грохота и не царапать дискету, но та высохла ещё 15 лет назад.
У дискеты вообще причин, по которым она может отказать -- меньше, чем у любого электронного изделия. Размагнитить её можно только в очень сильных магнитных полях, которые редко где вообще встречаются. Старению подвержено покрытие несущее магнитный слой, но при соблюдении технологий на производстве оно живёт десятилетиями. Дискета в основном может быть повреждена механически.
У SD-карты и других накопителей во-первых постоянно теряется заряд, наличием которого в затворе транзистров кодируется информация. И через несколько лет их будет просто не прочитать. На хабре была статья на эту тему: https://habr.com/ru/post/512886/ Для архивного хранения SD-карты уже не очень подходят. Во-вторых SD-карта в первую очередь просто очень сложное изделие, и из чего возникает масса возможных причин отказа: деградация электронной схемы вызванная химическими процессами вследствии каких-то проблем на производстве (случаи, когда микросхемы определённой фирмы выпущенные в определённый период времени массово "умирают" в течении пары лет -- достаточно распространённый). Статическое электричество: достаточно человеку схватиться за карту неудачно лежащую на проводящей поверхности с сильно отличным потенциалом. Гамма-излучение или тяжелые заряженные частицы могут попросту "стереть" микросхему памяти. В том числе космическое излучение, вплоть до солнечной вспышки. Да просто попадание воды, тем более морской, запросто убьёт любой электронный носитель, если вовремя не высушить. Достаточно даже регулярных циклов заморозки-оттаивания с появлением конденсата. Или даже падения на твёрдый пол под неудачным углом.
Наконец программная надёжность. У дискеты нет никакого своего программного обеспечения, там записано то что записано и контрольная сумма, ничего больше. У SD-карты есть свой контроллер который управляет и взаимодействием с компьютером, и тем как данные записываются в физическую память, и как обрабатываются ошибки. Потому, что в flash-памяти всегда полно ошибок и они вынуждены корректироваться, контроллер вынужден исключать из использования неисправные ячейки памяти и использовать другие. С программной надёжностью у многих контроллеров не всё хорошо, и часто даже откровенно плохо. Неисправные SD-карты или USB-флешки все видели. Причина там часто в программных сбоях в контроллере, а не отнюдь какая-то физическая неисправность. Многие "флешки" даже могут быть восстановлены специальным ПО путём полного переформатирования. И что характерно, при этом теряется сразу вся информация. У дискеты обычно не читаются отдельные сектора. И на дискету можно записать RAR-архив с избыточностью, прочитать с игнорированием ошибок и восстановить все данные, например... Многие электронны носители "умирают" (по внутренним программным причинам) при отключении питания не вовремя. На дискете это лишь даёт один нечитаемый сектор (который писался во время отключения питания). Почему собственно FAT таблица записывается два раза.
И ещё один важныю нюанс: контрольные суммы. С ними у электронных носителей всё откровенно плохо. Вообще систему хранения данных собрать на компонентах купленных в компьютерном магазине откровенно сложно. В чём дело: все электронные носители как правило не обеспечиваютсквозную контрольную сумму, хотя на каждой стадии она как бы есть. При хранении данных на SD-карте или флешке -- данные защищены каким-то достаточно надёжным ECC-кодом, или BCH-кодами. Но код этот проверяет только контроллер (и пока данные лежали в его оперативной памяти, они могли немного поменяться). Потом через интерфейс данные выдаются с CRC-кодом (который может и вовсе не использоваться, тогда данные могут искажаться и интерфейсом). Потом в компьютере, где-то в USB, в SATA, повторяется аналогичная история. Везде есть свои контрольные суммы и промежуточные узлы обрабатывающие и хранящие данные. В памяти которых данные могут искажаться. В итоге ситуация, когда с накопителя что-то читается вроде без ошибок но данные искажены -- не редкость. А потом оно обрабатывается и пишется обратно. И ошибка распространяется.
В Linux появился модуль dm-integrity предназначенный решить эту проблему, но он работает откровенно плохо, медленно. Некоторые файловые системы, вроде ZFS или Btrfs самостоятельно контролируют целостность данных. Но даже если они обнаружат ошибку, что делать? Если файловая система на RAID5, например, ошибка могла уже распространиться и на другие данные оказавшиеся в том же блоке. Нет, если raid организован самой файловой системой, а не используется dm-raid, то проблема решается. Или её решает dm-integrity, но ценой огромного замедления. Распространённых файловых систем это всё не касается (EXT3/4, NTFS, FAT...) Там ничего не предусмотрено.
Преимущество дискеты -- в простоте. Там три компонента: процессор компьютера, контроллер дисковода (я не говорю об USB-дисководах -- там появляются все те же проблемы описанные выше!), и сама дискета. И данные считываемые с дискеты поступают от дисковода в необработанной форме вместе с контрольным кодом в контроллер дисковода. Где он проверяется и принимается решение о том сектор прочитан правильно или нет. Контроллер дисковода подключен к процессору по внутренней шине, где предполагаем ошибок нет (иначе процессор не будет правильно исполнять программы и всё развалится очень быстро). Нет промежуточных узлов способных искажать читаемые данные. В некоторых компьютерах вообще всю работу по чтению дискеты выполнял процессор (Commodore Amiga), так что там данные поменяться по дороге вообще нигде не могли.
Конечно, целостность данных может проверяться и на уровне приложения, или на уровне базы данных... Но в целом жизнено критичную информацию дискете доверить проще. Или лазерному диску. Там нет встроенного контроллера и их, в конце концов, можно прочитать на разных дисководах. Отказ контроллера не ведёт к невзозможности чтения данных. Контроллер не может внести свои ошибки. Но да, интефейс с CD/DVD/BlueRay-приводом тоже имеет проблему с не-сквозными контрольными суммами. И следовало бы использовать какой-то архиватор, вроде Parchive (par) для контроля целостности данных...
Дискеты всё же наверное должны вымереть. Лазерным дискам они действительно -- не конкурент. Но с flash-накопителями кое в чём ещё могут посоревноваться.
Проблема только в том, что дискета может проваляться 20 лет, а потом быть использована. И даже прочитается. Если качественная и не "осыпалась". А поделка с AliExpress может выйти из строя через 2 года и в очень неудобный момент времени.
Куда важней, что там будет с компьютерами через 10-20 лет:
в текущей политической ситуации их может просто не стать...
одно поколение компьютеров постоянно сменяет следующее, нужно постоянно менять носители, форматы данных, программное обеспечение (и поддержка этого всего для библиотеки -- стоит денег).
Автор явно перегибает палку. Где-то описанное автором есть в каких-то частях, но не настолько, насколько описано. За часы отчитываться так или иначе нужно везде, а в случае аутсорса оно просто попадает в условную "бухгалтерию" чтоб заказчик вообще понимал на что тратятся деньги. Там у менеджеров появляется таблица в экселе, где есть (не)запланированные таски и ресурсы списанные на эти таски. И заказчик хочет её видеть.
Тотальной секретности может и не быть, и в большой корпорации может быть куда более тотальная секретность, вот прямо как описано, а в аутсорсе всё что попросишь тебе дадут, если смогут. Бывает по-разному. И жуткий легаси может быть в корпорации. И непрерывная текучка кадров бывает в корпорации.
В общем аутсорс совершенно зря поливается грязью. Бывает плохо, а бывает и не совсем плохо, и бывает даже не плохо. Зависит от организаци, от ситуации, от заказчика, от коллег в конце концов. Аутсорс бывет разный. В целом какой он, наверное, должно быть видно когда устраиваешься и когда тебе рассказывают о продукте. Если рассказать толком ничего не могут и мутят -- ничего хорошего не светит. Если есть какой-то осязаемый продукт с жизненной историей, может там и полные подвалы страшного легаси, но в остальном не так страшно. Наконец, за легаси в конце концов платят зарплату (ибо заказчику уже деваться некуда). А за модные технологии, где толпа желающих студентов, могут и не платить.
Когда-нибудь попробую, но сдаётся они ж не просто так звонят с разных номеров и вполне возможно зарегистрированных на частных лиц. И будут аппелировать к тому, что сами мол не звонят, мол всё это проделки этих самых физ. лиц.
Абоненту, очевидно, удобней пользоваться приложением, чем запоминать какие-то шифровки USSD-кодов или заходить на сайт, пароль от которого давно потерян и требует каждый раз посылать СМС.
И в приложении очевидно есть возможности отсутствующие в других приложениях. С тем же Мультифоном кроме мегафоновских приложений работает нормально мало кто (на смартфоне, а не на ПК или не стационарный SIP-телефон).
Раздача интернета в Yota -- платная. Или по крайней мере была какое-то время назад. Или нужен полноценный роутер и настройки TTL чтобы обмануть. Более того, там в договоре описывется, что отдельные виды траффика ограничиваются. Нарывался на глюки шейпера Йоты: https://www.linux.org.ru/forum/desktop/16190798 Исправить удалось только сменой операционной системы. Тариф был "для роутера", т.е. с возможностью раздачи. Но траффик именно для этого компьютера, именно с этой ОС ограничивался. Что там могло быть не так, не представляю, заголовки IP-пакетов разве что.
С 3G я не прав. Видимо, путаю с тарифами только для интернета (роутера), у Yota же -- там только 4G. В отличии от того же Мегафона, где и 3G, и 4G. Очень часто бывают места, где 3G добивает, а 4G уже нет. Или в плохих погодных условиях. Yota с симкой для роутера становится бесполезным, а мегафон с заметным пингом, но работает. Понятно, дело не в самой Yota, тем более что у ней мегафоновская же сеть, а в технологии передачи данных. 4G плохо работает в плохую погоду (ливень) и на больших расстояниях.
Сейчас есть зарядные устройства с двумя портами USB-C. Что, интересно, происходит при подключении туда двух разных телефонов? Порты совершенно точно не независимые и что-то происходит. Т.к. у одного телефона super fast charge превращается в просто charge за 8 часов.
Слишком громко сказано. У тэга "A" исторически сложилось два назначения
ссылка на "якорь" содержащийся на данной странице или на другую страницу, документ, файл... в таком случае элемент обязательно должен иметь атрибут "href".
собственно "якорь" на который может вести ссылка -- даже имя тэга "A" образовано от слова Anchor -- якорь. В этом случае элемент должен иметь атрибут "id" или "name" (а ссылка на якорь будет иметь вид "#somename").
В HTML5 появилось утверждение, что A-элемент без атрибута "href" выполняет роль "ссылки-заполнителя", но без помощи Javascript такая ссылка бесполезна (её не нажать до присвоения атрибута "href").
А использование A-тэга как "якоря" никуда не девалось. Хотя вместо него можно использовать любой элемент с атрибутом "id".
Не обязательно. Атрибут href может ссылаться на якорь на текущей страницы с помощью атрибута href="#somename".
Вообще непонятно, зачем современный веб-сайт строить из множества дискретных файлов. Любой сложности сайт, веб-приложение, может быть построено из одной страницы, в которую интегрированы все необходимые ресурсы (картинки в base64, отдельные "страницы" как изначально не отображаемые DIV и т.п.) Разделение на дискретные файлы имеет смысл для постепенной загрузки (страница уже есть, а картинки только грузятся, например) в условиях ограниченного по полосе пропускания канала связи в основном. Если сайт большой. Типичный сайт для ардуино (управление чем-либо) прекрасно влезет в одну страницу. А нажатия кнопок в интерфейсе могут транслироваться в XHR-запросы.
Ещё дискретные файлы нужны если предполагается устаревшие варианты html, когда не доступны ни современные CSS-селекторы (они могут организовать "навигацию" по сайту состоящему из единой страницы), ни Javascript.
PS: вообще содержимое единственной страницы сайта лучше закешировать в web storage, чтоб в следующие разы загружалось быстрей. Ну разумеется с чем-то вроде номера версии. Браузер впрочем и сам кеширует, но есть нюансы. И загрузку этой страницы реализовать через маленький начальный загрузчик (который принимает через XHR или script-тэг большой файл и вставляет его в свой DOM), маленкий начальный файл браузер точно закеширует. И добавить web application manifest, тогда можно добиться, что относительно "тяжёлый" сайт запросто будет работать даже в оффлайне. Кнопки через XHR конечно нажиматься перестанут, но остальной функционал полезный для пользователей может и остаться. Так можно построить полнофункциональное веб-приложение для управления электронными приборами или вроде того.
Возможно речь о материалах, диэлектрическая проницаемость которых увеличивается при приложении к ним электрического поля (что пока только научные эксперименты). А в увеличении диэлектрической проницаемости конструкторы антенн очень даже заинтересованы. Правда речь не о террагерцах, а несколько о более низкочастотных диапазонах. Так как материалаы с высокой диэлектрической проницаемостью позволяют конструировать антенны меньших физических размеров, но обладающих примерно теми же свойствами (ввиду изменения скорости распространения волны, коэффициента укорочения, примерно равного корню квадратному из значения относительной диэлектрической проницаемости).
И манипулируя постоянным напряжением, приложенным к антенне, предполагаю, подразумевается подстройка резонансных свойств антенны, при сохраненни постоянных физических размеров. А так же может и изменяться и пространственная характеристика антенны (в англоязычной литературе -- beam forming). Сейчас это осуществляется преимущественно путём использования антенных решёток из многих антенн и сложением сигналов антенн (или наоборот разделения, если на передачу) через специальную "матрицу", где сигналы на единичные антенные элементы поступают с разной задержкой. Но ведь если открывается возможность изменять свойства самой антенны, это в чём-то удобно.
Алиас достаточно бесполезная штука в данном случае. Он позволяет лишь создать второй символ который будет ссылаться на тот же адрес, что другой глобальный символ, уже определённый в этой единице трансляции. Такого же можно достичь без алиаса, с помощью asm-вставки: декларируем extern-символ (не обязательно функцию), а в асме его определяем где и как нужно. И его даже локальным сделать можно в асме. Но все трюки не позволят заменить один символ на другой и невозможно сделать алиас для не определённого в текущей единице трансляции символа.
Можно ещё воспользоваться программой objcopy и у ней есть опция позволяющая переименовывать символы. Соответственно, это можно сделать в мейке после компиляции, но до линковки. Такое обычно нужно, если есть конфликт по символам с внешней библиотекой.
Ещё может помочь опция линкера -Wl,--wrap=symbol, кстати. Все ссылки на symbol будут вести в __wrap_symbol (который нужно определить самостоятельно), а старую функцию можно вызвать как __real_symbol. Такое обычно используется когда нужно переопределить библиотечную функцию или делаются mock-функции.
Ссылка позволит иметь "альтернативное имя" для функции. И может ссылаться на переопределённую функцию. Что тут непонятного?
Идея в том, что например, переопределённую функцию сложно сделать static в пределах каждой единицы компиляции (чтоб не попадало в глобальные символы). А такую ссылку/указатель в каждую единицу компиляции положить можно. И в отдельную единицу компиляции функцию на которую она ссылается.
Тогда после линковки в коде может остаться и оригинальная функция, и новая, и весь код который использовал оригинальную функцию теперь будет вызывать новую. Ну тут нужно сделать так, чтоб у компилятора не было неоднозначности с определеним использовать ссылку или оригинальную функцию. Если оригинальная функция в хедерах не видна -- нет проблем. Если видна, то только при включении проблемного хедера в конкретном .c файле сделать #define function __function__, например, чтоб старая функция не конфликтовала с именем ссылки или указателя. И всё.
Вдогонку, о террагерцах:
Террагерцы на последней миле, если между базовыми станциями всего этого нет, ничего особенного потребителю не дадут. Они нужны только опсосу для работы с очень большим числом абонентов (в помещениях, метро, вокзалах, площадях). И никакого качественного скачка с террагерцами не будет, потому, что в атмосфере есть окна радиопрозрачности:
И как общее правило, чем выше частота -- тем сильней поглощение в атмосфере. Особенно в условиях сильного дождя (https://433175.ru/articles/3630-okna-radioprozrachnosti-dozhdi-i-svch-kvch-radiotehnologii.html).
Террагигагерцовые линки будут уступать гигагерцовым линкам, у которых намного меньше рассеяние. Уступать на пару порядков.
И найдут применение "террагигагерцовые" диапазоны связи только разве что для связи внутри помещений (торговых центрах, метро и т.п. местах где очень много народу и сложно между всеми поделить ограниченный частотный диапазон), или на очень коротких расстояниях (площади, вокзалы).
Впрочем в статье примерно это же говориться. Просто хотелось подчеркнуть, что террагерцы на последней миле сами по себе ничего не дают. Чтоб потребитель ощутил преимущества, все каналы связи должны получить качественное улучшение, чего пока не предвидится. Что толку в 1Тбит/сек между абонентом и базовой станцией, если дальше от БС сигнал будет ограничен десятками МБит/сек в лучшем случае.
Окончание статьи явно оборванное: "рассмотрим некоторые из них". Некоторые -- это какие?
Имя функции -- это символ с определённым типом. Никаких ограничений на счёт скобок для него нет. Может быть сколько угодно круглых скобок...
Операция взятия адреса для функции скорей не нужна, функция автоматически превращается в указатель на функцию в C/C++...
Как-как. Если в C++, то можно с использованием ссылки на другую функцию. Ссылки с нужным именем.
Если в голом-C, то можно с использованием константного указателя на функцию.
Юнит-тест системы часто пользуются такими методами для mocking'а функций.
PS: если нужно что-то сделать с аргументами, то сделать это в своей промежуточной функции. Если что-то сделать с аргументами нужно в месте вызова, то очевидно, это не выполнимо без макроса (или, может быть, но не всегда, шаблона в C++). И если нужен именно макрос то задача скорей решения не имеет.
PPS: сформулируйте задачу точнее. А то может в упор не видно очевидного решения.
У меня нет ни одной сколько-нибудь старой флешки. Все померли.
А на чём их ещё приносить, если в виндах, да и в линуксе на отдельных чипсетах, всё ещё как-то не очень хорошо с IOMMU. Да и не только...
Дискета содержит только данные. Конечно их можно проинтерпретировать неправильно и запустить вирус. Но можно так и не делать.
А "флешка" содержит собственное программное обеспечение. Которое достаточно плотно взаимодействует с контроллером USB-шины в чипсете (а тот с железом) и с операционной системой. И чем это кончится -- никто не знает. И бывает кончается не очень. Прецеденты были.
Хуже того, "флешка" может прикинуться любым устройством. Хоть мышкой. Хоть клавиатурой. И быстренько с клавиатуры вколотить shell-код. Так быстро, что не успеешь заметить, как на экране появилось какое-то окошко и пропало. И всё.
Как у нас дела с аппаратными фаерволами для флешек? И что делать сотрудникам банка?
У дискеты меньше точек отказа. У flash-накопителя очень большой промежуточный стек протоколов, каналов связи и устройств промежуточного хранения, где может произойти искажение данных.
Существует множетство форматов дискет, а не только распространённые на компьютере IBM-PC с файловой системой FAT. И тут многие покупные эмуляторы могут не подойти. Потому, что у старых компьютеров и файловые системы свои, и форматы дискет свои, другие. Другой размер сектора, другое количество секторов. Более того, часто применяются всякие трюки, вроде записи данных между секторов. Эмулировать такие дискеты очень не просто. Есть любительские эмуляторы действительно достаточно хорошие, но это отнюдь не массовый рынок, не то, что продаётся на каждом углу.
И разработка такого эмулятора -- это отнюдь не поделка на ардуино. Это часто многолетний труд.
Да. Такие дискеты нужны для уже антиквартных компьютеров и небольшой спрос есть. В основном нужны 3.5" и 5.25" на 720кБ. На 1.2МБ -- не нужны (там дисковод другой, их можно переделать на 720кБ, но будут плохо работать), на 1.44" тоже не очень желательны (в них можно то ли заклеить, то ли просверлить отверстие и будет 720кБ, но работать будут хуже).
Между дискетой и предлагаемым переходом на flash-память в виде SD-карт и эмуляторов есть большая разница, которую многие не видят. Надёжность.
Хоть и пишут, что "дискеты не читаются", так же полно случаев когда дискеты читаются спустя несколько десятилетий: чаще не читаются некачественные дискеты которыми был завален рынок перед их пропажей с рынка, и часто проблема вообще не в дискете, а в разъюстированном дисководе с грязной головкой (когда-то были специальные чистящие дискеты...) Или вовсе может встретиться дисковод который портит дискеты -- потому и не читаются. Во многих дешевых 3.5" дисководах головка с грохотом падает на дискету в момент вставки дискеты и физически царапает верхний магнитный слой. Можно просто пальцем придерживать кнопку... В старых 5.25 аналогичная проблема. Где-то головка опускается плавно и рычагом (который спереди крутить надо), где-то электромагнитом, резко и с грохотом. Там возможно изначально якорь магнита находился в специальной вязкой жидкости, чтоб без грохота и не царапать дискету, но та высохла ещё 15 лет назад.
У дискеты вообще причин, по которым она может отказать -- меньше, чем у любого электронного изделия. Размагнитить её можно только в очень сильных магнитных полях, которые редко где вообще встречаются. Старению подвержено покрытие несущее магнитный слой, но при соблюдении технологий на производстве оно живёт десятилетиями. Дискета в основном может быть повреждена механически.
У SD-карты и других накопителей во-первых постоянно теряется заряд, наличием которого в затворе транзистров кодируется информация. И через несколько лет их будет просто не прочитать. На хабре была статья на эту тему: https://habr.com/ru/post/512886/ Для архивного хранения SD-карты уже не очень подходят. Во-вторых SD-карта в первую очередь просто очень сложное изделие, и из чего возникает масса возможных причин отказа: деградация электронной схемы вызванная химическими процессами вследствии каких-то проблем на производстве (случаи, когда микросхемы определённой фирмы выпущенные в определённый период времени массово "умирают" в течении пары лет -- достаточно распространённый). Статическое электричество: достаточно человеку схватиться за карту неудачно лежащую на проводящей поверхности с сильно отличным потенциалом. Гамма-излучение или тяжелые заряженные частицы могут попросту "стереть" микросхему памяти. В том числе космическое излучение, вплоть до солнечной вспышки. Да просто попадание воды, тем более морской, запросто убьёт любой электронный носитель, если вовремя не высушить. Достаточно даже регулярных циклов заморозки-оттаивания с появлением конденсата. Или даже падения на твёрдый пол под неудачным углом.
Наконец программная надёжность. У дискеты нет никакого своего программного обеспечения, там записано то что записано и контрольная сумма, ничего больше. У SD-карты есть свой контроллер который управляет и взаимодействием с компьютером, и тем как данные записываются в физическую память, и как обрабатываются ошибки. Потому, что в flash-памяти всегда полно ошибок и они вынуждены корректироваться, контроллер вынужден исключать из использования неисправные ячейки памяти и использовать другие. С программной надёжностью у многих контроллеров не всё хорошо, и часто даже откровенно плохо. Неисправные SD-карты или USB-флешки все видели. Причина там часто в программных сбоях в контроллере, а не отнюдь какая-то физическая неисправность. Многие "флешки" даже могут быть восстановлены специальным ПО путём полного переформатирования. И что характерно, при этом теряется сразу вся информация. У дискеты обычно не читаются отдельные сектора. И на дискету можно записать RAR-архив с избыточностью, прочитать с игнорированием ошибок и восстановить все данные, например... Многие электронны носители "умирают" (по внутренним программным причинам) при отключении питания не вовремя. На дискете это лишь даёт один нечитаемый сектор (который писался во время отключения питания). Почему собственно FAT таблица записывается два раза.
И ещё один важныю нюанс: контрольные суммы. С ними у электронных носителей всё откровенно плохо. Вообще систему хранения данных собрать на компонентах купленных в компьютерном магазине откровенно сложно. В чём дело: все электронные носители как правило не обеспечивают сквозную контрольную сумму, хотя на каждой стадии она как бы есть. При хранении данных на SD-карте или флешке -- данные защищены каким-то достаточно надёжным ECC-кодом, или BCH-кодами. Но код этот проверяет только контроллер (и пока данные лежали в его оперативной памяти, они могли немного поменяться). Потом через интерфейс данные выдаются с CRC-кодом (который может и вовсе не использоваться, тогда данные могут искажаться и интерфейсом). Потом в компьютере, где-то в USB, в SATA, повторяется аналогичная история. Везде есть свои контрольные суммы и промежуточные узлы обрабатывающие и хранящие данные. В памяти которых данные могут искажаться. В итоге ситуация, когда с накопителя что-то читается вроде без ошибок но данные искажены -- не редкость. А потом оно обрабатывается и пишется обратно. И ошибка распространяется.
В Linux появился модуль dm-integrity предназначенный решить эту проблему, но он работает откровенно плохо, медленно. Некоторые файловые системы, вроде ZFS или Btrfs самостоятельно контролируют целостность данных. Но даже если они обнаружат ошибку, что делать? Если файловая система на RAID5, например, ошибка могла уже распространиться и на другие данные оказавшиеся в том же блоке. Нет, если raid организован самой файловой системой, а не используется dm-raid, то проблема решается. Или её решает dm-integrity, но ценой огромного замедления. Распространённых файловых систем это всё не касается (EXT3/4, NTFS, FAT...) Там ничего не предусмотрено.
Преимущество дискеты -- в простоте. Там три компонента: процессор компьютера, контроллер дисковода (я не говорю об USB-дисководах -- там появляются все те же проблемы описанные выше!), и сама дискета. И данные считываемые с дискеты поступают от дисковода в необработанной форме вместе с контрольным кодом в контроллер дисковода. Где он проверяется и принимается решение о том сектор прочитан правильно или нет. Контроллер дисковода подключен к процессору по внутренней шине, где предполагаем ошибок нет (иначе процессор не будет правильно исполнять программы и всё развалится очень быстро). Нет промежуточных узлов способных искажать читаемые данные. В некоторых компьютерах вообще всю работу по чтению дискеты выполнял процессор (Commodore Amiga), так что там данные поменяться по дороге вообще нигде не могли.
Конечно, целостность данных может проверяться и на уровне приложения, или на уровне базы данных... Но в целом жизнено критичную информацию дискете доверить проще. Или лазерному диску. Там нет встроенного контроллера и их, в конце концов, можно прочитать на разных дисководах. Отказ контроллера не ведёт к невзозможности чтения данных. Контроллер не может внести свои ошибки. Но да, интефейс с CD/DVD/BlueRay-приводом тоже имеет проблему с не-сквозными контрольными суммами. И следовало бы использовать какой-то архиватор, вроде Parchive (par) для контроля целостности данных...
Дискеты всё же наверное должны вымереть. Лазерным дискам они действительно -- не конкурент. Но с flash-накопителями кое в чём ещё могут посоревноваться.
Проблема только в том, что дискета может проваляться 20 лет, а потом быть использована. И даже прочитается. Если качественная и не "осыпалась". А поделка с AliExpress может выйти из строя через 2 года и в очень неудобный момент времени.
Куда важней, что там будет с компьютерами через 10-20 лет:
в текущей политической ситуации их может просто не стать...
одно поколение компьютеров постоянно сменяет следующее, нужно постоянно менять носители, форматы данных, программное обеспечение (и поддержка этого всего для библиотеки -- стоит денег).
Автор явно перегибает палку. Где-то описанное автором есть в каких-то частях, но не настолько, насколько описано. За часы отчитываться так или иначе нужно везде, а в случае аутсорса оно просто попадает в условную "бухгалтерию" чтоб заказчик вообще понимал на что тратятся деньги. Там у менеджеров появляется таблица в экселе, где есть (не)запланированные таски и ресурсы списанные на эти таски. И заказчик хочет её видеть.
Тотальной секретности может и не быть, и в большой корпорации может быть куда более тотальная секретность, вот прямо как описано, а в аутсорсе всё что попросишь тебе дадут, если смогут. Бывает по-разному. И жуткий легаси может быть в корпорации. И непрерывная текучка кадров бывает в корпорации.
В общем аутсорс совершенно зря поливается грязью. Бывает плохо, а бывает и не совсем плохо, и бывает даже не плохо. Зависит от организаци, от ситуации, от заказчика, от коллег в конце концов. Аутсорс бывет разный. В целом какой он, наверное, должно быть видно когда устраиваешься и когда тебе рассказывают о продукте. Если рассказать толком ничего не могут и мутят -- ничего хорошего не светит. Если есть какой-то осязаемый продукт с жизненной историей, может там и полные подвалы страшного легаси, но в остальном не так страшно. Наконец, за легаси в конце концов платят зарплату (ибо заказчику уже деваться некуда). А за модные технологии, где толпа желающих студентов, могут и не платить.
Когда-нибудь попробую, но сдаётся они ж не просто так звонят с разных номеров и вполне возможно зарегистрированных на частных лиц. И будут аппелировать к тому, что сами мол не звонят, мол всё это проделки этих самых физ. лиц.
Абоненту, очевидно, удобней пользоваться приложением, чем запоминать какие-то шифровки USSD-кодов или заходить на сайт, пароль от которого давно потерян и требует каждый раз посылать СМС.
И в приложении очевидно есть возможности отсутствующие в других приложениях. С тем же Мультифоном кроме мегафоновских приложений работает нормально мало кто (на смартфоне, а не на ПК или не стационарный SIP-телефон).
Раздача интернета в Yota -- платная. Или по крайней мере была какое-то время назад. Или нужен полноценный роутер и настройки TTL чтобы обмануть. Более того, там в договоре описывется, что отдельные виды траффика ограничиваются. Нарывался на глюки шейпера Йоты: https://www.linux.org.ru/forum/desktop/16190798 Исправить удалось только сменой операционной системы. Тариф был "для роутера", т.е. с возможностью раздачи. Но траффик именно для этого компьютера, именно с этой ОС ограничивался. Что там могло быть не так, не представляю, заголовки IP-пакетов разве что.
С 3G я не прав. Видимо, путаю с тарифами только для интернета (роутера), у Yota же -- там только 4G. В отличии от того же Мегафона, где и 3G, и 4G. Очень часто бывают места, где 3G добивает, а 4G уже нет. Или в плохих погодных условиях. Yota с симкой для роутера становится бесполезным, а мегафон с заметным пингом, но работает. Понятно, дело не в самой Yota, тем более что у ней мегафоновская же сеть, а в технологии передачи данных. 4G плохо работает в плохую погоду (ливень) и на больших расстояниях.
Сейчас есть зарядные устройства с двумя портами USB-C. Что, интересно, происходит при подключении туда двух разных телефонов? Порты совершенно точно не независимые и что-то происходит. Т.к. у одного телефона super fast charge превращается в просто charge за 8 часов.