В более ранних постах было рассказано про многопоточность в Windows при помощи CreateThread и прочего WinAPI, а также многопоточность в Linux и других *nix системах при помощи pthreads. Если вы пишите на C++11 или более поздних версиях, то вам доступны std::thread и другие многопоточные примитивы, появившиеся в этом стандарте языка. Далее будет показано, как с ними работать. В отличие от WinAPI и pthreads, код, написанный на std::thread, является кроссплатформенным.

Мне лично в языке C++ всегда казалась довольно сложной для понимания тема всех эти copy assignment’ов, move constructor’ов, perfect forwarding’а и вот этого всего. Поскольку без этих знаний в современном C++ далеко не уедешь, решил попробовать во всем разобраться. Не могу сказать, что теперь владею материалом в совершенстве, но на небольшую заметку-введение вроде наскреблось. Авось кому будет интересно.

Необходимость написания многопоточных приложений возникает весьма и весьма часто. В мире C/C++ эту задачу можно решать по-разному. Так в стандарте C++11 и старше есть std::thread и другие примитивы. Также поддержка трэдов есть в стандарте C11 (threads.h). Однако если эти стандарты вам по каким-то причинам не доступны, или ваше приложение не планируется в обозримом будущем портировать под Windows, можно воспользоваться старой-доброй библиотекой pthreads.

Хочется думать, что объяснять, что такое класс-синглтон, или он же паттерн «одиночка», читателям данного блога не требуется. Если вдруг это не так, вам поможет, например, соответствующая статья на Википедии. Мне же хотелось бы поделиться кое-какими мыслями касательно неоднозначного отношения к данному паттерну, следует ли его вообще использовать, и если да, то когда.

Регулярные выражения могут быть чрезвычайно полезны при решении множества задач. Пару лет назад в этом блоге рассматривались регулярные выражения C++11 (std::regex). Однако тогда они показали себя не очень хорошо (стоит отметить, что ситуация уже могла измениться к лучшему), да и в чистом C этими регулярками не воспользуешься. Поэтому в данном посте мы познакомимся с более консервативным, зато проверенным временем и гарантированно работающим подходом, заключающимся в использовании библиотеки libpcre.

Некоторое время назад мы с вами познакомились с Autotools. Несмотря на то, что Autotools до сих пор используется во многих известных проектах с открытым исходным кодом, инструмент этот трудно назвать особо удобным. Кроме того, нормально работает он только в *nix системах, а в каком-нибудь Windows пользоваться Autotools, скажем так, весьма непросто. В общем, Autotools — это легаси, и нормальные программисты в наше время пытаются использовать CMake или, например, SCons. В этой заметке мы познакомимся с CMake.

Если вы пишете код на языке C или C++, поиск и устранение ошибок работы с памятью, таких, как утечки, выход за границы массива или обращение к неинициализированной памяти, могут доставить немало хлопот. Существует по крайней мере два инструмента для решения этих проблем — Valgrind (не путать с Vagrant!) и Clang’овский MemorySanitizer. Последний работает исключительно под Linux и показал себя несколько сырым и не слишком гибким инструментом, поэтому поговорим о Valgrind. Он довольно гибок и работает везде. Кроме того, в отличие от MemorySanitizer, Valgrind может находить неинициализированные данные с точностью до одного бита. Из недостатков Valgrind стоит отметить сравнительно низкую скорость работы.

Продолжая серию постов о полезных библиотеках в мире C/C++, стоило бы упомянуть хотя бы одну библиотеку для сжатия данных. Библиотек таких великое множество. Среди них, пожалуй, наиболее распространенной, своего рода стандартом де-факто, является zlib. Поэтому о ней далее речь и пойдет.

Нет причин не продолжить наше с вами изучение библиотек для языка C. Ранее в этом блоге рассматривались библиотеки libcurl, libpcap, а также некоторые сильно менее распространенные. Сегодня же мы узнаем, как программы на C могут работать с реляционными базами данных.

Рассмотрим типичную задачу. Есть программа на C или C++ с исходниками. Известно, что при выполнении определенных условий программа начинает отжирать слишком много памяти. Нужно понять, почему это происходит, и по возможности исправить. Инструменты, которые мы рассматривали до этого, например, в заметке Профилирование кода на C/C++ в Linux и FreeBSD, для этого явно не подходят. Спрашивается, что же тогда делать? На помощь приходит Heaptrack!