Вырвано из G+:

• https://cpp.libhunt.com/

С сайта:

A curated list of awesome C/C++ frameworks, libraries, resources, and shiny things

Систематизированный список библиотек для решения различных задач на C++. Пока ограничен битбакетом и гитхабом, поэтому добавить некоторые полезные библиотеки за пределами этих площадок пока (?) возможности нет.

Список раньше хостился на GitHub, теперь обрёл второе рождение в виде сервиса.

Система рейтингов и меток должна помогать выбирать полезное. Как будет работать на самом деле - покажет время.

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

На первомайские планировали сходить немного траверса по Партизанскому хребту с заходом на г.Синяя. Заход: по р.Икрянка от села Ястребовка. Выход: р.Правая Икрянка в село Ястребовка.

Идея поста родилась при употреблении чая во внутрь на южной кухне.

Недавно смотрел один доклад (точнее бегло просматривал) про Rust и в момент, когда начался рассказ про life-time, глаз зацепился за такой опасный пример из мира C++:

string get_url()
{
  return "http://htrd.su";
}

string_view get_schema(string_view v)
{
  // тут какие-то действия, я их опущу
  auto result = v;
  return result;
}

int main()
{
  auto v = get_schema(get_url());
}

Что такое string_view - смотреть тут или тут. Если коротко - это невладеющая строка. Полезна для экономии на аллокациях, когда нужно работать с частями исходной строки.

В общем, из природы string_view следует и проблемы в коде выше: get_url() вернёт временный объект, который будет уничтожен в конце выражения, а следовательно, v будет ссылаться на невалидный участок памяти.

У меня в голове родилось, сходу, вариант защиты от такого: так как string_view не владеет строкой, то перемещение для строки сделать невозможно (да и семантически неверно), а перемещающий конструктор будет предпочтён для временного объекта. Следовательно если сделать перемещающий конструктор для string у string_view удалённым, то код выше сломается на этапе компиляции.

Пост для истории. Основные посылы, которые “не позволили” мне воспользоваться конвертером для ручки Platinum Balance можно почитать на penmania.ru.

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

Навеяно.

Из того, что мне понравилось:

1. SDL2 * Язык: C * Реализация: библиотека * Реально проста для простых применений. Куча примеров и статей в интернете. Поддерживает достаточно большое число платформ и компиляторов.
2. CImg * Язык: C++ * Реализация: header-only * Библиотека отличается феноменальной простотой установки: только один заголовочный файл и всё. Минусом будет только тот факт, что нужно будет указать правильные флаги линковщика для целевой платформы. Но при этом весь базовый функционал для рисования и процессинга изображений присутствует. Дружится с OpenCV. Думаю, стоит рассматривать вариант этой библиотеки, когда нужно что-то по-быстрому нарисовать.
3. SMFL * Язык: C++ * Реализация: библиотека * С данной библиотекой особо не имел дел. Но примеры представляют её эдаким вариантом SDL, но на C++. Стоит попробовать.

Кроме того, на ресурсе cppreference.com есть свой список библиотек под различные задачи (в дополнение к предыдущему посту), и, в частности, для графики.

ЗЫ по ссылке выше есть интересная библиотечка для пользовательского интерфейса (GUI): nana, стоит пощупать. А так же для TUI: cwidget.

ЗЗЫ прочие ссылки:

• A Proposal to Add 2D Graphics Rendering and Displayto C++
  • https://cristianadam.eu/20160228/introducing-c-plus-plus-experimental-io2d/ - разбор этого пропозала, референсная реализация
    • https://github.com/mikebmcl/N3888_RefImpl/ - оригинальная референсная реализация
    • https://github.com/cristianadam/io2d - форк от автора статьи

На RSDN промелькнуло, может ещё кому полезно будет:

• Awesome Modern C++ - A collection of resources on modern C++

Кто хочет дополнить - шлите мёрж-реквесты.

Прочие полезные ссылки, спасибо @sikmir:

• C++ links - A categorized list of C++ resources. Assembler, Lock-free и иже с ними.
• Awesome C/C++ - A curated list of awesome C/C++ frameworks, libraries, resources, and shiny things. Inspired by awesome-… stuff.
  • http://fffaraz.github.io/awesome-cpp/

Пока речь пойдёт про алиасы (alias) для man. Потом, может быть, что-то будет дополнено.

MAN

Часто возникает вопрос: “man чаво?”. Кроме того, интересные программистам документы, обычно, находятся в секциях 2 (системные вызовы), 3 (библиотечные вызовы) и 7 (стандарты, соглашения, обзоры). По назначению других секций можете спрашивать: man # intro

где # - номер секции от 1 до 7.

В общем родилось три алиаса: для обращения и для поиска.

Для использование, код ниже поместить в ~/.bashrc

alias man-prog='man -s 2,3,7'
alias man-prog-search='man -s 2,3,7 -K'
alias man-prog-apropos='man -s 2,3,7 -k'

Первый - просто ограничивает область поиска и по man-prog printf выведет не описание команды, а описание функции.

Второй - обеспечивает полнотекстовый поиск по страницам, третий - по индексу (apropos). В чём разница. Поясню на примере:

$ man-prog-apropos tcp
clnttcp_create (3)   - library routines for remote procedure calls
clock_getcpuclockid (3) - obtain ID of a process CPU-time clock
getcpu (2)           - determine CPU and NUMA node on which the calling thread is running
pthread_getcpuclockid (3) - retrieve ID of a thread's CPU time clock
QwtCPointerData (3)  - (неизвестный объект)
sched_getcpu (3)     - determine CPU on which the calling thread is running
svctcp_create (3)    - library routines for remote procedure calls
tcp (7)              - TCP protocol
zmq_tcp (7)          - 0MQ unicast transport using TCP

Вроде всё хорошо. Дальше:

$ man-prog-apropos TCP_CORK
TCP_CORK: ничего подходящего не найдено.

Оппа… В гуголь лезть? А если так:

$ man-prog-search TCP_CORK
--Man-- след: sendfile(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: sendfile64(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: sendmsg(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: sendto(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: splice(2) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]
--Man-- след: tcp(7) [ просм (ввод) | пропуск (Ctrl-D) | выход (Ctrl-C) ]

в man 7 tcp мы найдём искомое описание.

Сначала немного информации из мира С.

При запуске приложения (речь идёт о POSIX) вместе с ним открывается 3 файловых дескритоптора:

• 0 - ассоциирован со стандартным вводом (stdin)
• 1 - ассоциирован со стандартным выводом (stdout)
• 2 - ассоциирован со стандартным выводом в поток ошибок (stderr)

В стандартной библиотеки Си используется FILE*-based буфферизируемый доступ к файлам и терминалу. В stdio.h объявлены следующие глобальные символы, которые отражают стандартные потоки ввода вывода:

• stdin
• stdout
• stderr

Соответственно их свободно можно использовать вместе с семейством функций fread()/fprintf(), обеспечивая буфферизированный доступ.

Сами файловые дескрипторы POSIX объявляет через макросы в unistd.h:

• STDIN_FILENO
• STDOUT_FILENO
• STDERR_FILENO

Соответственно их свободно можно использовать со всем семейством функций read(), write() и, даже, select()/epoll() и fcntl() (например, при помощи fcntl(O_NONBLOCK)+select+read можно реализовать аналог [getch()](http://www.codenet.ru/progr/cpp/spr/175.php) из старого доброго Borland C++). Доступ через эти функции не буфферизирован.

Доступ к одному потоку разными механизмами в одной программе лучше не осуществлять: буферизация это уровень библиотеки C и внутреннего устройства FILE. write() или read() ближе к системным вызовам и ничего про это знать не обязаны. Как результат можете получить перемешивание текста даже в однопоточном приложении. Это не отменяет того файла, что сам fwrite() может, в конце концов, вызвать write().

На этом экскурс закончим и вернёмся в C++.

В C++ для работы с потоками служит библиотека [iostream](http://www.cplusplus.com/reference/istream/iostream/). Причём доступ к конкретному стриму может быть как буфферизируемым так и не буфферизируемым (зависит от потребностей).

Библиотека декларирует объекты, связанные со стандартными потоками:

• std::cin - стандартный ввод
• std::cout - стандартный вывод
• std::cerr - стандартный вывод ошибок и
• std::clog - для логирования

Про std::cin особо гооврить (пока?) не будем - он один, в своём роде. А вот про оставшиеся три стоит.

Итак, начнём с std::cout и std::cerr. В C++ они, помимо того, что связаны с разными дескрипторами, несколько отличаются поведением:

• std::cout - буферизируемый
• std::cerr - не буферизируемый

Такое отличие явственно следует из семантики использования: ошибку нужно увидеть сразу без ожидания каких-то дополнительных действий со стороны программиста типа std::flush или std::endl (он, кстати, делает и flush, поэтому, для большей производительности строки в нормальном выводе стоит заканчивать ‘
n’, а не std::endl).

Ок, а что за std::clog? А это всего-лишь std::cerr + буферизация. И снова, семантика использования проста: диагностика может чуть и подождать, что бы не понижать производительность вывода, но смешиваться с нормальным выводом не есть хорошо, мы, ведь, можем использовать приложения в пайпе и, желательно, разделить диагностику и ошибки от обычного вывода.

Собственно, немного обобщая:

• std::cout - используется для обычного вывода результатов работы программы на экран, эти данные могут быть переданы дальше по пайпу для обработки.
• std::cerr - вывод сообщений об ошибке в обработке, что бы не подмешивались в основной поток и не ломали логику работы других программ в пайпе. При этом сообщение выводим максимально скоро.
• std::clog - используем для разного рода диагностических сообщений, но когда использование std::cerr замедляет вывод из-за более частого дёргания системных вызовов, при этом, не подмешиваемся в основной поток и не мешаем работе других приложений в пайплайне.

Хорошим тоном, так же, является вывод справки по программе в std::cout, если вызвано с параметрами -h|--help - тогда её удобно смотреть в, например, less без дополнительных телодвижений, а вот справку по опциям, в случае неправильной установки какого-то параметра (или пропуска обязательного), лучше выводить (тут особой разницы не вижу) в std::cerr или std::clog.

И, на последок, лекция по поводу тормозов iostream и вообще, а как оно там внутри устроено:

• https://events.yandex.ru/lib/talks/3309/ - просмотр строго рекомендован.

Недавно на ru.SO проскочил вопрос: как можно подключиться к SSM ( Source Specific Multicast) группе?

Нюанс в том, что для этого используется опция MCAST_JOIN_SOURCE_GROUP для которой нет объекта-обёртки. Но, как оказалось, такой объект пишется самостоятельно на раз-два. Под катом я продублирую свой ответ, как пример подхода реализации нужного функционала. Пример не самый идеологически правильный, но, как оказалось, рабочий. Автор сам предложил свой вариант с захватом сырого хендла. Такой подход тоже имеет смысл в некоторых ситуациях((у меня случилось однажды так подружить сетевые абстракции Asio и libev, реализовав, тем самым, реактор на Asio :simple_smile:)).

23 февраля решили отпраздновать очередным снегоступингом.

По предложению Кирилла рассматривали варианты посещения южных отрогов Ливадийского хребта.

Маршрут изначально рассматривался как:

Фокино-г.Халаза-г.Горбуша-г.Лысый дед-Молёный мыс

но в результате был скорректирован до:

Душкино-падь Светланка-г.Круглая-г.Пидан-Лукьяновка.

Собралось три человека: я, Кирилл, Саня. В роли адового тропильщика в этот раз Кирилл.