#425_DvOp_PkS

Процессы CI.

CI (Continuous Integration) — практика разработки ПО, которая подразумевает регулярное объединение изменений кода от разных разработчиков в общую кодовую базу с целью минимизации конфликтов и быстрого выявления ошибок.


Основные процессы CI:
Автоматизация сборки — каждый раз, когда разработчик отправляет изменения в репозиторий, система CI автоматически запускает сборку проекта.
Это включает компиляцию исходного кода, выполнение тестов и создание артефактов (например, бинарных файлов).
Тестирование — после успешной сборки проект проходит автоматическое тестирование.
Обычно это юнит-тесты, интеграционные тесты и другие виды автоматизированных проверок.
Если хотя бы один тест не пройден, процесс CI завершается ошибкой, а разработчики получают уведомление об этом.
Анализ кода — в процессе CI может проводиться статический анализ кода для поиска потенциальных проблем, таких как уязвимости безопасности, нарушения стандартов кодирования и другие ошибки.
Обратная связь — разработчики должны получать быстрые уведомления о результатах сборки и тестирования.
Это позволяет им оперативно исправлять проблемы до того, как они станут частью основной ветки разработки.
Непрерывные улучшения — процессы CI направлены на постоянное улучшение качества кода и процесса разработки.
Например, если выявляются частые ошибки при сборке или тестировании, можно добавить дополнительные проверки или улучшить инфраструктуру CI/CD.
Интеграция с другими инструментами — СI часто интегрируется с системами управления версиями (Git, SVN), системами отслеживания задач (Jira, Trello) и платформами для развертывания (Docker, Kubernetes).
Это позволяет создавать комплексные решения для автоматизации всего жизненного цикла разработки ПО.


Преимущества CI:
Быстрое обнаружение ошибок — ошибки выявляются сразу после внесения изменений, что упрощает их устранение.
Снижение риска конфликтов — регулярное слияние кода уменьшает вероятность возникновения сложных конфликтов при объединении веток.
Повышение качества кода — автоматизированные тесты и статический анализ помогают поддерживать высокий уровень качества кода.
Ускорение разработки — благодаря автоматизации рутинных процессов, разработчики могут сосредоточиться на создании новых функций и улучшении продукта.


Инструменты для реализации CI: Jenkins, GitLab CI, Travis CI, CircleCI, TeamCity и др.

#426_DvOp_GIT_PkS

Как отредактировать коммит?

Редактирование коммита в системе контроля версий Git возможно несколькими способами в зависимости от того, какой именно коммит нужно изменить и где он находится относительно вашей текущей работы.


Распространенные сценарии:

Изменение последнего коммита — если нужно исправить последний коммит (например, забыли добавить файл или хотите изменить сообщение коммита), используйте команду git commit --amend:

# Откроется редактор, чтобы изменить сообщение коммита
git commit --amend

# Или добавьте параметр -m, чтобы указать новое сообщение напрямую
git commit --amend -m "Новое сообщение"

Эта команда изменяет последний коммит, позволяя внести правки в файлы и/или изменить сообщение коммита.


Редактирование более ранних коммитов с помощью интерактивного ребейза (git rebase -i) — если нужно изменить коммит, который был сделан ранее, но еще не отправлен в удаленный репозиторий, можно использовать интерактивный режим команды rebase.
Для этого выполните следующую команду:

# Укажите хеш коммита, начиная с которого начнется редактирование
git rebase -i <хэш_коммита>

Откроется текстовый редактор с перечнем всех коммитов, начиная с указанного.
Увидите список команд напротив каждого коммита. Чтобы изменить конкретный коммит, замените слово pick на edit рядом с этим коммитом.
После сохранения и выхода из редактора Git перейдет к указанному коммиту, и можно будет его изменить:

# Добавьте нужные изменения в индекс
git add .

# Зафиксируйте изменения
git commit --amend

# Продолжайте ребейс
git rebase --continue

Этот процесс позволит пройти через все указанные коммиты и применить изменения к каждому из них.


Изменение сообщения коммита с помощью git filter-branch — если нужно изменить только сообщение коммита без изменения содержимого файла, можно воспользоваться командой filter-branch:

# Заменяем старое сообщение на новое во всех коммитах
git filter-branch -f --msg-filter 'sed "s/старое сообщение/новое сообщение/g"' HEAD

Внимание!!! Использование этой команды требует осторожности, так как она переписывает историю коммитов и может привести к проблемам при совместной работе над проектом.


Важно!
Помните, что изменение истории коммитов может быть опасно, особенно если эти коммиты уже были отправлены в общий репозиторий.
В таком случае лучше создать новый коммит с исправлениями вместо изменения старых коммитов.

#427_DvOp_GIT_PkS

Интерактивный rebase.

Интерактивный ребейс (interactive rebase) в Git — инструмент, позволяющий изменять историю коммитов в локальном репозитории.
Он предоставляет возможность редактировать, перемещать, удалять и комбинировать коммиты перед тем, как отправить их в удалённый репозиторий.
Интерактивный ребейс полезен, когда необходимо очистить историю коммитов, сделать её более понятной или исправить ошибки.


Как работает интерактивный ребейс?
Когда выполняется команда git rebase -i, Git открывает текстовый редактор с перечислением всех коммитов, которые будут пересмотрены.
Рядом с каждым коммитом указаны действия, которые можно с ним совершить.
По умолчанию указано действие pick, которое означает, что коммит будет оставлен без изменений.


Основные доступные действия:
pick — оставить коммит без изменений;
reword — изменить сообщение коммита;
edit — остановить процесс ребейза на данном коммите, чтобы внести изменения вручную;
squash — объединить текущий коммит с предыдущим;
fixup — аналогично squash, но сообщение текущего коммита игнорируется;
drop — удалить коммит полностью.


Пример списка коммитов в редакторе:

pick a123456 Сообщение первого коммита
pick b234567 Сообщение второго коммита
pick c345678 Сообщение третьего коммита

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

Пример использования.
Допустим, есть три коммита, и нужно объединить второй и третий коммиты в один:

Выполняем команду:

git rebase -i HEAD~3

Открывается редактор с таким содержанием:

pick a123456 Сообщение первого коммита
pick b234567 Сообщение второго коммита
pick c345678 Сообщение третьего коммита

Меняем строки на следующие:

pick a123456 Сообщение первого коммита
pick b234567 Сообщение второго коммита
squash c345678 Сообщение третьего коммита

Сохраняем и закрываем редактор. Git откроет ещё один редактор, чтобы задать итоговое сообщение нового комбинированного коммита.
Здесь можно оставить оба сообщения или написать своё собственное.
После завершения редактирования сообщений Git завершит процесс ребейза, и история коммитов изменится соответствующим образом.


Важные моменты:
Изменение истории — использование интерактивного ребейза меняет историю коммитов, поэтому будьте осторожны, если коммиты уже были отправлены в удалённый репозиторий. Это может привести к конфликтам при следующей попытке push'а.
Резервные копии — перед началом интерактивного ребейза рекомендуется создать резервную копию своей работы, например, с помощью команды git branch backup.
Команды отмены — если что-то пошло не так, всегда можно отменить ребейс с помощью команды git rebase --abort.


Интерактивный ребейс — инструмент для очистки и реорганизации истории коммитов.
Однако важно помнить, что его следует применять осторожно, особенно если работаете в команде.
Правильное использование этого инструмента поможет поддерживать чистую и понятную историю изменений проекта.

#428_DBG_PkS_TP

Какие существуют способы дебаггинга кода?

Дебаггинг (debugging) — процесс нахождения и устранения ошибок в программном коде.
Существует множество методов и подходов к дебаггингу, каждый из которых имеет свои особенности и применяется в зависимости от конкретной ситуации.


Распространённые способы дебаггинга:

Логирование (Logging) — запись информации о выполнении программы в лог-файл или консоль.
Логирование помогает отслеживать состояние приложения в определённые моменты времени и понять, какие операции выполняются и какие данные обрабатываются.

Примеры:
Использование встроенных средств логирования, таких как console.log() в JavaScript или print() в Python.
Применение специализированных библиотек для логирования, таких как logging в Python или log4j в Java.

Плюсы:
Простота использования — возможность записывать информацию в разные уровни детализации (info, warning, error и т.д.).
Минусы:
Может замедлить работу программы, если используется слишком много логов.
Требует анализа большого объёма данных.


Отладка с использованием точек останова (Breakpoints) — точки останова позволяют приостановить выполнение программы в определённой строке кода и исследовать текущее состояние переменных, стек вызовов и другие аспекты выполнения.

Инструменты:
Встроенные отладчики IDE, такие как Visual Studio, PyCharm, IntelliJ IDEA и др.
Внешние отладчики, такие как GDB для C/C++.

Плюсы:
Позволяют детально изучить состояние программы в любой момент времени.
Удобно для пошагового выполнения кода.
Минусы:
Требуют использования специальных инструментов.
Не всегда применимо в высоконагруженных системах или в условиях реального времени.


Печать значений переменных (Print Debugging) — простой способ дебаггинга, заключающийся в выводе значений переменных прямо в коде.
Хотя этот метод считается устаревшим, он всё ещё широко используется, особенно в ситуациях, когда нет доступа к полноценным отладчикам.

Примеры:

printf("Value of x: %d", x); // в C.
System.out.println("Value of x: " + x); // в Java.

Плюсы:
Очень простой и быстрый способ получить информацию о значениях переменных.
Минусы:
Загромождает код.
Трудно масштабируемо для больших проектов.


Анализ дампов памяти (Memory Dumps) — в случае аварийного завершения программы (crash) можно проанализировать дамп памяти, чтобы найти причину сбоя.
Дамп содержит всю информацию о состоянии программы на момент аварии, включая значения переменных, стек вызовов и т.д.

Инструменты:
WinDbg для Windows.
GDB для Linux.

Плюсы:
Полезен для анализа критических сбоев.
Позволяет восстановить состояние программы на момент аварии.
Минусы:
Сложность анализа дампа.
Требуется специализированное оборудование и навыки.


Профилирование (Profiling) — процесс измерения производительности программы, включая время выполнения различных частей кода, использование памяти и другие ресурсы.
Помогает выявить узкие места и оптимизировать производительность.

Инструменты:
VisualVM для Java.
Chrome DevTools для веб-приложений.
Valgrind для C/C++.

Плюсы:
Помогает находить неэффективные участки кода.
Можно использовать для оптимизации производительности.
Минусы:
Может замедлить работу программы во время профилирования.
Требует дополнительных знаний и навыков.

.

Тестирование (Testing) — помогает обнаружить ошибки до их попадания в продакшн-среду.
Существуют различные виды тестирования, такие как модульное тестирование, интеграционное тестирование и регрессионное тестирование.

Инструменты:
JUnit для Java.
pytest для Python.
Mocha для JavaScript.

Плюсы:
Обнаруживает ошибки на ранней стадии разработки.
Повышает качество кода.
Минусы:
Требует написания дополнительного кода для тестов.
Не гарантирует полное отсутствие ошибок.


Рефакторинг (Refactoring) — процесс улучшения структуры и читаемости кода без изменения его функциональности.
Часто приводит к устранению скрытых ошибок и улучшению поддерживаемости кода.

Методы:
Извлечение метода.
Переименование переменной.
Разделение класса.

Плюсы:
Улучшает читаемость и поддержку кода.
Может устранить скрытые ошибки.

Минусы:
Требует времени и усилий.
Необходимо тщательно проверять функциональность после рефакторинга.


Выбор способа дебаггинга зависит от многих факторов, включая ЯП, среду выполнения, сложность задачи и доступное время.
Комбинируя различные методы, можно значительно повысить эффективность поиска и устранения ошибок в коде.

#429_Cpp_DBG

Вывод типов в С++.

Вывод типов в C++ — процесс определения типа переменных или выражений во время компиляции.
В языке есть несколько механизмов для автоматического выведения типов, начиная с версии C++11 и далее.


Основные способы вывода типов в C++:

Ключевое слово auto было введено в C++11 и позволяет компилятору автоматически определять тип переменной на основании инициализатора:

auto x = 5;         // x будет иметь тип int
auto y = 6.7f;      // y будет иметь тип float
auto z = true;      // z будет иметь тип bool

Здесь типы переменных x, y и z определяются автоматически исходя из их инициализаторов.


decltype — используется для получения типа выражения.
decltype возвращает тип, который выражение имело бы в контексте программы:

int a = 10;
decltype(a) b = 20;  // b будет иметь тип int

Шаблонные параметры — шаблоны позволяют выводить типы параметров функций или классов:

template<typename T>
void print(T value) {
  std::cout << "Тип: " << typeid(T).name() << ", Значение: " << value << std::endl;
}

int main() {
  // Тип: int, Значение: 42
  print(42);
  // Тип: double, Значение: 3.14
  print(3.14);
  // Тип: char const*, Значение: Привет
  print("Привет");
  return 0;
}

Здесь функция print принимает параметр любого типа, а компилятор выводит этот тип автоматически.


std::initializer_list — для работы с инициализационными списками используется std::initializer_list.
Его тип может быть выведен автоматически:

void func(std::initializer_list<int> list) {
  for (auto item : list) {
    std::cout << item << ' ';
  }
  std::cout << std::endl;
}

int main() {
  func({1, 2, 3});  // Выведет: 1 2 3
  return 0;
}

decltype(auto) — комбинация decltype и auto позволяет более точно управлять типом возвращаемого значения.
Она полезна, когда требуется сохранить ссылку или тип выражения:

int arr[] = {1, 2, 3};
decltype(auto) ref = arr;
// ref будет иметь тип int (&)[3]

Автоматическое выведение типа возвращаемого значения функции — начиная с C++14, можно опустить указание типа возвращаемого значения функции, и компилятор выведет его автоматически:

auto add(int a, int b) {
  return a + b;
}

int main() {
  // result будет иметь тип int
  auto result = add(5, 10);
  std::cout << result << std::endl;  // Выведет: 15
  return 0;
}

СЛЕДУЕТ ЗАПОМНИТЬ!!!
— в процессе вывода типа шаблона аргументы, являющиеся ссылками, рассматриваются как ссылками не являющиеся, т.е. их "ссылочность" игнорируется;
— при выводе типов для параметров функции, являющихся универсальными ссылками (&&), lvalue-аргументы рассматриваются специальным образом;
— при выводе типов для параметров, передаваемых по значению, аргументы, объявленные как const и/или volatile, рассматриваются как не являющиеся ни const, ни volatile;
— в процессе вывода типа шаблона аргументы, являющиеся именами массивов или функций, преобразуются в указатели, если только они не использованы для инициализациии ссылок;
— вывод типа auto обычно такой же, как и вывод типа шаблона, но вывод типа auto, в отличие от вывода типа шаблона, предполагает, что инициализатор в фигурных скобках представляет std::initializer_list;
— auto в возвращаемом типе функции или параметре лямбда-выражения влечет применение вывода типа шаблона, а не вывода типа auto;
— decltype почти всегда дает тип переменной или выражения без каких-либо изменений;
— для lvalue-выражений типа Т, отличных от имени, decltype всегда дает тип T&;
— C++14 поддерживает конструкцию decltype(auto), которая, подобно auto, выводит тип из его инициализатора, но выполняет вывод типа с использованием правил decltype.


Механизмы выведения типов значительно упрощают программирование на C++, делая код более лаконичным и удобным для чтения.
Особенно полезны они при работе с шаблонами и обобщенным программированием.

#430_Cpp_DBG

Как посмотреть выведенные типы в С++?

Просмотр выведенных типов в C++ полезен для отладки и понимания поведения программы.
Самый простой способ — использование оператора typeid, возвращающего информацию о типе объекта или выражения.


Примеры:
Использование typeid — typeid возвращает объект типа std::type_info, который содержит информацию о типе.
Метод name() этого объекта возвращает строку, представляющую имя типа.
Однако строковое представление имени типа зависит от конкретной реализации компилятора и может быть трудночитаемым.

#include <iostream>
#include <typeinfo>

int main() {
  auto x = 5;
  std::cout << "Тип x: " << typeid(x).name() << std::endl;

  decltype(3.14) y;
  std::cout << "Тип y: " << typeid(y).name() << std::endl;

  return 0;
}

На выходе получим строки, соответствующие именам типов, например:

Тип x: i
Тип y: d

Где i обозначает int, а d — double.
Имена могут отличаться в зависимости от компилятора.


Деманглирование имен типов — если нужны более читаемые имена типов, можно воспользоваться деманглером.
Для GCC и Clang встроенный деманглер доступен через функцию abi::__cxa_demangle:

#include <iostream>
#include <typeinfo>
#include <cxxabi.h>

/* Функция для вывода имени типа в удобочитаемом формате */
std::string demangledTypeName(const char* mangledName) {
  int status;
  char* demangled = abi::__cxa_demangle(mangledName, nullptr, nullptr, &status);
  if (demangled == nullptr || status != 0) {
    return mangledName;
  }
  std::string result(demangled);
  free(demangled);
  return result;
}

int main() {
  auto x = 5;
  std::cout << "Тип x: " << demangledTypeName(typeid(x).name()) << std::endl;

  decltype(3.14) y;
  std::cout << "Тип y: " << demangledTypeName(typeid(y).name()) << std::endl;

  return 0;
}

Теперь результат будет выглядеть так:

Тип x: int
Тип y: double

Это гораздо удобнее для восприятия.


Отладка с помощью IDE — многие современные IDE, такие как Visual Studio, CLion, Eclipse и другие, предоставляют удобные инструменты для просмотра типов переменных прямо во время отладки.
Например, в Visual Studio можно поставить точку останова и просмотреть типы всех переменных в окне Watch или Locals.
Важно помнить!!! При работе со сложными типами, информация, выводимая IDE, может оказаться не точной и не особенно полезной.


Диагностика компилятора — эффективный способ заставить компилятор показать выведенный тип - использовать данный тип так, чтобы это привело к проблемам компиляции.
Сообщение об ошибке практически обязательно будет содержать тип, который к ней привел.

Предположим, что хотим узнать типы, выведенные для х и у из следующего примера:

const int theAnswer = 42 ;
auto х theAnswer;
auto у = &theAnswer;

Сначала объявим шаблон класса, но не определим его:

template<typename Т>
class TD;
// Только объявление TD;

Попытки инстанцировать этот шаблон приведут к сообщению об ошибке, поскольку инстанцируемый шаблон отсутствует.
Чтобы увидеть типы х и у, просто попробуем инстанцировать TD с их типами:

 /* Сообщение об ошибке будет содержать типы х и у */
TD<decltype ( x ) > хТуре ;
TD<decltype ( y ) > уТуре ;

Используем имена переменных вида variaЫeNameType, чтобы проще найти интересующую информацию в сообщении об ошибке.
В зависимости от компилятора сообщения об ошибке могут отличаться:

error: aggregate ' TD<int> хТуре ' has incomplete type and
cannot Ье def ined
error: aggregate ' TD<const int *> уТуре ' has incomplete type
and cannot Ье defined

или например:

error: ' хТуре ' uses undefined class ' TD<int> '
error : ' уТуре ' uses unde fined class ' TD<const int * > '

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

.

Сторонние библиотеки — там, где std::tуре_info::name и IDE могут ошибаться, библиотека Boost Typelndex (часто именуемая как Boost.Typelndex) приведет к успеху.
Boost.TypeIndex не является частью стандарта С++, но точно так же частью стандарта не являются ни IDE, ни шаблоны наподобие рассмотренного выше TD.
Библиотеки Boost (доступные по адресу boost.org) являются кроссплатформенными, с открытым исходным кодом и с лицензией, разработанной так, чтобы быть приемлемой даже для самых параноидальных юристов, означает, что код с применением библиотек Boost переносим практически так же хорошо, как и код, основанный на стандартной библиотеке.

Рассмотрим более сложный пример:

/* Шаблонная функция, вызываемая далее */
template<typename T>
void f(const T& param);

// Фабричная функция
std::vector<Widget> createVec();
/* Инициализация vw возвратом фабричной функции */
const auto vw = createVec();
if (!vw.empty()) {
  // Вызов f
  f(&vw[0]);
}

Этот код, включает пользовательский тип Widget, контейнер STL std::vector и переменную auto vw, является более представительным и интересным примером.
Интересно узнать, какие типы выводятся для параметра типа шаблона T и для параметра param функции f.
Вот как функция f может выдать точную информацию о типах с использованием Boost.Typelndex:

#include <boost/type_index.hpp>

template<typename T>
void f(const T& param) {
  using std::cout;
  using boost::typeindex::type_id_with_cvr;

  // Вывод информации о T
  cout << "T: "
  << type_id_with_cvr<T> ().pretty_name()
  << '\n';

  // Вывод информации о типе param
  cout << "param: "
  << type_id_with_cvr<decltype (param)>().pretty_пame()
  << '\n' ;
}

Как это работает?
Шаблон функции boost::typeindex::type_id_with_cvr получает аргумент типа (тип, о котором мы хотим получить информацию) и не удаляет const, volatile или квалификатор ссылки (о чем и говорит "with_cvr" в имени шаблона).
Результатом является объект boost::typeindex::type_index, функция-член pretty_name которого дает std::string с удобочитаемым представлением типа.
При такой реализации f обратимся к вызову, который дает неверную информацию о типе param при использовании typeid:

// Фабричная функция
std::vector<Widget> createVec();
/* Инициализация vw с помощью фабричной функции */
const auto vw = createVec();
if (!vw.empty()) {
  // Вызов f
  f(&vw[0]);
}

После компиляции с помощью компиляторов GNU и Clang Boost.Typelndex дает следующий (точный) результат:

Т: Widget const *
param: Widget const * const &

Применение компилятора Microsoft дает по сути то же самое:

T = class Widget const *
param = class Widget const * const &

Такое единообразие - это хорошо, но важно помнить, что редакторы IDE, сообщения об ошибках компилятора и библиотеки наподобие Boost.Typelпdex являются всего
лишь инструментами, которые можно использовать для выяснения того, какие типы выводит компилятор.
Это может быть полезно, но не может заменить понимания информации о выводе типов в С++.
Просмотр выведенных типов в C++ может быть полезен для диагностики ошибок и лучшего понимания работы программы.
Используйте typeid и деманглеры для получения информации о типах, а также возможности IDE для удобной отладки.

.

СЛЕДУЕТ ЗАПОМНИТЬ!!!
— выводимые типы часто можно просмотреть с помощью редакторов IDE, сообщений об ошибках компиляции и с использованием библиотеки Boost.Typelпdex.
— результаты, которые выдают некоторые инструменты, могут оказаться как неточными, так и бесполезными, так что понимание правил вывода типов в С++ является совершенно необходимым.

#431_Cpp_DBG_LIB_PkS

Для чего нужны Unit test?
Чем отличается от Functional Test?

Unit tests и functional tests являются важными частями процесса тестирования ПО, однако у них разные цели и подходы к тестированию.


Unit Tests (Юнит-тесты) — предназначены для проверки отдельных компонентов (модулей, классов, методов) программы в изоляции друг от друга.
Основная цель юнит-тестов — убедиться, что каждая часть системы работает правильно и выполняет свои задачи согласно спецификации.

Особенности:
Изоляция — каждый юнит-тест проверяет только одну единицу кода, изолируя её от других частей системы. Это достигается за счет моков (mocks) и заглушек (stubs).
Быстрота выполнения — юнит-тесты обычно выполняются очень быстро, поскольку они работают с небольшими фрагментами кода.
Покрытие кода — хороший набор юнит-тестов должен покрывать большинство возможных путей выполнения кода, включая нормальные сценарии, граничные случаи и исключения.
Автоматизация — юнит-тесты легко автоматизируются и могут запускаться часто, даже после каждого изменения в коде.

Примеры инструментов:
C++: GoogleTest, Catch2, Boost.Test
Java: JUnit, TestNG
Python: unittest, pytest
JavaScript: Jest, Mocha


Functional Tests (Функциональные тесты) — проверяют поведение всей системы или её крупных подсистем с точки зрения пользователя или другого внешнего интерфейса.
Они оценивают, соответствует ли система функциональным требованиям и спецификациям.

Особенности:
Интеграция — функциональные тесты проверяют взаимодействие между различными компонентами системы, включая базы данных, внешние сервисы и пользовательские интерфейсы.
Реалистичность — функциональные тесты имитируют реальные сценарии использования системы, чтобы проверить её функциональность в условиях, близких к реальным.
Время выполнения — функциональные тесты обычно занимают больше времени, чем юнит-тесты, так как они охватывают большие части системы.
Тестовые сценарии — функциональные тесты часто основаны на сценариях использования (use cases), описывающих последовательность действий пользователя.

Примеры инструментов:
Web: Selenium, Cypress
API: Postman, Rest Assured
Desktop applications: Sikuli, AutoIt
Mobile apps: Appium, Espresso


Отличия между Unit Tests и Functional Tests:

Цель:
Юнит-тесты фокусируются на проверке отдельных модулей.
Функциональные тесты проверяют работу всей системы в целом.

Уровень абстракции:
Юнит-тесты работают на уровне кода, проверяя отдельные методы и классы.
Функциональные тесты работают на уровне взаимодействия пользователя с системой.

Скорость выполнения:
Юнит-тесты выполняются быстро, так как они изолированы и проверяют небольшие фрагменты кода.
Функциональные тесты требуют больше времени, потому что они включают интеграцию различных компонентов.

Покрытие:
Юнит-тесты обеспечивают глубокое покрытие кода, проверяя различные пути выполнения.
Функциональные тесты охватывают основные сценарии использования системы.

Инструменты:
Для юнит-тестов используются специализированные фреймворки, такие как GoogleTest или JUnit.
Для функциональных тестов применяются инструменты автоматизации, такие как Selenium или Appium.


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

#432_Cpp_DBG_LIB_PkS

Как тестировать код?
Какой используете фреймворк для С и С++?

Тестирование кода — важный этап разработки ПО, который помогает убедиться, что код работает корректно и соответствует требованиям.


Вот несколько шагов, которые можно использовать для тестирования кода:

Модульное тестирование — тестирование отдельных функций или модулей кода.
Это позволяет проверить, что каждая часть кода работает правильно.

Интеграционное тестирование — тестирование взаимодействия между различными модулями кода.
Это помогает убедиться, что разные части кода работают вместе корректно.

Системное тестирование — тестирование всей системы в целом.
Это включает в себя проверку всех функций и возможностей системы.

Регрессионное тестирование — тестирование, направленное на проверку того, что изменения в коде не привели к появлению новых ошибок.

Нагрузочное тестирование — тестирование производительности системы под нагрузкой.
Это помогает убедиться, что система может справляться с большим количеством запросов или данных.

Тестирование безопасности — тестирование на наличие уязвимостей и проверка того, что система защищена от атак.

Тестирование удобства использования — тестирование интерфейса пользователя на удобство и простоту использования.


Для тестирования кода на языках C и C++ можно использовать различные фреймворки:
Google Test (gtest) — популярный фреймворк для модульного тестирования на C++. Он предоставляет широкий набор функций для написания тестов и поддерживает как C, так и C++.
Catch2 — легкий и удобный фреймворк для модульного тестирования на C++. Он прост в использовании и не требует сложной настройки.
CMake — инструмент для сборки и тестирования проектов на C и C++. Он поддерживает интеграцию с различными тестовыми фреймворками.
Boost.Test — фреймворк для модульного тестирования на C++, который является частью библиотеки Boost.
Unity — легкий фреймворк для модульного тестирования на C. Он прост в использовании и подходит для небольших проектов.
CppUnit — фреймворк для модульного тестирования на C++, который является портом JUnit для C++.


Выбор фреймворка зависит от конкретных требований проекта и предпочтений разработчика.

#433_Cpp_DBG_LIB_PkS

Что такое mock?

Mock (или "мок-объект") — объект-заместитель, который имитирует поведение реального объекта в тестируемом коде.
Моки используются в модульном тестировании для замены зависимостей тестируемого объекта, чтобы изолировать его от внешних систем и проверить его поведение в контролируемых условиях.


Основные цели использования моков:
Изоляция тестируемого кода — моки позволяют изолировать тестируемый объект от внешних зависимостей, таких как базы данных, внешние API, файловые системы и т.д.
Это делает тесты более стабильными и независимыми от состояния внешних систем.
Контроль поведения зависимостей — моки позволяют задавать определённое поведение для зависимостей, что помогает тестировать различные сценарии, такие как успешные и неудачные вызовы, исключения и т.д.
Ускорение тестов — моки могут значительно ускорить выполнение тестов, так как они не требуют реальных внешних систем, которые могут быть медленными или сложными в настройке.

Пример использования мока на C++ с использованием Google Test:

#include <gtest/gtest.h>
#include "gmock/gmock.h"

/* Пример интерфейса для зависимостей */
class Database {
public:
  virtual ~Database() {}
  virtual bool SaveData(const std::string& data) = 0;
};

// Тестируемый класс
class MyClass {
public:
  MyClass(Database* db) : db_(db) {}
  bool Save(const std::string& data) {
    return db_->SaveData(data);
  }
private:
  Database* db_;
};

// Мок для Database
class MockDatabase : public Database {
public:
  MOCK_METHOD(bool, SaveData, (const std::string& data), (override));
};

// Тесты
TEST(MyClassTest, SaveSuccess) {
  MockDatabase mockDb;
  ON_CALL(mockDb, SaveData("test data")).WillByDefault(Return(true));

  MyClass myClass(&mockDb);
  EXPECT_TRUE(myClass.Save("test data"));
}

TEST(MyClassTest, SaveFailure) {
  MockDatabase mockDb;
  ON_CALL(mockDb, SaveData("test data")).WillByDefault(Return(false));

  MyClass myClass(&mockDb);
  EXPECT_FALSE(myClass.Save("test data"));
}

int main(int argc, char** argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

Объяснение:
Database — интерфейс, который используется для работы с базой данных.
MyClass — класс, который использует объект базы данных для сохранения данных.
MockDatabase — мок-объект, который имитирует поведение базы данных.
В тестах SaveSuccess и SaveFailure настраиваем мок-объект так, чтобы он возвращал либо true, либо false при вызове метода SaveData.


Преимущества использования моков:
Изоляция — тестируемый код изолирован от внешних зависимостей.
Повторяемость — тесты всегда дают одинаковые результаты, так как моки контролируют поведение зависимостей.
Скорость — тесты выполняются быстрее, так как не требуется взаимодействие с реальными внешними системами.

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


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

#434_Cpp_PkS

Сколько тестов нужно написать на одну функцию?

Количество тестов, которые нужно написать на одну функцию, зависит от нескольких факторов, таких как сложность функции, её критичность для приложения и требования к тестовому покрытию.


Рекомендации, которые помогут определить, сколько тестов нужно написать:
Покрытие кода — написание тестов, чтобы покрыть все ветви и пути выполнения функции.
Это включает в себя тестирование всех возможных условий if, else, switch, циклов и исключений.
Граничные случаи — проверка граничных значений входных данных, такие как минимальные и максимальные значения, нулевые значения, пустые строки и т.д.
Неудачные сценарии — написание тестов для обработки ошибок и исключений, которые могут возникнуть при вызове функции.
Нормальные сценарии — проверка основных сценариев использования функции с корректными входными данными.
Интеграция с зависимостями — если функция взаимодействует с внешними системами или зависимостями, убедитесь, что тесты проверяют корректность взаимодействия.
Регрессионное тестирование — убедитесь, что новые тесты покрывают изменения, внесённые в функцию, чтобы избежать регрессий.

Пример:
Допустим, у вас есть функция, которая вычисляет факториал числа:

int factorial(int n) {
  if (n < 0) {
    throw std::invalid_argument("n must be non-negative");
  }
  int result = 1;
  for (int i = 1; i <= n; ++i) {
    result *= i;
  }
  return result;
}

Рекомендации по тестированию:

Тест на корректные входные данные — проверить, что функция возвращает правильный результат для небольшого положительного числа, например, factorial(5) == 120.

Тест на граничные случаи — проверить, что функция возвращает 1 для n = 0 и n = 1.
Проверить, что функция возвращает правильный результат для большого числа, например, factorial(10) == 3628800.

Тест на обработку ошибок — проверить, что функция бросает исключение std::invalid_argument при передаче отрицательного числа.

Тест на граничные случаи обработки ошибок — проверить, что функция корректно обрабатывает минимальное отрицательное число, например, factorial(-1).

Тест на интеграцию с зависимостями — если функция использует внешние зависимости, убедитесь, что тесты проверяют их корректность.


Пример тестов с использованием Google Test:

#include <gtest/gtest.h>

int factorial(int n);

TEST(FactorialTest, CorrectInput) {
  EXPECT_EQ(factorial(5), 120);
}

TEST(FactorialTest, BoundaryCases) {
  EXPECT_EQ(factorial(0), 1);
  EXPECT_EQ(factorial(1), 1);
  EXPECT_EQ(factorial(10), 3628800);
}

TEST(FactorialTest, ErrorHandling) {
  EXPECT_THROW(factorial(-1), std::invalid_argument);
}

int main(int argc, char** argv) {
  ::testing::InitGoogleTest(&argc, argv);
  return RUN_ALL_TESTS();
}

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

#435_Cpp_PkS_TP

Что такое побочный эффект, идемпотентность и чистые функции?

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


Побочный эффект (Side Effect) — любое изменение состояния программы, которое происходит в результате выполнения функции, помимо её основного результата.
Другими словами, это когда функция изменяет что-то за пределами своей области видимости (например, глобальные переменные, файлы, базы данных и т.д.) или взаимодействует с внешним миром (например, выводит данные на экран, отправляет запросы в сеть).

Примеры:

int global_variable = 0;

void increment_global() {
  /* Побочный эффект: изменение глобальной переменной */
  global_variable++;
}

void print_message(const std::string& message) {
  // Побочный эффект: вывод на экран
  std::cout << message << std::endl;
}

Идемпотентность (Idempotence) — свойство операции или функции, при котором многократное выполнение операции даёт тот же результат, что и однократное выполнение.
Идемпотентные функции особенно важны в распределённых системах, где запросы могут дублироваться, и нужно гарантировать, что результат останется неизменным.

Примеры:
x = 5; — идемпотентная операция, так как повторное выполнение не изменит значение x.
Удаление файла — идемпотентная операция, так как повторное удаление уже удалённого файла не изменит состояние системы.

Неидемпотентные операции:
x++; — неидемпотентная операция, так как повторное выполнение изменит значение x.
Добавление записи в базу данных — неидемпотентная операция, так как повторное выполнение добавит дублирующую запись.


Чистые функции (Pure Functions) — функция, которая:
Не имеет побочных эффектов: не изменяет состояние программы и не взаимодействует с внешним миром.
Детерминированна: всегда возвращает один и тот же результат для одних и тех же входных данных.

Пример:

int add(int a, int b) {
  /* Чистая функция: не имеет побочных эффектов и детерминирована */
  return a + b;
}

Сравнение:
Функция с побочным эффектом изменяет состояние программы и может возвращать разные результаты при одинаковых входных данных.
Идемпотентная функция может иметь побочные эффекты, но многократное выполнение не изменяет результат.
Чистая функция не имеет побочных эффектов и всегда возвращает один и тот же результат для одних и тех же входных данных.


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

#436_ADM_DvOp_PkS

Что такое контейнеризация и в чем преимущества и недостатки?
Что такое Docker или иной инструмент контейнеризации?

Контейнеризация — метод виртуализации на уровне операционной системы, при котором приложения и их зависимости упаковываются в контейнеры, которые могут быть запущены на любом хосте с поддержкой контейнеров.
Контейнеры позволяют изолировать приложения друг от друга, обеспечивая их независимость от окружения.


Преимущества контейнеризации:
Портативность — контейнеры можно легко перемещать между различными окружениями, будь то локальная машина разработчика, тестовый сервер или производственная среда.
Изоляция — контейнеры изолированы друг от друга, что предотвращает конфликты между приложениями и их зависимостями.
Эффективность — контейнеры используют общие ресурсы ОС, что делает их более легковесными по сравнению с виртуальными машинами.
Упрощение управления зависимостями — все необходимые библиотеки и зависимости упаковываются вместе с приложением, что устраняет проблемы совместимости.
Гибкость — контейнеры могут быть легко масштабированы и развернуты в различных окружениях, что упрощает управление инфраструктурой.


Недостатки контейнеризации:
Ограниченная изоляция — хотя контейнеры изолированы, они все еще используют общие ресурсы операционной системы, что может привести к утечкам данных или проблемам безопасности.
Сложность управления — управление большим количеством контейнеров может быть сложным, особенно в крупных производственных окружениях.
Проблемы совместимости — некоторые приложения могут быть несовместимы с контейнеризацией, особенно если они требуют специфических аппаратных ресурсов или драйверов.
Безопасность — контейнеры могут представлять дополнительные риски безопасности, если не будут правильно настроены и защищены.


Docker — один из самых популярных инструментов для контейнеризации. Он позволяет разработчикам и системным администраторам создавать, запускать и управлять контейнерами.
Docker предоставляет удобные инструменты для упаковки приложений в контейнеры, управления их жизненным циклом и развертывания в различных окружениях.

Преимущества Docker:
Простота использования — Docker предоставляет интуитивно понятный интерфейс для работы с контейнерами.
Широкая поддержка — Docker поддерживается большинством облачных платформ и операционных систем.
Большое сообщество — Docker имеет большое и активное сообщество разработчиков, что обеспечивает доступность документации, примеров и решений для различных задач.
Интеграция с другими инструментами — Docker легко интегрируется с другими инструментами DevOps, такими как Kubernetes, Jenkins и др.

Недостатки Docker:
Зависимость от хостовой ОС — Docker требует установки и настройки на хостовой операционной системе, что может быть сложным для некоторых пользователей.
Проблемы безопасности — как и в случае с контейнеризацией в целом, Docker может представлять дополнительные риски безопасности, если не будет правильно настроен и защищен.
Производительность — в некоторых случаях контейнеры могут работать медленнее, чем нативные приложения, особенно если они требуют интенсивного использования ресурсов.


Альтернативы Docker.
Существуют и другие инструменты контейнеризации, такие как:
Podman — альтернатива Docker, которая предоставляет аналогичные функции, но без использования демона.
LXC/LXD — инструмент для создания и управления контейнерами, который фокусируется на изоляции и безопасности.
Rocket (rkt) — проект, разработанный компанией CoreOS, который предлагает альтернативный подход к контейнеризации.


Каждый из этих инструментов имеет свои особенности и подходит для различных сценариев использования.
Выбор конкретного инструмента зависит от конкретных требований и предпочтений команды разработчиков и администраторов.

#437_ADM_DvOp_PkS

Что такое CI/CD и какие преимущества приносит для разработчика?

CI/CD (Continuous Integration/Continuous Delivery или Continuous Deployment) — методология и набор практик, направленных на автоматизацию процессов разработки, тестирования, интеграции и развертывания программного обеспечения.
CI/CD позволяет разработчикам быстрее и надежнее выпускать новые версии приложений, минимизируя ручные операции и снижая вероятность ошибок.

Непрерываная интеграция CI (Continuous Integration) — процесс, при котором разработчики регулярно объединяют свои изменения в общий репозиторий кода. Каждый раз, когда изменения добавляются в репозиторий, запускаются автоматические процессы сборки и тестирования кода.
Это позволяет быстро выявлять и устранять проблемы, связанные с интеграцией различных частей приложения.

Непрерываная доставка CD (Continuous Delivery или Continuous Deployment) — процесс, при котором изменения в коде автоматически проходят через все этапы тестирования и подготовки к выпуску, чтобы быть готовыми к развертыванию в любое время.
Непрерывное развертывание — следующий шаг, при котором изменения автоматически развертываются в производственную среду после успешного прохождения всех тестов.


Преимущества CI/CD для разработчика:
Ускорение разработки — автоматизация процессов сборки, тестирования и развертывания позволяет разработчикам быстрее выпускать новые функции и исправления.
Снижение риска ошибок — регулярное тестирование и интеграция кода помогают выявлять и устранять проблемы на ранних этапах, что уменьшает вероятность критических ошибок в производственной среде.
Повышение качества кода — автоматизированные тесты и проверки кода способствуют улучшению его качества и стабильности.
Улучшение сотрудничества — CI/CD способствует более тесному взаимодействию между разработчиками, тестировщиками и операционными командами, что улучшает координацию и уменьшает конфликты.
Гибкость и масштабируемость — CI/CD позволяет легко масштабировать процессы разработки и развертывания, поддерживая рост команды и проекта.
Снижение стресса — автоматизация рутинных задач уменьшает нагрузку на разработчиков и позволяет им сосредоточиться на более творческих и сложных задачах.


Инструменты CI/CD:
Jenkins — один из самых популярных инструментов для CI/CD, предоставляющий гибкие возможности настройки и интеграции с различными системами.
GitLab CI/CD — встроенный в GitLab инструмент для CI/CD, который интегрируется с системой контроля версий.
CircleCI — облачный сервис для CI/CD, который поддерживает различные языки программирования и платформы.
Travis CI — популярный облачный сервис для CI/CD, особенно среди проектов с открытым исходным кодом.
Bamboo — инструмент от Atlassian, который интегрируется с Jira и Bitbucket.


Выбор конкретного инструмента зависит от требований проекта, инфраструктуры и предпочтений команды.

#438_ADM_DvOp_PkS

Какие принципы итеративных методологий?

Итеративные методологии — подходы к разработке ПО, которые предполагают выполнение работы в коротких циклах (итерациях), с постепенным добавлением новых функций и улучшением существующих.
Эти методологии позволяют быстрее получать обратную связь и адаптироваться к изменениям требований.


Основные принципы итеративных методологий:
Разделение на итерации — проект делится на небольшие, управляемые этапы, каждый из которых включает в себя планирование, разработку, тестирование и интеграцию.
Обратная связь — регулярное получение обратной связи от пользователей и заинтересованных сторон позволяет корректировать курс разработки и улучшать продукт.
Адаптация — итеративные методологии позволяют легко адаптироваться к изменениям требований и условиям проекта.
Постоянное улучшение — каждый цикл итерации позволяет улучшать качество продукта, устранять ошибки и добавлять новые функции.
Гибкость — итеративные методологии позволяют быстро реагировать на изменения и корректировать планы в зависимости от текущих обстоятельств.
Командная работа — итеративные методологии предполагают тесное взаимодействие между членами команды, что способствует более эффективной работе и лучшему пониманию задач.
Минимизация рисков — разделение проекта на небольшие итерации позволяет снизить риски, связанные с разработкой, так как проблемы выявляются и решаются на ранних этапах.
Быстрое получение результатов — благодаря коротким циклам разработки, пользователи могут получать рабочие версии продукта уже на ранних стадиях проекта.


Примеры итеративных методологий: Agile, Scrum и Kanban.

#439_ADM_DvOp_PkS

Какие преимущества и недостатки code-convention?

Code convention (или кодовые соглашения) — набор правил и рекомендаций, которые определяют, как должен выглядеть и структурироваться код в проекте.
Эти соглашения могут касаться стиля написания, именования переменных, функций, классов, отступов, комментариев и других аспектов кода.


Преимущества code convention:
Улучшение читаемости кода — когда все члены команды следуют единым правилам, код становится более читаемым и понятным.
Это особенно важно в крупных проектах, где участвует много разработчиков.
Снижение количества ошибок — строгие правила именования и форматирования могут помочь избежать ошибок, связанных с неправильным использованием переменных, функций или классов.
Улучшение совместимости — единые соглашения облегчают интеграцию кода, написанного разными разработчиками, и делают его более совместимым.
Упрощение поддержки и сопровождения — код, написанный в соответствии с соглашениями, легче поддерживать и обновлять, так как он более предсказуем и структурирован.
Повышение производительности команды — разработчики тратят меньше времени на понимание чужого кода и могут быстрее вносить изменения, что повышает общую производительность команды.
Стандартизация — Code convention помогает стандартизировать код в рамках проекта или компании, что делает его более унифицированным и предсказуемым.


Недостатки code convention:
Ограничения творчества — строгие правила могут ограничивать свободу разработчиков в выборе стиля написания кода, что может быть неприятно для некоторых.
Дополнительные усилия на начальном этапе: Внедрение code convention требует времени и усилий, особенно если команда ранее не следовала каким-либо соглашениям.
Необходимость обучения: Новые члены команды должны изучить и освоить соглашения, что может занять время и потребовать дополнительных ресурсов.
Риск конфликтов: Если соглашения не будут четко определены или если члены команды не будут строго их придерживаться, это может привести к конфликтам и разногласиям.
Сложность в больших проектах: В крупных проектах с большим количеством разработчиков и legacy-кодом может быть сложно внедрить и поддерживать единые соглашения.
Зависимость от инструментов: Некоторые code convention могут требовать использования специфических инструментов для проверки и соблюдения правил, что может усложнить процесс разработки.

Примеры code convention:

Стиль именования: Например, использование camelCase для переменных и PascalCase для классов.
Отступы и форматирование: Использование табуляции или пробелов для отступов, правила для размещения фигурных скобок.
Комментирование: Правила для написания комментариев, их стиля и содержания.
Документирование: Требования к документации кода, например, использование Javadoc или другой системы документации.

Использование code convention — это важный аспект профессиональной разработки, который помогает поддерживать качество и согласованность кода в команде.

#440_Cpp

Что предпочтительнее auto или явное указание типа в С++?

В С++ существует два способа объявления переменных: с использованием ключевого слова auto и с явным указанием типа.


Ключевое слово auto было введено в стандарт С++11 и позволяет компилятору автоматически определять тип переменной на основе инициализирующего значения.

Причины, почему auto может быть предпочтительным:
Упрощение кода: Использование auto делает код более кратким и читаемым, особенно в случаях, когда тип переменной явно следует из инициализирующего выражения.
Автоматическое определение сложных типов: В случаях, когда тип переменной сложно или неудобно указывать явно (например, при работе с шаблонами или лямбда-функциями), auto значительно упрощает код.
Избежание ошибок: Использование auto помогает избежать ошибок, связанных с некорректным указанием типа, так как компилятор автоматически определяет правильный тип.
Совместимость с современными стандартами: В новых версиях С++ использование auto становится все более распространенным и поддерживается многими современными идиомами программирования.


Явное указание типа переменной также имеет свои преимущества:
Ясность и предсказуемость: Явное указание типа делает код более понятным и предсказуемым, особенно для разработчиков, которые не знакомы с проектом или не используют современные инструменты анализа кода.
Контроль над типом: В некоторых случаях может быть важно явно указать тип переменной, чтобы обеспечить точное соответствие требованиям или избежать неявных преобразований типов.
Совместимость с устаревшим кодом: В проектах, использующих старые стандарты С++, явное указание типа может быть необходимым для обеспечения совместимости.


Когда использовать auto
auto предпочтительно использовать в следующих случаях:

Когда тип переменной явно следует из инициализирующего выражения.
При работе с шаблонами и лямбда-функциями.
Для упрощения кода и уменьшения вероятности ошибок.


Когда использовать явное указание типа
Явное указание типа предпочтительно в следующих случаях:
Когда важно обеспечить точное соответствие типа переменной определенным требованиям.
В проектах, использующих старые стандарты С++.
Для повышения ясности и предсказуемости кода.


Выбор между auto и явным указанием типа зависит от контекста и предпочтений разработчика. В современных проектах, использующих С++11 и выше, auto становится все более популярным и предпочтительным, особенно в случаях, когда тип переменной явно следует из инициализирующего выражения. Однако в некоторых ситуациях явное указание типа может быть необходимым для обеспечения ясности, предсказуемости или совместимости с устаревшим кодом.

#441_ALG_TP

Интрузивные структуры данных.

Интрузивные (или встроенные) структуры данных — структуры данных, где каждый элемент хранит указатели на другие элементы этой же структуры.
Примером интрузивных структур являются связные списки (linked lists), деревья (например, бинарное дерево поиска) и графы.


Основные характеристики интрузивных структур данных:
Динамическое выделение памяти — элементы структуры создаются динамически во время выполнения программы, часто с использованием операций malloc/new.
Указатели между элементами — каждый элемент содержит один или несколько указателей на другие элементы той же структуры.
Нет фиксированного размера — интрузивные структуры данных не имеют заранее определенного размера и могут расширяться или сокращаться по мере добавления или удаления элементов.
Эффективность операций вставки и удаления — вставка и удаление элементов зачастую происходят быстро, поскольку не требуют перемещения остальных элементов (как это бывает в массивах).
Дополнительная память для указателей — помимо хранения самих данных, каждый элемент должен хранить дополнительные указатели, что увеличивает общий объем занимаемой памяти.


Рассмотрим простейший пример связного списка:

struct Node {
  int data;
  Node* next;
};

Здесь структура Node содержит два поля:
— data — поле для хранения данных,
— next — указатель на следующий узел списка.
Таким образом, каждая запись содержит данные и ссылку на следующую запись, образуя цепочку элементов.


Преимущества интрузивных структур:
Гибкость — можно легко добавлять и удалять элементы без перераспределения всей структуры.
Простота реализации — например, операции вставки или удаления элемента в списке выполняются за O(1) в большинстве случаев.

Недостатки:
Необходимость управления памятью вручную (в C/C++).
Дополнительные затраты памяти на хранение указателей.
Сложнее обеспечить случайный доступ к элементам (нужно проходить по всей структуре до нужного узла).


Использование интрузивных структур особенно полезно там, где важна гибкость структуры данных и быстрое выполнение операций вставки/удаления.

#442_C_LIB

Библиотека termios в С функциональность и назначение?

Библиотека termios в ЯП C предназначена для управления характеристиками терминалов и взаимодействия с ними.
Она обеспечивает низкоуровневый контроль над функциями ввода-вывода в терминалах Unix-подобных ОС, таких как Linux, macOS и BSD.


Функциональность библиотеки termios.
Библиотека termios предоставляет набор функций и структур данных для управления поведением терминала.

Основные возможности, предоставляемые библиотекой:

Управление режимами терминала — терминалы могут работать в двух основных режимах:
— канонический режим — ввод воспринимается построчно. То есть, программа получает данные только после нажатия клавиши Enter.
— неканонический режим — программа может получать данные посимвольно, что позволяет реализовать интерактивные приложения, реагирующие на каждое нажатие клавиши.
Функции библиотеки termios позволяют переключаться между этими режимами и настраивать их параметры.

Управление сигналами — терминалы поддерживают специальные сигналы, такие как Ctrl+C (SIGINT), Ctrl+Z (SIGTSTP) и другие.
Библиотека termios позволяет изменять обработку этих сигналов, например, игнорировать их или перехватывать для выполнения определённых действий.

Управление скоростью ввода-вывода — через termios можно контролировать скорость передачи данных между программой и терминалом, что важно для приложений, работающих в режиме реального времени.

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

Управление клавиатурой — библиотека позволяет настраивать реакцию на нажатия клавиш, например, чтобы определять функциональные клавиши или комбинации клавиш.

Буферизация ввода-вывода — можно настроить размер буфера и политику его заполнения, что влияет на производительность ввода-вывода.


Назначение библиотеки termios.
Основное назначение библиотеки termios заключается в предоставлении программистам инструментов для низкоуровневого контроля над работой терминалов.
Это позволяет создавать высокопроизводительные консольные приложения, такие как редакторы текста (например, Vi или Emacs), игровые консоли и другие интерактивные утилиты.


Примеры использования termios включают:
— написание собственных оболочек (терминалов);
— создание текстовых игр с поддержкой горячих клавиш;
— управление эхо-сигналом для безопасного ввода паролей;
— программирование систем мониторинга и управления, работающих в терминальном режиме.


Основные функции и структуры предоставляемые библиотекой termios:

/* Получение текущих атрибутов терминала. */
tcgetattr();

/* Устанавливка новых атрибутов терминала. */
tcsetattr();

/* Установка или получение скорости ввода терминала. */
cfgetispeed();
cfsetispeed();

/* Управление скоростью вывода терминала. */
cfgetospeed();
cfsetospeed();

/* Ожидание, пока все данные будут переданы на устройство. */
tcdrain();

/* Приостановка или возобновление передачи данных на терминал. */
tcflow();

/* Удаление данных из входного или выходного буфера терминала. */
tcflush();

.