Поддержка Юникода в 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.

В форумах люди часто упоминают, что 64-битные версии программ поглощают больший объем памяти и стека. При этом обычно ссылаются на то, что размеры данных стали в 2 раза больше. Однако это необоснованное утверждение, так как размер большинства типов (char, short, int, float) в языке Си/Си++ остался прежним на 64-битных системах. Конечно, например, увеличился размер указателей, но ведь не все данные в программе состоят из указателей. Причины роста потребляемой памяти и стека более сложны. Я решил подробнее исследовать данный вопрос.

В данной заметке я поговорю о стеке, а в будущем планирую обсудить выделение памяти и размер двоичного кода. И еще хочу сразу заметить, что статья посвящена языку Си/Си++ и среде разработки Visual Studio.

Совсем недавно мне необходимо было написать программу для удаленной работы с мускулом. В интернете, как не обидно, нашел лишь «скачайте бла-бла, подключите через include, и вот пример!». На практике не сработало, пришлось искать специалистов чтоб объяснили. Для исправления этого досадного отсутствия информации, выложу полное описание от «А» до «Я» по настройке и работе в среде Visual C++. Итак, приступим!

Данным образом настраивал Visual C++ 2008 и 2010. Т. к. особой разницы в интерфейсе разных версий визуалки нету, то и настройка проходит практически одинаково.

Для того что бы подключить БД, такую как мускул, и играться с ней на чистом API, нужно сначала установить или что бы было установлено такое ПО:
1. «Connector/C++»для 32-х розрядного приложения 32-х розрядный набор библиотек, а для 64-х соответственно 64-х битный набор (скачать можно здесь http://dev.mysql.com/downloads/connector/cpp/ ).
2. Дистрибутив мускула, у меня стоит MySQL Community Server 5.1.59 при установке нужно выбрать либо полную установку, либо выбрать самому весь набор, ну для разработки хватит набора DevCpp.

Одним из популярных и дешёвых средств реализации многопоточных вычислений на языке C++ является OpenMP.

Достоинства технологии очевидны: простота; малые, и легко отключаемые изменения в коде; поддержка от авторов самых популярных компиляторов:

• Visual C++
• GCC 4.2
• Intel C++ Compiler

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

Проходит пара лет, вы успешно мигрируете на Visual Studio 2010,… и обнаруживаете себя сидящим в луже. Если вчера обработка большого массива данных на машинах с многоядерными процессорами проходила за считанные секунды, то сегодня наличие любого фонового приложения, занимающего собственными вычислениями одно или несколько ядер, практически вешает приложение.

Почему так происходит, и как с этим бороться?

Эта статья – описание моих экспериментов по сборке модулей для Python. Мне понадобился высокоуровневый интерфейс к библиотеке LibRaw, притом в первую очередь под Windows.

Последний раз модуль для питона на C++ я писал в 2004 году. Модуль к мертворожденной (к счастью не мной) библиотеке ( я тупо продавал свои умения за зарплату). Естественно, навыки не закрепились. Помню, что SWIG сильно облегчил мне работу, поскольку нужен был объектный интерфейс, а «ручками» его писать ломало. Память у меня профессиональная – то есть избирательная и короткая, поэтому пришлось прыгать сначала.

Это статья только про настройку SWIG для Python под Windows. Писать же модули на C/C++ с использованием SWIG гораздо проще, чем всё настроить (кстати, у меня такое впечатление, что это парадигма современного программирования).

Одной из методик выявления ошибок в программах является статический анализ кода. Мы рады, что это методология становится всё более популярной. Во многом этому способствует Visual Studio, в которой статический анализ является одной из многих функциональных возможностей. Эту функциональность легко попробовать и начать регулярно использовать. Когда человек понимает, что ему нравится статический анализ кода, мы рады предложить ему профессиональный анализатор PVS-Studio для языков Си/Си++/Си++11.

Многие C++ программисты, пишущие под Windows часто путаются над этими странными идентификаторами как TCHAR, LPCTSTR. В этой статье я попытаюсь наилучшим способом расставить все точки над И. И рассеять туман сомнений.

В свое время я потратил много времени копаясь в исходниках и не понимал что значат эти загадочные TCHAR, WCHAR, LPSTR, LPWSTR,LPCTSTR.
Недавно нашел очень грамотную статью и представляю ее качественный перевод.
Статья рекомендуется тем кто бессонными ночами копошиться в кодах С++.

Вам интересно ??
Прошу под кат!!!

Фото Channel9

Только что на Channel 9 закончилась презентация Герба Саттера на конференции BUILD в Редмонде. Кому интересен конспект его выступления с последними новостями про Visual C++ и C++11 в целом — прошу под кат.

Всем доброго {daytime}!

Сегодня пришла пора рассказать вам о фундаментальной проблеме перекодировки при взаимодействии проекта собранного на MS Visual C++ на платформе Windows и наиболее приятной скриптовой обвязки для языка C++, благодаря библиотеке Boost.Python, собственно написанной для языка Python.

Вы ведь хотите использовать для вашего приложения на C++ под ОС Windows хорошую скриптовую обвязку на последней версии Python 3.x, либо вы хотите использовать для вашего приложения на Python максимально ускоренный участок кода вашего модуля, переписанный на C++. В обоих случаях, если вы знаете оба языка как минимум хорошо, вам стоит это прочитать.

Месяц назад Евгений Гречников grechnik опубликовал пост «Стандартная библиотека Visual Studio 2015 и телеметрия», в котором рассказал об интересной находке: оказалось, что в любом бинарнике, скомпилированном VS2015 из программы на C или C++, есть код, который может писать логи — и выглядело это всё слегка подозрительно, особенно в силу отсутствия исходников telemetry.cpp.

Три дня назад этот вопрос был снова поднят на Reddit, где время от времени в комментариях появляются разработчики Visual Studio — и вот сегодня общественности наконец-то удалось получить вполне себе официальный ответ от представителя Microsoft.

Самое важное: телеметрия будет убрана из статических библиотек в обновлении Update 3.

В компиляторе Visual Studio C++ имеется warning C4311 ('variable': pointer truncation from 'type' to 'type') предназначенный для выявления ошибок приведения указателя к 32-битным типам данных. В Intel C++ этому предупреждению соответствует warning #810. Пример обнаруживаемого дефекта:

void *ptr = x;
int y = (int)ptr;

В Win64 размер указателя стал 64-битным, а размер int остался по-прежнему 32 бита. Явное приведение типа обрежет значение указателя, что приведет к ошибке, если указатель ссылается на объект находящимся за пределами младших 4 Гбайт памяти (0x00000000FFFFFFFF).

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

По интернету ходят невнятные слухи о неком WinC++. Толи это просто новое название Visual C++, толи нечто большее. Поскольку я заинтересован и озабочен тематикой Visual C++, то проявил к этой теме внимание. Мне попалась свежая статья от 4 мая «What is WinC++ and how does it figure in Microsoft's bid to make tools a $2 billion business?». Поскольку на русском языке пока про WinC++ тихо, я решил предложить Хабра-сообществу перевод этой статьи. Признаюсь, перевод вышел не очень, читается скучно. Поэтому многие, наверное, предпочтут познакомиться с оригиналом.

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

Итак, собственно перевод статьи Мэри-Джо Фолли: Что такое WinC++ и как она связана со стремлением Microsoft поднять оборот продаж инструментов до 2 миллиардов долларов?

 

Когда мы пишем статьи про проверки каких-либо проектов с помощью PVS-Studio, то, как правило, у нас прибавляется клиентов. Тут все честно. Программисты не любят рекламу, но охотно отзываются на интересные материалы, которые легко проверить. Поэтому мы не рекламируем свой инструмент, а просто показываем, что он умеет. Однако, хотя мы проверили код Chromium уже три раза и трижды находили в нем ошибки, ордера с почтой в google.com в моей почте до сих пор нет. Поскольку мне интересно, что я делаю не так, и почему Google пока не использует PVS-Studio, я решил написать очередную статью.

Эта статья состоит из двух частей. В первой рассказывается об инфраструктуре проекта Chromium и нюансах интеграции, во второй приведены очередные найденные ошибки.

Кстати эта статья опубликована и на английском языке. Если захотите переслать ее англоязычным коллегам – пожалуйста, дайте им ссылку вот на это.

Хотите узнать, почему разрабатывать Chromium сложно и далеко не каждый инструмент для программистов может быть использован в проекте Chromium? Тогда читаем…

Как-то так вышло, что завелся у меня Windows 8 планшет. Не очень удачная модель — громоздкий как помощник, слабоватый как рабочая станция, но зато с стилусом, а самое важное, с 32-битной Win32 системой. Имея некое количество старых игр с распродаж GOG и Steam, я планировал как-нибудь засесть с этой таблеткой и переиграть все, что можно и нельзя. Но вот как-то не хватало времени и настроения, да еще и пробные запуски показали, что играть надо с мышью — курсор от тач-скрина убегал неизвестно куда, да и правый клик долгим нажатием был бы откровенно неудобным. Планшет пылился пол-года в углу до недавней раздачи Fallout от GOG и эта раздача подтолкнула меня к действию. Начинался вечер пятницы, планшет обзавелся USB мышью, а я устроился поудобнее на диване и начал по списку с самого верха — с Arcanum.
Через пол-часа создания персонажа (а ведь это дело очень важное и ответственное!) левая рука с трудом держала устройство, а запястье правой подозрительно начало тянуть, намекая о туннельном синдроме и прочих радостях неудобного хвата. Вспомнив нехорошим словом разработчиков некой эргономичной складывающейся мыши, я полез искать драйвера, патчи или еще хоть что-то, чтобы играть с тачскрина или хотя бы стилуса.
Патчей не нашлось. Единственный похожий драйвер был платным и без пробного режима. Вот в этот момент в голову и пришла идиотская (это я теперь понимаю!) мысль — «там ведь наверняка приходит какой-то WM_TOUCH и неправильно преобразуется в WM_MOUSEMOVE»… Забегая вперед, Арканум теперь у меня полностью управляется с тачскрина, правда, выходные закончились и больше хочется спать, чем играть.

Очень давно все наши статьи стали посвящаться чему угодно, но только не самому инструменту PVS-Studio. Мы рассказываем о проверенных проектах, о тонкостях языка Си++, о создании плагинов на C#, о запуске PVS-Studio из командной строки. А ведь в первую очередь PVS-Studio ориентирован на разработчиков, использующих Visual Studio. Мы очень много сделали, чтобы им было удобно пользоваться нашим инструментом. Но как раз это часто оказывается за кадром. Решил исправить эту ситуацию и рассказать с чистого листа о плагине PVS-Studio. Если вы используете Visual C++, эта статья для вас.