C++ *

Можно ли уместить исходники MySQL клиента на 1 страничке формата A4? Оказывается, если 8 кеглем (в принципе читаемо) и после обфускации, то можно! А если нормальный код без обфускации и 10 кеглем, то таки нельзя: надо целых 6 страничек.

В ходе работы над всяким у меня тут случайно получился крохотный, но работающий MySQL клиент размером чуть больше 1000 строк. Стало интересно, насколько компактнее можно сделать. Потратил половину воскресенья, изолировал и минимизировал код. В результате появился nanomysql, CLI клиент для MySQL, полные исходники которого занимают чуть менее 380 строк и примерно 10500 байт, и при этом компилируются и работают под Linux, Windows, MacOS. Написано на C++ с абсолютным минимумом STL.

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

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

ИМХО (Имею Мнение Хрен Оспоришь)

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

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

Все основано на реальных событиях, но примеры были максимально упрощены, чтобы в них осталась лишь суть проблемы.

Наше путешествие началось Qt Graphics Framework, нас завербовали его светлой стороной, а потом мы долго получали граблями по разным частям тела.

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

Привет! Ниже речь пойдет об известных всем операторах new и delete, точнее о том, о чем не пишут в книгах (по крайней мере в книгах для начинающих).
На написание данной статьи меня побудило часто встречаемое заблуждение по поводу new и delete, которое я постоянно вижу на форумах и даже(!!!) в некоторых книгах.
Все ли мы знаем, что такое на самом деле new и delete? Или только думаем, что знаем?
Эта статья поможет вам разобраться с этим (ну, а те, кто знают, могут покритиковать:))

Обычно в таких статьях делают заголовок вида «аналог await/async для C++», а их содержимое сводится к описанию ещё одной библиотеки, выложенной где-то в интернете. Но в данном случае нам не требуется ничего подобного и заголовок точно отражает суть статьи. Почему так смотрите ниже.

Предлагается разработать безопасную альтернативу встроенного макроса __COUNTER__. Первое вхождение макроса заменяется на 0, второе на 1, и так далее. Значение __COUNTER__ подставляется на этапе препроцессирования, следовательно его можно использовать в контексте constant expression.

К сожалению, макрос __COUNTER__ опасно использовать в заголовочных файлах — при другом порядке включения заголовочных файлов подставленные значения счетчика поменяются. Это может привести к ситуации, когда например в foo.cpp значение константы AWESOME равно 42, в то время как в bar.cpp AWESOME≡33. Это нарушение принципа one definition rule, что есть страшный криминал во вселенной C++.

Нужна возможность использовать локальные счетчики вместо единого глобального (как минимум, для каждого заголовочного файла свой). При этом возможность использовать значение счетчика в constant expression должна сохраниться.

По мотивам этого вопроса на Stack Overflow.

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

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

Моему сыну, как и многим мальчишкам, нравятся автомобили. Причём чем они больше и необычнее — тем больше нравятся. Когда мы идём по улице, а мимо проезжает эвакуатор или снегоуборочная машина, он неизменно дёргает меня за руку, указывает на заинтересовавший его объект и говорит: «Папа, б-р-р!». Говорит он так потому, что ему один год и вышеуказанные два слова составляют 40% его словарного запаса. Тем ни менее, в общем мысль понятна — обратить внимание на автомобиль. Давайте подумаем, каким образом ребёнок в возрасте 8-10 лет сказал бы своему сверстнику то же самое. Что-то вроде «Ух ты, смотри какая крутая тачка!», да? Мысль та же, но обратите внимание — уже шесть слов вместо двух. И, наконец, представьте, каким образом то же самое скажет человек лет в тридцать: «Эй, смотри, да это же Ferrari California 2008-го года выпуска с двигателем V8 мощностью в 454 лошадиных силы и 7-ми скоростной коробкой-автоматом! Она до сотни разгоняется за 3.9 секунды!». Да, здесь уже больше деталей, но, если вы не автомеханик или фанат Ferrari — они вам скорее всего не нужны и не важны. Основная же мысль — всё та же, что и в «Ух ты, смотри какая крутая тачка!» или «Папа, б-р-р!». Но выражена она уже в 30 слов.

Вы заметили, как абстракция «интересный автомобиль» обросла деталями и нюансами, стала занимать существенно больше места в тексте и времени на понимание, анализ и ответ? То же самое происходит и с программным кодом.

В апреле в Бристоле прошла встреча комитета С++, на которой были рассмотрены первые предложения по внесению изменений в новый стандарт С++14. Все рассматриваемые в этой статье изменения были одобрены на этой встрече и уже занимают свое почетное место в последней версии черновика нового стандарта (N3690 от 15 мая 2013).

Краткий перечень:

• Автоматическое определение типа возвращаемого значения для обычных функций
• Обобщенная инициализация захваченных переменных лямбд с поддержкой захвата-по-перемещению
• Обобщенные (полиморфные) лямбда-выражения
• Упрощенные ограничения на создание constexpr функций
• Шаблоны переменных
• exchange
• make_unique
• Обособленные строки
• Пользовательские литералы для типов стандартной библиотеки
• optional
• shared_mutex и shared_lock
• dynarray

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

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

Программисты допускают невероятное количество опечаток, простых логических ляпов и делают ошибки благодаря Copy-Paste. Приглашаю отпробовать их. Приятного аппетита.

Программисты часто думают, что ошибки, отнимающие больше всего времени очень сложные и коварные. А простые ошибки они не делают.

Зачем это нужно

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

Libcurl — это библиотека интерфейса API для передачи, которую разработчики могут встроить в свои программы; cURL действует как автономная обёртка для библиотеки libcurl. libcurl используется, чтобы обеспечить возможность передачи файлов (адресуемых с помощью URL) многочисленным приложениям (как открытым, так и коммерческим). (wikipedia)

Для iOS можно скачать готовый пример подключения и использования cURL с сайта разработчика. И с iOS всё просто.

Под android мне на просторах google не удалось найти ни одного исходника, где бы производилось успешное обращение к этой кросс-платформенной библиотеке. (Может я плохо искал).

И вообще говоря под android заставить работать cURL оказалось немного сложнее чем хотелось бы.

Как-то раз я решил написать игру. Для себя и в своё удовольствие. Передо мной стоял выбор – использовать всё готовенькое ака Box2D или написать для неё физику самому. Второй вариант показался мне более интересным, и я принялся выискивать в просторах сети информацию, которая помогла бы мне написать всё необходимое. Выискал. Как результат получился очень гибкий(как для игры) и простой физический движок. Основой движка стал метод численного интегрирования Верле.

Вступление

Добрый вечер хабровчане. В данной статье хочу описать проблемы работы в многопоточной среде, с которыми я встретился и пути их решения. Более пяти лет я занимаюсь разработкой игровых проектов на С++ / Objective C++, в оснвоном под платформу iOS. 2 года назад решил попробовать себя в «нативной» разработке используя только Objective-C. Примерно в тоже время меня заинтересовала технология GCD от Apple (как раз после просмотра очередного WWDC). В первую очередь, в этой технологии меня привлекла гибкая возможность делегирования операций между потоками. Довольно распространненой задачей является загрузка каких-либо игровых ресурсов в низкоприоритетном потоке. Но довольно нетривиальной задачей является смена потока по окончанию операции загрузки на главный поток с целью дальнейшей загрузки в VRAM. Конечно можно было закрыть глаза на эту проблему и использовать Shared Context для графического контекста, но ростущий в то время во мне перфикционизм к собственному коду и решениям проектирования графических систем, не позволил поступить так. В общем было принято решение опробовать GCD на «пет» проекте, которым я как раз в то время занимался. И получилось довольно не плохо. Кроме задач решающих загрузку игровых ресурсов я стал использовать GCD там где это было уместно, ну или мне казалось, что это было уместно.

Прошло много времени и вот появились компиляторы полноценно поддерживающие C++11 стандарт. Так как работаю я в текущий момент в компании, занимающейся разработкой компьютерных игр, то особое требование ставится именно к разработке на С++. Большинству сотрудников чужд Objective-C. Да и сам я не питаю особой любви к этому языку (может быть только кроме его обьектной модели построенной по принципам языка Smalltalk).

Почитав спеки по 11 стандарту, проштудировав множество буржуинских блогов я решился написать свой велосипед схожий с Apple CGD. Конечно я не ставлю себе за цель обьять необьятное и ограничился лишь реализацией паттерна «Пул потоков» и возможностью выйти в любой момент из контекста второстепенного потока на контекст главного потока, и наоборот.

Для этого мне понадобились следующие новшевства С++11 — std::function, variadic templates и конечно работы с std::thread. (std::shared_ptr используется лишь для чувства собственного успокоения). Конечно еще одна цель, которую я поставил перед собой — это кроссплатформенность. И очень был разочарован, когда узнал, что компилятор от Microsoft, укомплектованый в VS 2012, не поддерживал variadic templates. Но, поштудировав немного stackoverflow, я увидел, что и эта проблема решается установкой допольнительного пакета «Visual C++ November 2012 CTP».

Мы отправили разработчикам TortoiseSVN на некоторое время бесплатный ключ для анализатора PVS-Studio. Пока они не успели им воспользоваться, я решил быстро скачать исходные коды TortoiseSVN и самостоятельно выполнить анализ. Цель понятна. Очередная небольшая статья для рекламы PVS-Studio.

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

Да, можно сослаться на большое количество низкоквалифицированного персонала, зарплата которого зависит от количества написанных строк кода или от умения долго смотреть на монитор, не моргая. Но такие сотрудники есть практически во всех отраслях. Строители имеют более низкую квалификацию, чем архитекторы, но это не мешает зданиям в большинстве своем быть пригодными для полноценного использования без дополнительных «заплаток».

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

Вторая причина гораздо более прозаична. Невнимание к мелочам. Особенно в начале проекта. И чем моложе команда, тем эффект катастрофичнее. Конечно, гораздо интереснее обсуждать перспективы использования мультиметодов [1], чем следить за тем, чтобы операторы отделялись пробелами. Да и к конечной функциональности подобные мелочи особого отношения не имеют. Не лучше ли сначала сконцентрироваться на первоочередных требованиях, ведь время проекта и бюджет ограничены…

Введение

Данная статья является продолжением цикла статей: Использование паттерна синглтон [1], Синглтон и время жизни объекта [2], Обращение зависимостей и порождающие шаблоны проектирования [3], Реализация синглтона в многопоточном приложении [4]. Сейчас я хотел бы поговорить о многопоточности. Эта тема настолько объемна и многогранна, что охватить ее всю не представляется возможным. Здесь я заострю внимание на некоторых практичных вещах, которые позволят вообще не думать о многопоточности, ну или думать о ней в крайне минимальном объеме. Если говорить точнее, то думать о ней только на этапе проектирования, но не реализации. Т.е. будут рассмотрены вопросы о том, как сделать так, чтобы автоматически вызывались правильные конструкции без головной боли. Такой подход, в свою очередь, позволяет значительно уменьшить проблемы, вызванные состояниями гонок (race condition, см. Состояние гонки [5]) и взаимными блокировками (deadlock, см. Взаимная блокировка [6]). Этот факт уже сам по себе представляет немалую ценность. Также будет рассмотрен подход, который позволяет иметь доступ к объекту из нескольких потоков одновременно без использования каких-либо блокировок и атомарных операций!