Попался мне как-то в руки в личное пользование ноутбук Lenovo X201 — отличная рабочая машинка.
Всё в нём вроде хорошо и всё вроде есть, но как обычно хочется большего — захотелось встроенный WiMax иметь (3G модем уже в нём есть и довольно хорошо работает).



Для WiMax была приобретена карта Intel WiMax/Wifi Link 5150 PCIe Mini Card.
После установки выяснилось, что оказывается большинство современных ноутбуков (в частности Lenovo) имеют White-list устройств, которые они поддерживают. Сделано это видимо для того, чтоб пользователи покупали только фирменные устройства в фирменных магазинах. Честно говоря я бы рад купить такое устройство, если бы у нас они свободно продавались (поправьте меня, если это так, может я не достаточно хорошо искал).
В частности мой ноутбук расстроился, увидев, что карточки, которую я ему подсунул нет в White-list и выдал мессагу:
1802: Unauthorized network card is plugged in - Power off and remove the miniPCI network card.
В случае установки неподдерживаемого 3G модема, вы получите сообщение:
1804: Unauthorized WAN card is plugged in - Power off and remove the WAN card.

Для меня красота C++ заключается, в первую очередь, во вседозволенности и ужасающей мощи языка. Мы можем работать с памятью так же плотно, как и в C, и в то же время имеем такие средства абстракции, как шаблоны и STL, где параметризовать можно что угодно и чем угодно.
Плата за это соответствующая — не всегда вразумительные ошибки компилятора (попробуйте забыть поставить точку с запятой после определения класса), очень большой срок подготовки и обучения программистов, но самое главное — некоторые баги становятся заметными только во время исполнения программы.
Мы хотим больше полезных ворнингов до запуска наших программ. Одно из средств получения желаемого — статический анализ кода. Статический — значит, не запуская программу. Интересны не только вероятные ошибки, случаи undefined behaviour, утечки памяти, но и вещи вроде недоступности/неиспользуемости кода, рекомендации по повышению интуитивности стиля программирования.

Начало

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

В качестве основы разработки была выбрана библиотека Qt, Так как до этого все проекты на предприятии велись в Delphi, мы стали первооткрывателями этого мощнейшего инструмента. До этого никто из нас не занимался разработкой коммерческих продуктов с использованием библиотеки Qt.

Падение программы — это очень гадкая вещь. К сожалению все мы не идеальны и даже применяя наиболее безопасные методы разработки (например TDD) мы не застрахованы от того что программа свалится. Особенно плохо, если она свалится уже у заказчика. Но на пути к идеалу у нас всегда есть инструментарий, который может помочь расследовать падение программ, выявить ошибки, а главное исправить их.
Одно грустно, что многие, даже очень опытные разработчики не знакомы с этим инструментарием и многие компании не включают данную практику в свою работу. Я говорю о postmortem отладке.
В данной статье я хочу показать азы работы с данным зверем и возможно подтолкну этим самым разработчиков на расширение своих познаний в области оладки. Итак, приглашаются к чтению C++ Windows разработчики, тим-лиды, ну и руководителям отделов разработки будет неплохо ознакомиться.

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

Читатели наших статей, посвященных разработке 64-битных приложений, часто упрекают нас в отсутствии обоснованности описываемых проблем. А именно, что мы не приводим примеры ошибок в реальных приложениях.

Я решил собрать примеры различных типов ошибок, которые мы сами обнаружили в реальных программах, о которых прочитали в интернете или о которых нам сообщили пользователи PVS-Studio. Итак, предлагаю вашему вниманию статью, представляющую собой коллекцию из 30 примеров 64-битных ошибок на языке Си и Си++.

Продолжение статьи >>

Интересная на мой взгляд статья, которая показывает, что одни и те же принципы никогда не устаревают. Конечно, все они уже часто проскакивали в той или иной форме на множестве ресурсов, но мне бы хотелось предложить вам их видение Ученым с большой буквы, Альбертом Эйнштейном.

Итак, в новостях снова пишут, что кто-то еще умер из-за игромании. Да, опять Корея.

Какого ...? послушайте, я не пытаюсь доказать что видео игры — это героин. Я полностью понимаю, что в данном случае у жертвы было много проблем в жизни. Но, половина из вас знает что World of Warcraft затягивает и что доктора считают игровую зависимость серьёзной проблемой. А вопрос вот в чем: может быть какие-то игры намеренно разрабатывались, чтобы заставлять вас играть в них, даже если вы не получаете от этого удовольствия?

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

Интернет – это не только web. Помимо контента (и устройств его хранения и обработки), отображаемого на web страницах важны ещё и линии связи. Причём важнее всего дальнемагистральные направления, т.к. провайдеров в городе может быть несколько, а вот соединение между городами и странами могут обеспечить немногие. Тем более, если речь идёт о разных континентах, тогда приходится топить сотни километров оптоволокна в пучинах мирового океана.

Возможно в Вашем проекте и не пишут try { /* code */ } catch(...) { } для того чтобы избежать исключений при работе с памятью, умеют закрывать хендлы и знают о виртуализации Windows Vista, а программы никогда не падают по непонятным и редко повторяемым причинам.

Тогда Вам повезло, можете переходить к следующему топику.

Утечка памяти — довольно серьезная и опасная проблема. Быть может, пользователь и не заметит однократной утечки каких-нибудь 32Кб памяти (а ведь это целые 5% от 640Кб, которых «хватит всем»), но постоянно теряя сложные иерархические структуры или массивы размером больше INT_MAX (которые мы так любим создавать на 64-битной архитектуре) мы обречем его на страдания, а наш продукт на провал.

Не допускать ситуации вроде бы и не трудно — воспользуемся правилом «класть на место всё что взяли», но на практике это сильно осложняется человеческим фактором (банальная невнимательность), хитростью архитектуры и нелинейным порядком выполнения операторов, например, из-за применения исключений.

А можно было бы просто «отдаться» автоматическому сборщику мусора, ценой потери производительности (и это не обязательно Managed C++, для Native C++ / C есть библиотеки сборки мусора, вот, например).

Но мы поговорим о ситуации когда уже «всё плохо».