Поддержка Юникода в Windows появилась раньше, чем в большинстве остальных операционных систем. Из-за этого многие проблемы, связанные с представлением символов, в Windows решались не так, как в других системах, разработчики которых отложили внедрение нового стандарта до лучших времён [1]. Самый показательный пример: в Windows для представления символов Юникода используется кодировка UCS-2. Она была рекомендована Консорциумом Юникода, поскольку версия 1.0 поддерживала только 65 536 символов [2]. Пять лет спустя Консорциум передумал, но к тому времени менять что-то в Windows было уже поздно, так как на рынок уже были выпущены системы Win32s, Windows NT 3.1, Windows NT 3.5, Windows NT 3.51 и Windows 95 — все они использовали кодировку UCS-2 [3].

Но сегодня мы поговорим о строках форматирования функции printf.

При разработке на C++ время от времени приходится писать код, в котором исключения не должны возникать. Например, когда нам нужно написать не бросающий исключений swap для собственных типов или определить noexcept move-оператор для своего класса, или вручную реализовать нетривиальный деструктор.

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

Например, если у меня есть вот такие типы и функции:

class first_resource {...};
class second_resource {...};

void release(first_resource & r) noexcept;
void close(second_resource & r);

и есть некий класс resources_owner, который владеет объектами типа first_resource и second_resource:

class resources_owner {
   first_resource first_resource_;
   second_resource second_resource_;
   ...
};

то я могу написать деструктор resources_owner следующим образом:

resources_owner::~resources_owner() noexcept {
   // Функция release() не бросает исключений, поэтому просто вызываем ее.
   release(first_resource_);

   // А вот функция close() может бросать исключения, поэтому
   // обрамляем ее try-catch.
   try{ close(second_resource_); } catch(...) {}
}

В каком-то смысле noexcept в C++11 сделал жизнь C++ разработчика легче. Но у текущей реализации noexcept в современном C++ есть одна неприятная сторона...

Компилятор не помогает контролировать содержимое noexcept функций и методов

Возникла тут идея поздравить нашего главного бухгалтера более-менее оригинально, например, с помощью ее любимой программы 1С? Но как?

После некоторых размышлений, пришла мысль использовать для поздравлений фоновое изображение в клиентской области обычных форм для конфигураций на 1С77–1С82 либо во внешнем окне для управляемых форм 1С82 и во всех случаях для 1С83. На нем вывести нужное сообщение и дать ссылки на поздравительное видео, как показано на рисунке.

_{Рис. взят с сайта www.extremetech.com/wp-content/uploads/2016/07/MegaProcessor-Feature.jpg}

Всем доброго здравия!

В прошлой статье я рассмотрел вопрос о проблеме доступа к регистрам микроконтроллера с ядром CortexM на языке С++ и показал простые варианты решения части проблем.

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

Всех кого заинтересовал, добро пожаловать под кат. Кода будет много.

Всем привет. Решил несколько дополнить статью C/C++ из Python.

Передача стандартных типов, таких как int, bool, float и так далее довольно проста, но мало необходима. С такими данными быстро справится и сам python, и вряд ли у кого-то возникнет необходимость вынесения части такого кода в библиотеку C/C++.

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

Тут уже все не так очевидно, и есть ряд вещей, которые думаю можно осветить для тех кто хочет существенно ускорить трудные для интерпретатора python участки кода.

Приведенный под катом пример не очень полезный для применения, но думаю достаточный, чтобы осветить все нюансы данной процедуры.

Про то как вызывать Python из C написал в прошлой статье, теперь поговорим как делать наоборот и вызывать C/C++ из Python3. Раз начал писать об этом, то раскроем всю тему до конца. Тем более, что ни чего сложного здесь нет тоже.

Данная статья посвящена особенностям проверки Unreal Engine проектов с помощью статического анализатора PVS-Studio на операционной системе Windows: как установить анализатор, как проверить проект, где и как посмотреть отчёт об ошибках.

Лето — не только сезон отпусков, но и время плодотворной работы. Солнечные дни так сильно заряжают энергией, что хватает сил и на поздние прогулки, и объёмные коммиты кода. Второй летний релиз PVS-Studio 7.04 получился достаточно большой, поэтому предлагаем вашему вниманию пресс-релиз, в котором обо всём и расскажем.

В прошлом году появилась необходимость дополнить старый проект написанный на C функционалом на Python3. Не смотря на то, что есть статьи на эту тему я помучился и в том году и сейчас когда писал программы для статьи. Поэтому приведу свои примеры по тому как работать с Python3 из C под Linux (с тем что использовал). Опишу как создать класс и вызвать его методы, получить доступ к переменным. Вызов функций и получение переменных из модуля. А также проблемы с которыми я столкнулся и не смог их понять.

В большинстве систем проектирования (САПР) основным представлением моделируемого объекта является граничное представление геометрии или B-rep (Boundary representation). Но все чаще пользователям САПР приходится иметь дело с полигональными моделями, например, полученными в результате 3D-сканирования или заимствованными из онлайн-каталогов.
Чтобы сделать их пригодными для дальнейшей работы, нужно конвертировать полигональную сетку в B-rep модель. А это совсем непросто.
Мы разработали программный компонент C3D B-Shaper, который встраивается в систему проектирования и преобразует полигональные модели в граничное представление. В этом посте покажем алгоритм конвертации и примеры реализации на С++.

Что общего у этих людей, помимо того, что все они известны в мире C++?

• Sean Parent
  
• Eric Niebler
  
• Marshall Clow
  
• Bryce Adelstein Lelbach
  
• Антон Полухин
  
• Андрей Давыдов
  

Ответ: все они приедут на C++ Russia. Теперь, когда лето кончилось и все вернулись из отпусков, пора ждать следующую большую C++-конференцию: C++ Russia 2019 Piter. На ней выступят не только люди из этого списка, но и многие другие международные докладчики. 30 докладов, 2 полных дня с 10 утра до 7 вечера, никаких вводных историй и чтения документации по слогам — сразу сплошной хардкор.

Это оказалась одна из самых быстро и качественно организованных наших конференций, половина программы стала известна уже летом: спикеры чётко знают, какие вещи хотят рассказать на C++ Russia. Сейчас программа почти стабилизировалась, и настало время приоткрыть завесу тайны.

Введение

«Линукс не для игр!» — устаревшая фраза: сейчас появилось много замечательных игр специально для этой замечательной системы. Но всё же, иногда, хочется чего-то особенного, что подходило бы именно тебе… И я решил создать это особенное.

Встреча в Кёльне прошла, стандарт C++20 приведён к более или менее законченному виду (по крайней мере до появления особых примечаний), и я хотел бы рассказать об одном из грядущих нововведений. Речь пойдёт о механизме, который обычно называют operator<=> (стандарт определяет его как «оператор трёхстороннего сравнения», но у него есть неформальное прозвище «космический корабль»), однако я считаю, что область его применения гораздо шире.

У нас не просто будет новый оператор — семантика сравнений претерпит существенные изменения на уровне самого языка.

Для начала несколько комментариев по следам предыдущей статьи. Мы действительно раньше работали в компании Wargaming, где разрабатывали движок, известный как dava.framework или dava.engine. Поэтому многие старые коллеги, с которыми мы по-прежнему в хороших отношениях, активно участвуют в обсуждении.

У ряда людей возникли сомнения: это та же технология или другая? Ответ: это новая технология, написанная с нуля.

Как же мы справились всего за год? Наша команда имеет огромный опыт. Многие занимаются разработкой движков и игр более 15-и лет.

Почему с нуля, если можно было взять наш старый движок, который к тому же лежит в open-source? Ему около 10 лет, и большая часть кода устарела. Даже самые лучшие части движка, которыми мы гордимся, местами содержали куски кода и какие-то рудименты 5-и, 7-и и иногда даже 10-ти летней давности. Многие архитектурные решения были рассчитаны на устройства того времени — начиная с айфона 3G. Сейчас же мы ориентируемся минимум на iPad Air 1 и аналогичные ему по мощности Android-устройства. Соответственно и подходы несколько поменялись.

За прошедшие с момента появления языка C десятилетия было создано множество интереснейших языков программирования. Какие-то из них используются до сих пор, другие — повлияли на следующие поколения языков, популярность третьих тихо сошла на нет. Между тем архаичный, противоречивый, примитивный, сделанный в худших традициях своего поколения языков C (и его наследники) живее всех живых.

Критика C — классический для нашей индустрии эпистолярный жанр. Она звучит то громче, то тише, но в последнее время буквально оглушает. Пример — перевод статьи Дэвида Чизнэлла «C — не низкоуровневый язык», опубликованный в нашем блоге некоторое время назад. Про C можно говорить разное, в дизайне языка действительно много неприятных ошибок, но отказывать C в «низкоуровневости» — это уже слишком!

Чтобы не терпеть такую несправедливость, я собрался с духом и постарался определиться с тем, что есть язык программирования низкого уровня и чего хотят от него практики, после чего перебрал аргументы критиков C. Так получилась эта статья.

В последние годы C++ шагает вперед семимильными шагами, и угнаться за всеми тонкостями и хитросплетениями языка бывает весьма и весьма непросто. Уже не за горами новый стандарт, однако внедрение свежих веяний — процесс не самый быстрый и простой, поэтому, пока есть немного времени перед C++20, предлагаю освежить в памяти или открыть для себя некоторые особо «скользкие» места актуального на данный момент стандарта языка. 

Сегодня я расскажу: почему if constexpr не является заменой макросов, каковы «внутренности» работы структурного связывания (structured binding) и его «подводные» камни и правда ли, что теперь всегда работает copy elision и можно не задумываясь писать любой return. 

Если не боишься немного «испачкать» руки, копаясь во «внутренностях» языка, добро пожаловать под кат.

Всем доброго времени суток. Хочу немного рассказать о своём проекте qt-async, возможно кому-то он покажется интересным или даже полезным.

Асинхронность и многопоточность уже давно и серьезно входит в обиход разработчиков. Многие современные языки и библиотеки разрабатываются с прицелом на асинхронное использование. Язык С++ тоже потихоньку движется в этом направлении — появились std::thread, std::promise/future, должны вот-вот завезти корутины и networking. Библиотека Qt тоже не отстает, предлагая свои аналоги QThread, QRunnable, QThreadPool, QFuture и т.п. При этом виджетов для отображения асинхронных действий в Qt я не нашел (возможно плохо искал, поправьте, если я ошибаюсь).

Поэтому я решил восполнить недостаток и попробовать реализовать такой виджет самому. Многопоточная разработка — дело сложное, но интересное.

Встроенные средства контроля ресурсов используемой оперативной памяти в приложении

Описывается достаточно простое в реализации программное средство контроля используемых ресурсов оперативной памяти в процессе выполнения приложения. Основу реализации составляет перехват и регистрация запросов на выделение, освобождение и повторное использование ресурсов памяти, направляемых приложением операционной системе через вызовы malloc(), calloc(), realloc(), free(). Все запросы памяти регистрируются в специальном журнале и по завершении приложения накопленная информация выводится в форме отчета на консоль или записывается в текстовый файл. Анализ отчета позволяет выявлять случаи неэффективного использования оперативной памяти в приложении. К таковым относятся “утечки” (memory leaks), когда запрошенные ресурсы памяти не освобождаются и не востребуются приложением, фрагментация, когда размеры освобожденных и доступных для повторного использования непрерывных участков памяти оказываются недостаточными для удовлетворения новых запросов, что приводит к выделению дополнительных ресурсов.

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

Всем привет.

Я думаю что вы, если работали с arduino+nema 17, знаете, что запустить несколько двигателей одновременно бывает очень затруднительно.

Есть разные способы решения этой проблемы, самый простой, пожалуй — использование библиотеки NemaStepper. Библиотека упрощает данную задачу во много раз, главное преимущество — она не останавливает выполнение программы. Устанавливается она также, как и все остальные библиотеки. Распространяется по MIT лицензии.

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