Отладка makefile - это что-то из черной магии. К несчастью, не существует такой вещи как makefile отладчик, чтобы изучить ход выполнения конкретного правила или как разворачивается переменная. Большую часть отладки можно выполнить с помощью обычных print’ов и проверкой makefile. Конечно, GNU make немного помогает своими встроенными методами и опциями командной строки. Один из лучших методов отладки makefile это добавить отладочные перехваты (hooks) и использовать техники безопасного программирования, на которые можно будет опереться, когда дела пойдут совсем плохо. Далее представлено несколько основных техник отладки и практик безопасного программирования, которые будут, на мой взгляд, наиболее полезными.

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

В какой-то момент эта функция перестала работать на моём рабочем компьютере. Незадолго до этого возможность поиска в меню "Пуск" пропала и у моего коллеги.

Также я обнаружил, что не работает поиск в панели задач (если включено отображение кнопки поиска): при вводе текста в панель поиска либо отображается просто чёрное окно, либо - вообще ничего.

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

Долгие поиски на русскоязычных и англоязычных сайтах приводили примерно к одним и тем же результатами: глюки сервисов Microsoft в марте 2020, переиндексация, откат обновлений и прочее. Но результат был нулевой. В итоге, намучившись, переустановил операционную систему, тем более, что давно планировал это сделать.

На днях поиск и контекстное меню снова отказали. Но в этот раз я понял, в чем дело...

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

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

В данном топе книги не упорядочены по важности, они все очень хорошие, но есть одна книга, которая равнее других.

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

Я решил сделать некую подборку мало освещенных возможностей, особенностей. Статья не претендует на уникальность, это и мне, как памятка, и возможно некоторым падаванам поможет, начинающим свой путь с docker-compose.

Всем привет!

Кратко о себе. По образованию я математик, а вот по профессии — программист. В сфере разработки с 2006 года. Хотя, поскольку программирование начали изучать ещё в школе, свои первые программки и игры я начал писать ещё в школе (примерно, с 2003). Так сложилось, что пришлось выучить и поработать на нескольких языках. Если не брать во внимание ВУЗ-овские лекции по С, С++, Бэйсику, Паскалю и Фортрану, то реально я работал с Delphi (более 6 лет), PHP (более 5 лет), Embedded (Atmel + PIC около 2.5 лет) и последним временем Python + чуть-чуть Scala. Конечно же без баз данных тоже никак не обойтись.

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

*Ссылка на библиотеку и демо видео в конце статьи. Для понимания того, что происходит, и кто все эти люди, рекомендую прочитать предыдущую статью.

В прошлой статье мы ознакомились с подходом, позволяющим осуществлять "горячую" перезагрузку c++ кода. "Код" в данном случае — это функции, данные и их согласованная работа друг с другом. С функциями особых проблем нет, перенаправляем поток выполнения из старой функции в новую, и все работает. Проблема возникает с данными (статическими и глобальными переменными), а именно со стратегией их синхронизации в старом и новом коде. В первой реализации эта стратегия была очень топорной: просто копируем значения всех статических переменных из старого кода в новый, чтобы новый код, ссылаясь на новые переменные, работал со значениями из старого кода. Конечно это некорректно, и сегодня мы попытаемся исправить этот изъян, попутно решив ряд небольших, но интересных задач.

В статье опущены детали, касающиеся механической работы, например чтение символов и релокаций из elf и mach-o файлов. Упор делается на тонких моментах, с которыми я столкнулся в процессе реализации, и которые могут быть полезны кому-то, кто, как и я недавно, ищет ответы.

* Ссылка на библиотеку в конце статьи. В самой статье изложены механизмы, реализованные в библиотеке, со средней детализацией. Реализация для macOS еще не закончена, но она мало чем отличается от реализации для Linux. Здесь в основном рассматривается реализация для Linux.

Гуляя по гитхабу одним субботним днем, я наткнулся на библиотеку, реализующую обновление c++ кода налету для windows. Сам я слез с windows несколько лет назад, ни капли не пожалел, и сейчас все программирование происходит либо на Linux (дома), либо на macOS (на работе). Немного погуглив, я обнаружил, что подход из библиотеки выше достаточно популярен, и msvc использует ту же технику для функции "Edit and continue" в Visual Studio. Проблема лишь в том, что я не нашел ни одной реализации под не-windows (плохо искал?). На вопрос автору библиотеки выше, будет ли он делать порт под другие платформы, ответ был отрицательный.

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

"Как так?" — подумал я, и принялся раскуривать фимиам.

Ещё раз о том, почему плохо бросать исключения в деструкторах

Многие знатоки C++ (например, Герб Саттер) учат нас, что бросать исключения в деструкторах плохо, потому что в деструктор можно попасть во время раскрутки стека при уже выброшенном исключении, и если в этот момент будет выброшено ещё одно исключение, в результате будет вызван std::terminate(). Стандарт языка C++17 (здесь и далее я ссылаюсь на свободно доступную версию драфта N4713) на эту тему сообщает нам следующее:

Пару недель назад прошла главная конференция в С++ мире — CPPCON.
Пять дней подряд с 8 утра и до 10 вечера шли доклады. Программисты всех конфессий обсуждали будущее С++, травили байки и думали как сделать С++ проще.

Удивительно много докладов были посвящены обработке ошибок. Устоявшиеся подходы не позволяют достичь максимальной производительности или могут порождать простыни кода.
Какие же нововведения ожидают нас в С++2a?

	std::unordered_map<std::string, std::string> some_map = 
	{
		{ "black", "white" },
		{ "cat", "dog" },
		{ "day", "night" }
	};

	if (auto res = "cat" in some_map)
	{
		res->second = "fish";
	}

Не так давно у меня произошёл очередной разговор с коллегой на извечную тему: "по ссылке, или по значению". В результате возникла данная статья. В ней я хочу изложить результаты моего исследования по этой и смежным темам. Далее будут рассмотрены:

• Регистры и их назначение при вызове функций.
• Передача и возврат простых типов и структур.
• Как передача по ссылке и по значению влияют на оптимизации тела функции компилятором.
• Как используется место при многочисленных вызовах функций.
• Механизм виртуальных вызовов.
• Оптимизация хвостовых вызовов и рекурсии.
• Инициализация структур, массивов и векторов.

Осторожно! Статья содержит большое количество кода на C++ и ассемблере (Intel ASM с комментариями), а также множество таблиц с оценками производительности. Всё написанное актуально для x86-64 System V ABI, который используется во всех современных Unix операционных системах, к примеру, в Linux и macOS.