Text
This commit is contained in:
@ -10,7 +10,7 @@ toc: yes
|
||||
|
||||
### Информация и лицензия
|
||||
|
||||
[PVS-Studio](https://www.viva64.com/ru/pvs-studio/) - это инструмент для
|
||||
[PVS-Studio](https://www.viva64.com/ru/pvs-studio/) — это инструмент для
|
||||
статического анализа исходного кода программ, написанных на языках С, C++.
|
||||
|
||||
Для использования в Linux нужно чтобы в каталоге `~/.config/PVS-Studio`
|
||||
@ -23,7 +23,7 @@ toc: yes
|
||||
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
|
||||
```
|
||||
|
||||
### Настройка и комплияция проекта
|
||||
### Настройка и компиляция проекта
|
||||
|
||||
Полное руководство для работы в Linux находится
|
||||
[здесь](https://www.viva64.com/ru/m/0036/), а ниже приведён список типовых команд.
|
||||
@ -68,7 +68,7 @@ ninja -t compdb
|
||||
|
||||
Выбор типов предупреждений осуществляется на основе побитовой маски из
|
||||
приведенных выше типов. Чтобы выполнить анализ, исключив проверки MISRA,
|
||||
нужно выполнить:
|
||||
нужно выполнить
|
||||
|
||||
```sh
|
||||
pvs-studio-analyzer analyze -a 29 -j$(nproc) -o pvs.log
|
||||
35
wiki/Prog/Development/Подбор ключей компиляции GCC.md
Normal file
35
wiki/Prog/Development/Подбор ключей компиляции GCC.md
Normal file
@ -0,0 +1,35 @@
|
||||
---
|
||||
title: Подбор ключей компиляции GCC
|
||||
category: Программирование
|
||||
tags: программирование, C, C++, отладка, оптимизация
|
||||
summary:
|
||||
...
|
||||
|
||||
Подбор ключей компиляции основан на измерениях характеристик во
|
||||
время выполнения программы. На первом этапе создаётся исполняемый
|
||||
файл `program`, в который включается информация для профилировки.
|
||||
Ключ `-fprofile-generate=data/pgo` указывает, что нужно собирать
|
||||
информацию и сохранять в каталог `data/pgo`. Компиляцию следует
|
||||
выполнять в последовательном режиме.
|
||||
|
||||
```sh
|
||||
env CXXFLAGS='-fprofile-generate=data/pgo' cmake .. -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles"
|
||||
make -j1
|
||||
```
|
||||
|
||||
После компиляцию программу следует выполнить, придерживаясь
|
||||
типичного сценария использования.
|
||||
|
||||
```sh
|
||||
./program
|
||||
```
|
||||
|
||||
Скомпилировать программу с использованием полученной статистики.
|
||||
Для многопоточной программы следует указать флаг `-fprofile-correction`,
|
||||
чтобы скорректировать данные, которые могут неустойчивыми из-за пропусков
|
||||
обновлений счётчиков. Компиляцию следует выполнять в последовательном режиме.
|
||||
|
||||
```sh
|
||||
env CXXFLAGS='-fprofile-use=data/pgo -fprofile-correction' cmake .. -DCMAKE_BUILD_TYPE=Release -G "Unix Makefiles"
|
||||
make -j1
|
||||
```
|
||||
55
wiki/Prog/Development/Профилирование кода.md
Normal file
55
wiki/Prog/Development/Профилирование кода.md
Normal file
@ -0,0 +1,55 @@
|
||||
---
|
||||
title: Профилирование кода
|
||||
category: Программирование
|
||||
tags: программирование, отладка, производительность, профилирование, gprof
|
||||
summary:
|
||||
...
|
||||
|
||||
## Общее описание
|
||||
|
||||
Чтобы профилировать приложения, компилируемые [GCC](http://gcc.gnu.org),
|
||||
необходимо добавлять флаг `-fno-omit-frame-pointer` и желательно `-g`.
|
||||
|
||||
## quickstack
|
||||
|
||||
Утилита для отслеживания стеков вызовов функций [quicktrack](https://github.com/yoshinorim/quickstack).
|
||||
Пример использования:
|
||||
|
||||
```sh
|
||||
quickstack -f -p $(pidof application)
|
||||
```
|
||||
|
||||
## perf
|
||||
|
||||
Утилита профилирования для ядра Linux (находится в дереве его исходных текстов
|
||||
в каталоге `tools/perf`).
|
||||
|
||||
Полезные ссылки:
|
||||
|
||||
* [Официальная страница](https://perf.wiki.kernel.org/index.php/Main_Page)
|
||||
* [Примеры](https://stackoverflow.com/questions/1777556/alternatives-to-gprof/10958510#10958510)
|
||||
* [Примеры](http://www.brendangregg.com/perf.html)
|
||||
|
||||
|
||||
## Systemtap
|
||||
|
||||
[Установка и простые примеры использования SystemTap](https://eax.me/systemtap/)
|
||||
|
||||
|
||||
## Valgrind
|
||||
|
||||
|
||||
## gperftools
|
||||
|
||||
|
||||
## Разное
|
||||
|
||||
* [Профилирование кода на C/C++ в Linux и FreeBSD](https://eax.me/c-cpp-profiling/)
|
||||
* [Примеры](http://gernotklingler.com/blog/gprof-valgrind-gperftools-evaluation-tools-application-level-cpu-profiling-linux/)
|
||||
|
||||
|
||||
## Графическое отображение
|
||||
|
||||
* [Flame Graphs](http://www.brendangregg.com/flamegraphs.html)
|
||||
* [gprof2dot](https://github.com/jrfonseca/gprof2dot)
|
||||
|
||||
@ -6,7 +6,8 @@ summary: ""
|
||||
...
|
||||
|
||||
|
||||
1) В главном меню QGis **Слой** - **Добавить слой** - **Добавить векторный слой** выбрать и открыть файл с векторным слоем, например, `map.sxf`.
|
||||
1) В главном меню QGis **Слой** — **Добавить слой** — **Добавить векторный слой**
|
||||
выбрать и открыть файл с векторным слоем, например, `map.sxf`.
|
||||
|
||||
2) Среди слоёв выбрать слой с рельефом местности и типом геометрии `LineString`.
|
||||
|
||||
@ -19,26 +20,29 @@ summary: ""
|
||||
`"CLNAME" ILIKE '%ГОРИЗОНТАЛИ ОСНОВ%'` и нажить **OK**.
|
||||
|
||||
5) На панели **Панель слоёв** правой кнопкой мыши щелкнуть на слое,
|
||||
содержащем данные о высотах, и выбрать **Сохранить как...**. Появишийся новый
|
||||
слой **heights** следует удалить.
|
||||
содержащем данные о высотах, и выбрать **Сохранить как...**. Появившийся
|
||||
новый слой **heights** следует удалить.
|
||||
|
||||
6) В появившемся диалоговом окне выбрать имя выходного файла, например, `heights`.
|
||||
|
||||
|
||||
|
||||
7) В каталоге `/home/a/work/map` выполнить команду, которая в файле `heights.shp` из слоя `heights` берёт данные о высотах из
|
||||
поля `SC_4` и генерирует матрицу высот размером 2000 на 2000 в формате BMP.
|
||||
7) В каталоге `/home/a/work/map` выполнить команду, которая в файле
|
||||
`heights.shp` из слоя `heights` берёт данные о высотах из поля `SC_4`
|
||||
и генерирует матрицу высот размером 2000 на 2000 в формате BMP.
|
||||
Настойки алгоритма посторения матрицы можно изменять с помощью параметра `-a`:
|
||||
|
||||
```sh
|
||||
gdal_grid -a invdist:power=3.0:smoothing=1.0 -outsize 2000 2000 -of BMP -ot Byte -zfield SC_4 -l heights heights.shp heights.bmp
|
||||
```
|
||||
|
||||
8) После построения матрицы её можно импортировать в QGis как растровый слой, для этого в главном меню QGis **Слой** - **Добавить слой** - **Добавить растровый слой** нужно выбрать и открыть файл `heights.bmp`. В результате на
|
||||
панели **Панель слоёв** появится растровый слой **heights**.
|
||||
8) После построения матрицы её можно импортировать в QGis как растровый
|
||||
слой, для этого в главном меню QGis **Слой** — **Добавить слой** —
|
||||
**Добавить растровый слой** нужно выбрать и открыть файл `heights.bmp`.
|
||||
В результате на панели **Панель слоёв** появится растровый слой **heights**.
|
||||
|
||||
9) С помощью модуля Profile Tool можно построить провиль местности. В главном
|
||||
меню нужно выбрать **Модуль** - **Profile Tool** - **Terrain profile**.
|
||||
9) С помощью модуля Profile Tool можно построить профиль местности. В главном
|
||||
меню нужно выбрать **Модуль** — **Profile Tool** — **Terrain profile**.
|
||||
|
||||
10) На панели **Панель слоёв** нужно перенести растровый слой **heights**
|
||||
в конец списка, выделить его и на панели **Profile Tool** нажать **Add Layer**.
|
||||
|
||||
@ -11,13 +11,18 @@ summary: ""
|
||||
Если нужно следить за каталогом `/home/user/dir` и записывать историю
|
||||
изменений в `/home/user/repo/dir`, то нужно инициализировать репозиторий:
|
||||
|
||||
git init --bare /home/user/repo/dir
|
||||
```sh
|
||||
git init --bare /home/user/repo/dir
|
||||
```
|
||||
|
||||
добавить шаблоны исключаемых файлов
|
||||
добавить шаблоны исключаемых файлов:
|
||||
|
||||
printf '*.[oa]\n*.swp\n*~\n/.git' >> /home/user/repo/dir/info/exclude
|
||||
```sh
|
||||
printf '*.[oa]\n*.swp\n*~\n/.git' >> /home/user/repo/dir/info/exclude
|
||||
```
|
||||
|
||||
и запустить скрипт
|
||||
|
||||
./gitwatch.sh -g /home/user/repo/dir /home/user/dir
|
||||
и запустить скрипт:
|
||||
|
||||
```sh
|
||||
./gitwatch.sh -g /home/user/repo/dir /home/user/dir
|
||||
```
|
||||
|
||||
@ -5,7 +5,7 @@ tags: программирование, git
|
||||
summary:
|
||||
...
|
||||
|
||||
Создание репозитория для нового проекта
|
||||
Создание репозитория для нового проекта:
|
||||
|
||||
```sh
|
||||
ln -s /media/user/usbdisk/git /home/user/work/usbdisk/git
|
||||
@ -13,10 +13,10 @@ git --bare init /home/user/work/usbdisk/git/project.git
|
||||
cd /home/user/work/projects
|
||||
git clone /home/user/work/usbdisk/git/project.git
|
||||
cd project
|
||||
git remote set-url origin file:///home/user/work/usbdisk/git/project.git/
|
||||
git remote set-url usb file:///home/user/work/usbdisk/git/project.git/
|
||||
```
|
||||
|
||||
Добавление нового удалённого репозитория к существующему проекту
|
||||
Добавление нового удалённого репозитория к существующему проекту:
|
||||
|
||||
```sh
|
||||
ln -s /media/user/usbdisk/git /home/user/work/usbdisk/git
|
||||
|
||||
@ -10,8 +10,8 @@ summary: ""
|
||||
Допустим, по адресу `git://localhost/project.git` находится
|
||||
большой проект, в котором интересует только последнее
|
||||
состояние каталогов `src/driver` и `include/driver`.
|
||||
Сначала нужно создать репозиторий и подготовить его для
|
||||
получения только необходимых файлов:
|
||||
Сначала нужно создать пустой репозиторий и подготовить его
|
||||
для получения только необходимых файлов:
|
||||
|
||||
```sh
|
||||
git init project
|
||||
@ -26,4 +26,6 @@ echo "include/driver/*" >> .git/info/sparse-checkout
|
||||
а, добавив ключ `--depth=1`, указать, что синхронизироваться
|
||||
должно только текущее состояние файлов без учёта истории.
|
||||
|
||||
git pull --depth=1 origin master
|
||||
```sh
|
||||
git pull --depth=1 origin master
|
||||
```
|
||||
|
||||
24
wiki/Prog/Git/Gitlab выполнение по расписанию.md
Normal file
24
wiki/Prog/Git/Gitlab выполнение по расписанию.md
Normal file
@ -0,0 +1,24 @@
|
||||
---
|
||||
title: "GitLab — выполнение по расписанию"
|
||||
category: Программирование
|
||||
tags: программирование, gitlab, git
|
||||
summary:
|
||||
...
|
||||
|
||||
После помещения изменений (push) на сервер следует выполнять только задачи,
|
||||
не требующие много ресурсов. Ресурсоёмкие задачи можно отложить на время
|
||||
минимальной нагрузки сервера. Для этого нужно:
|
||||
|
||||
* в секциях файла `.gitlab-ci.yml`, запускающих задачи с высокой нагрузкой,
|
||||
добавить
|
||||
|
||||
```yaml
|
||||
only:
|
||||
- schedules
|
||||
```
|
||||
|
||||
подробнее это описано [здесь](https://docs.gitlab.com/ee/ci/yaml/#only-and-except-simplified)
|
||||
|
||||
* в веб-интерфейсе в меню **CI/CD** / **Расписания** добавить **Новое расписание**
|
||||
и назначить исполнение задачи на время, когда нагрузка на сервер минимальна.
|
||||
|
||||
@ -8,7 +8,7 @@ toc: yes
|
||||
|
||||
[TOC]
|
||||
|
||||
Установка вылолняется в операционной системе Ubuntu Bionic.
|
||||
Установка выполняется в операционной системе Ubuntu Bionic.
|
||||
|
||||
### LXC
|
||||
|
||||
@ -139,7 +139,6 @@ cat /etc/docker/daemon.json
|
||||
}
|
||||
|
||||
|
||||
|
||||
### Ссылки
|
||||
|
||||
* [GitLab Runner](https://docs.gitlab.com/runner/register/index.html)
|
||||
|
||||
1181
wiki/Prog/Lang/CPP/Проверка именования в Clang Tidy.md
Normal file
1181
wiki/Prog/Lang/CPP/Проверка именования в Clang Tidy.md
Normal file
File diff suppressed because it is too large
Load Diff
28
wiki/Prog/Links/Библиотеки C CPP.md
Normal file
28
wiki/Prog/Links/Библиотеки C CPP.md
Normal file
@ -0,0 +1,28 @@
|
||||
---
|
||||
title: "Библиотеки для C, C++"
|
||||
category: Программирование
|
||||
tags: программирование, C, C++, Qt
|
||||
summary:
|
||||
toc: yes
|
||||
...
|
||||
|
||||
[TOC]
|
||||
|
||||
### C
|
||||
|
||||
* [nanomsg](http://nanomsg.org): сетевое взаимодействие
|
||||
* [noping](https://noping.cc): работа с ICMP-пакетами
|
||||
* [openblas](https://github.com/xianyi/OpenBLAS): оптимизированная версия
|
||||
[BLAS](https://ru.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms)
|
||||
|
||||
### C++
|
||||
|
||||
* [JSON](https://github.com/nlohmann/json)
|
||||
* [fmtlib](https://github.com/fmtlib/fmt): форматирование строк
|
||||
* [spdlog](https://github.com/gabime/spdlog): журналирование
|
||||
* [cpptoml](https://github.com/skystrife/cpptoml): чтение [TOML](https://github.com/toml-lang/toml)
|
||||
|
||||
|
||||
### Qt
|
||||
|
||||
* [Обработка сигналов UNIX](https://github.com/sjinks/qt_signalwatcher)
|
||||
159
wiki/Prog/Time/Работа с датами и временем.md
Normal file
159
wiki/Prog/Time/Работа с датами и временем.md
Normal file
@ -0,0 +1,159 @@
|
||||
---
|
||||
title: Работа с датами и временем
|
||||
category: Программирование
|
||||
tags: программирование, время, часы, дата
|
||||
summary:
|
||||
toc: yes
|
||||
toc-depth: 4
|
||||
...
|
||||
|
||||
[TOC]
|
||||
|
||||
### Временные шкалы
|
||||
|
||||
В идеале системы учёта времени должны обладать тремя характеристиками:
|
||||
|
||||
1. _точность_ (время базируется на атомном стандарте, каждая секунда
|
||||
отсчитывается как секунда в системе СИ, нет високосных секунд, переводов
|
||||
на зимнее или летнее время и т.п.);
|
||||
2. _простота_ (каждый "день" состоит из 86400 "секунд");
|
||||
3. _календарные дни_ (дни календаря точно соответствуют вращению Земли).
|
||||
|
||||
На практике есть возможность выбрать шкалу только с двумя характеристиками
|
||||
из трёх.
|
||||
|
||||
1. точность и календарные дни. Примером такой шкалы является UTC,
|
||||
в которой отсчёт дней и секунд ведётся разными методами (секунды
|
||||
исчисляются по атомному стандарту, а дни по суточному вращению Земли),
|
||||
а соответствие достигается вводом _секунды координации_;
|
||||
|
||||
2. календарные дни и простота. Примером такой шкалы является POSIX
|
||||
(IEEE Std 1003.1-1988), в которой день всегда равен 86400 секундам;
|
||||
|
||||
3. точность и простота. Этими характеристиками обладают технические
|
||||
шкалы (атомные часы, GPS), в которых не важен учёт дней.
|
||||
|
||||
|
||||
### Классы времени
|
||||
|
||||
Время можно условно поделить на два класса: физическое и гражданское.
|
||||
|
||||
1. _Физическое_ время представляет собой точки на непрерывной шкале, такую
|
||||
концепцию достаточно точно отражает UTC, если можно пренебречь _секундой
|
||||
координации_ (дополнительная секунда, добавляемая к UTC 30 июня или 31 декабря
|
||||
для согласования со средним солнечным временем UT1. В этот момент время
|
||||
условно обозначается как 23:59:60, а на шкале UTC две секунды отображаются
|
||||
как одна).
|
||||
|
||||
2. _Гражданское_ время представляется полями (год, месяц, число, час, минута,
|
||||
секунда, доли секунды, а также временная зона и календарь, который по умолчанию
|
||||
считается Григорианским).
|
||||
|
||||
Почти всегда существует возможность однозначно перевести физическое время
|
||||
в гражданское и наоборот, но при этом следует различать их свойства и
|
||||
применение (ближайшая аналогия — массивы байтов и символьные строки).
|
||||
|
||||
Основная проблема состоит в том, что в обычном употреблении не всегда можно
|
||||
сделать вывод о том, какой класс времени подразумевается, и гражданское
|
||||
время меняется на основании юридических актов (указов, постановлений и т.п.),
|
||||
что приводит к неоднозначности при планировании событий.
|
||||
|
||||
### Обработка на компьютере
|
||||
|
||||
#### Хранение и отображение
|
||||
|
||||
Для ссылки на момент во времени необходимо использовать единую шкалу,
|
||||
на которой нет разрывов, связанных с летним временем. Примером стандарта
|
||||
времени с такой шкалой является UTC. Локальное или местное время для таких
|
||||
целей не подходит, так как на его шкале имеются разрывы и неоднозначности,
|
||||
связанные с переходами на летнее время и обратно.
|
||||
|
||||
Если нужно сохранить значение локального времени, то необходимо сохранить
|
||||
также смещение относительно UTC, чтобы временную отметку можно было
|
||||
интерпретировать однозначно. Необходимо помнить, что местное время может
|
||||
отличаться от UTC на интервал не кратный часу (например, в Нидерландах
|
||||
с 1909-05-01 по 1937-06-30 смещение времени от UTC составляло
|
||||
19 минут и 32.13 секунд).
|
||||
|
||||
Правила хранения и отображения времени:
|
||||
|
||||
1. Время всегда хранится в UTC. При необходимости дополнительно сохраняется
|
||||
информация о временной зоне (смещение и/или название).
|
||||
|
||||
2. Для вывода на экран время переводится в местное.
|
||||
|
||||
3. При выводе на экран отличного от местного времени необходимо указывать
|
||||
название часового пояса или типа исчисления (например, Юлианский календарь).
|
||||
|
||||
|
||||
#### Системное время для администратора
|
||||
|
||||
Системный администратор должен следить за тем, чтобы файлы базы данных
|
||||
описания временных зон **tzdata** имели одну версию в рамках комплекса
|
||||
и обновлялись регулярно, чтобы минимизировать расхождения с внешними
|
||||
системами. Особенно это важно делать при издании новых правил учёта
|
||||
зимнего или летнего времени.
|
||||
|
||||
На серверах аппаратные часы всегда должны использовать UTC. Операционные
|
||||
системы тоже должны использовать UTC, чтобы при возникновении проблем
|
||||
в файлах журналов было указано время в едином формате.
|
||||
|
||||
В рамках комплекса следует использовать синхронизацию времени, даже
|
||||
если нет доверенного источника более высокого уровня.
|
||||
|
||||
|
||||
#### Клиентские приложения
|
||||
|
||||
В общем случае нельзя доверять временным отметкам внешних клиентов,
|
||||
так как невозможно гарантировать их корректность. Программа должна
|
||||
самостоятельно ставить временные отметки для происходящих событий.
|
||||
Исключением являются программные комплексы, в которых предусмотрено
|
||||
наличие доверенных приложений, ответственных за установку временных отметок.
|
||||
|
||||
|
||||
#### Postgresql
|
||||
|
||||
Сервер базы данных должен использовать только временную зону UTC. Для этого
|
||||
в файле настройки сервера `postgresql.conf` должна быть строка
|
||||
|
||||
```
|
||||
timezone = 'UTC'
|
||||
```
|
||||
|
||||
При создании таблиц необходимо использовать типы данных `timestamp without time zone`
|
||||
и `time without time zone`. Если данные о времени должны содержать информацию
|
||||
о временной зоне или смещении относительно UTC, то нужно создать дополнительные
|
||||
столбцы, информацию из которых должно обрабатывать клиентское приложение.
|
||||
Например, временные отметки можно хранить в таком виде
|
||||
|
||||
```sql
|
||||
CREATE TABLE time_stamps (
|
||||
time_stamp time without time zone, -- временная отметка
|
||||
time_zone character(12), -- текстовое название временной зоны
|
||||
shift integer -- смещение локального времени относительно UTC в секундах
|
||||
);
|
||||
```
|
||||
|
||||
Смещение следует записывать в четырёхбайтное знаковое целое, так как оно
|
||||
может быть как положительным, так и отрицательным, а его максимальное
|
||||
значение может составлять 14 * 60 * 60 = 50400 секунд. Несмотря на приведённый
|
||||
выше пример с временной зоной Нидерландов, микросекундами можно пренебречь,
|
||||
так как современные временные зоны имеют смещения кратные минутам, а точность
|
||||
до микросекунд в далёком прошлом обычно не требуется.
|
||||
|
||||
Чтобы клиентская программа могла получить выборку, привязанную к некоторой
|
||||
временной зоне можно использовать оператор `AT TIME ZONE`, например
|
||||
|
||||
```sql
|
||||
SELECT TIMESTAMP '2001-02-16 20:38:40Z' AT TIME ZONE 'MSK';
|
||||
```
|
||||
|
||||
В результате время будет преобразовано из временной зоны UTC в MSK.
|
||||
Модификатор `Z` в записи времени указывает на принадлежность зоне UTC.
|
||||
|
||||
|
||||
#### Qt
|
||||
|
||||
Класс `QTimeZone` предназначен для получения информации о временной зоне
|
||||
и перевода времени из одной временной зоны в другую.
|
||||
|
||||
Reference in New Issue
Block a user