VoidVolker

В контроллере COM-порта несколько регистров. Запись в них определённых значений меняет режим работы порта. Эти регистры адресуются от базового адреса контроллера.
_outp(COMBase+3,0x80); - Line Control Register (LCR). Установка старшего бита разрешает доступ к делителю.
_outp(COMBase,0x01); - установка младшего байта делителя (0x01 => 115200 tick/s).
_outp(COMBase+3,0x03); - отключение доступа к делителю и установка размера символа 8 бит, 1 стоп-бит, без контроля чётности.
_outp(COMBase+1,0x00); - Inerrupt Enable Register (IER), запрет всех прерываний.
_outp(COMBase+2,0xC7); - FIFO Control Register (FCR), разрешить буферы FIFO размером 14 байт и очистить их.
_inp(COMBase); - прочитать байт из буфера.
www.osdever.net/documents/CP_serial.pdf

На самом деле, решение зависит от ситуации.

Если у вас есть не огромный(!) набор иконок для повсеместного использования - то вам нужен SVG Sprite. В других ответах уже накидали даже названий библиотек для Vue.

Если коротко, то использование выглядит следующим образом:

Кладете в public файл со спрайтами (обычно, сборка такого файла берут на себя библиотеки. Не хитрый SVG файл, который можно один раз собрать и юзать сборку)

А далее - элементарный компонент

Icon.vue

<template>
  <svg>
    <use :xlink:href="`path-to-sprite.svg#${iconName}`"></use>
  </svg>
</template>

<script lang="ts" setup>
  defineProps<{
    iconName: string;
  }>();
</script>

Использования будет выглядеть следующим образом:
App.vue

<template>
  <div>
    <Icon name="some-icon-1" />
    <Icon name="some-icon-2" />
    <Icon name="some-icon-3" />
  </div>
</template>

<script lang="ts" setup>
  import Icon from './Icon.vue';
</script>

Тут есть небольшой подводный камень, связанный с размерами (use не учитывает width, height, viewBox иконки, которая в Spritemap). Обходится элементарно - добавлением размера для svg с помощью CSS.

Если вам нужны 2-3 иконки - более рационально будет просто заинлайнить их в template. Не очень оптимизировано, зато не тратим кучи времени на ненужные телодвижения.

В случае с большим количеством иконок (более 500) SVG Sprite будет неэффективен ввиду того, что на каждую страницу будет загружаться тонна ненужных иконок. В таких случаях, лучше хранить иконки без спрайта, просто в ассетах и использовать ссылки на них в <use>.

Ссылки:
- https://developer.mozilla.org/en-US/docs/Web/SVG/E...

Если точно нужны inline svg, то vue-svg-loader - он делает автоматически ваш 1-й вариант.

Ещё есть vite-svg-loader - подключается как плагин к vite и удобен тем, что можно из vite.config менять как импортировать файл (url или raw).

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

через "v-if/v-else-if" рендерить ту, которая равна "close".

Если у вас всего 2-3 иконки - можно и так, но в общем случае - старайтесь не использовать длинные "портянки" if/else. Почти всегда можно обойтись без такого кода. (conponent is или defineAsyncComponent)

1е фото - крайний справа

Вернул строку, потому, что команда .join(', '); - превращает массив в строку с разделителем ', '

Ну раз с фронта пересели, то аналогию понять должны: В чëм отличие Google Chrome от JavaScript?

Если ты не используешь unsafe, то сборщик мусора сам все ссылки после передвижения поправит - ради этого он все managed потоки останавливает.

Если ты используешь unsafe и передаёшь куда-то сырые указатели, то тогда тебе надо запинить объект чтобы гарантировать, что объект не будет перемещаться. Для этого, например, есть конструкция fixed, но оно работает только в рамках блока и одного потока.

Там выше посоветовали книгу Конрада Кокосы, добавлю от себя книгу Саши Гольдштейна и у Станислава Сидристого есть недописанная книга. Еще на ютубе с dotNext`а можно посмотреть, что то было интересного про внутненности dotnet`а.

https://habr.com/ru/companies/ruvds/articles/358494/

https://habr.com/ru/articles/269621/
https://habr.com/ru/articles/269707/
https://habr.com/ru/articles/269863/
https://habr.com/ru/articles/681116/
https://habr.com/ru/articles/680038/
https://habr.com/ru/articles/680038/
https://habr.com/ru/articles/681256/

Управление памятью в .NET для профессионалов

Как работает сборка мусора.
В .NET используется 2 фазная сборка мусора: Mark & Sweep (Пометить и Убрать).

Mark

На этом этапе обходится весь граф объектов. И выявляются все недостижимые.

Каким образом достижимость объектов определяется?

Достижимые это:
- Аллоцированные на стеке
- В статических полях
- Достижимые из достижимых (см. выше)

Все объекты, которые не удалось достичь (в граф не попали) - являются недостижимыми.

Но на стеке лежат числа. могут быть как числами, так и адресами, как и числами?

JIT копилятор достаточно умный, чтобы сгенерить код, который будет знать, что за объект/ссылка лежит на стеке. Так и получаются знания об объектах.

Sweep

Тогда итог, что языки с сборщиком мусора, под в 2 раза медленнее должны быть.(помимо сборки)

Вот тут интереснее. Есть несколько хаков как достигается большая производительность.
1. Линеризованное пространство памяти.
Адреса 0, 1 и 2 поколения расположены не абы где, а последовательно, друг за другом. Т.е. если нужно сократить пространство 0 поколения, то это означает простое передвигание указателя влево.

2. Переход в след. поколение происходит не всегда
Из 0 в 1 - переход быстрый, но из 1 в 2 - не всегда.
На этом этапе тоже может не затрачиваться много времени.

3. Ссылки из недостижимых объектов не обновляются - эти объекты и так нигде не участвуют
Обновление ссылок, к сожалению, - это ручное изменение и копирование. Ничего не поделаешь.

Теперь где-то, сборщик мусора, начинает переносить arr в другое место.

Ты слишком большой массив выделил, он аллоцируется в LOH. Оттуда не вытащишь.

Я много о чем не упомянул. Например, очередь финализации, таблица дескрипторов (Handle), сегментирование памяти и т.д. но ответы на основные вопросы дал