При включении аппарат предлагает выбрать систему из следующего списка: iOS 5, MeeGo, Android 3.1 Honeycomb (интерфейс HTC Sense), Windows Phone 7.5 Mango, BlackBerry OS, Android 2.3 (интерфейс Samsung TouchWiz 3.0) и Symbian Anna. Неплохо, правда? Не очень понятно, как некоторые участницы списка будут работать на резистивном дисплее с разрешением 240х400, но попробовать все равно хочется. К сожалению, при ближайшем рассмотрении всплывает обман: из семи операционок на клоне реально работает только одна. Знаете какая? Нет, ни за что не догадаетесь… Не Android. Не Symbian. MEEGO! Нормальная такая MeeGo, а все остальные «системы» представлены в виде накладываемых поверх нее интерфейсов.

Честно говоря, не ожидал такого от наших китайских соседей. Уж слишком плотно они насели на Android, используя его в самых неожиданных устройствах, и вдруг такое. Больше того, источники в Nokia сообщают о наличии в продаже трехсимочного клона N9, и тоже на MeeGo!

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

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

А пока мы можем посмотреть видео о чудо-смартфоне с семью операционными системами на самом понятном в мире языке.

Статья под названием «Acer Aspire S3, ультрабук-первопроходец» опубликована на Хабре, добро пожаловать читать и плюсовать (ну, или минусовать, если не понравится). Но вот представьте, купили вы себе что-то подобное, установили привычные программы и призадумались – эх, а чем бы его таким зарядить, чтобы чувствовалось не только «бук», но и «ультра»? При поддержке моего коллеги Андрея Крупина могу предложить несколько вариантов на подобный случай.

Во-первых, на такой действительно мобильный компьютер можно поставить программу Joulemeter, разрабатываемую Microsoft. Она умеет в режиме реального времени оценивать энергопотребление как аппаратной части, так и каждого приложения в отдельности. Железо, в силу особенно высокой степени его интеграции, у ультрабука особенно не поменяешь, и можно только любоваться на то, как же мало энергии потребляют такие совершенные микросхемы. А вот наблюдения за поведением софта помогут сформировать правильную модель использования последнего, дабы батарея не садилась подольше.

Многим, наверное понравится и программка Luxand Blink!, позволяющая отказаться от ввода пароля или сканирования пальца при входе в свой эккаунт. Достаточно просто заглянуть в объектив встроенной камеры – и все, добро пожаловать. А защищать ноутбук хотя бы паролем надо непременно – мало ли что может случиться в дороге. Самые же ценные данные можно зашифровать при помощи программы, вроде Folder Lock. Я очень-очень надеюсь, что ни мне, ни вам никогда не придется потерять ноутбук, но, право же, в подобных случаях о железке переживаешь гораздо меньше, чем о личной информации, попадающей в лапы непонятно кому.

Возвращаясь к вопросу энергосбережения, вспомним о программке Aerofoil которая поможет детально настроить функциональность ультрабука при питании от сети и от батареи, а потом мгновенно переключиться между настройками. Многое из этого можно проделать стандартными средствами Windows, но придется повозиться, а вещи, вроде интерфейса Aero, все равно надо будет включать/выключать вручную. Лучше сэкономить время, благо программка-то бесплатная.

Мы с вами понимаем, что перечисленное выше ПО написано не для ультрабуков, а «просто так». И вот вопрос – а можно ли придумать что-то особенно полезное именно для этого нового класса мобильных компьютеров? Или это слишком нишевая штука, чтобы ломать голову? Или ничего особенного в ультрабуках, с точки зрения разработчика, нет и не будет?

Поделитесь мыслями, пожалуйста.

Как известно, проще всего придираться, потому что небанальные оборотцы так и лезут в голове. А вот хвалить почему-то трудно. Правда, Дмитрий Рыжков недавно потребовал вообще все обзоры сводить к одному предложению: мол, хочется сразу прочитать вывод, а не продираться через словеса, таблички и графики. Поэтому специально для Дмитрия я напишу, что N9 на MeeGo – это очень интересный и самобытный аппарат, просто феноменально хорошо допиленный для первого блина, каковым он, несомненно, является. А для тех, кто еще не привык к столь коротким формам, допишу еще несколько слов.

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

Прелесть MeeGo именно в продуманной оригинальности. Определенное сходство с коллегами по бизнесу там, несомненно, имеется, но это не тупое копирование, а реализация лучшего варианта из возможных. И за всем ощущается та самая продуманность, свойственная оригинальным вещам. Что же до приятных мелочей, вроде выведения смартфона из спящего режима двойным постукиванием по экрану или мгновенного переключения между приложениями одним «листающим» движением пальца, то такого я просто нигде не видел, и теперь остро чувствую – как не хватает этого на других моих телефонах. Не забываем и о полноценной вытесняющей многозадачности, когда браузер продолжает дорисовывать страничку, даже отправленный в фон, а «тяжелые» игры пробуждаются ото сна мгновенно, словно вы забавлялись с ними всего несколько секунд назад, а не вчера. Для обеспечения этих маленьких чудес N9 потребовался целый гигабайт оперативной памяти, но по нынешним временам это добавляет к себестоимости буквально пару десятков центов.

Также MeeGo воплощает в себе мечту целого поколения разработчиков, когда с одной стороны мы имеем действительно простой, красивый и быстро работающий интерфейс, а с другой – самый настоящий матерый Linux с возможностью допиливания всего и вся, а также установкой DEB-пакетов. Причем линуксовая составляющая спрятана настолько аккуратно, что обычный пользователь может о ней никогда и не узнать, просто пользуясь N9 в свое удовольствие.

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

ОТЛИЧНАЯ операционка получилась, иначе и не скажешь. И потому особенно обидно, что будущее ее сейчас слегка туманно. Получилась бы MeeGo чем-то сыроватым, выглядящим в лучших традициях стиля «инженеры для инженеров», можно было бы и не переживать: ну, возьмут разработки за основу чего-то нового, и в итоге будет хорошо. Однако то, что я вижу, меня очень сильно радует, да и обзоры коллег со всего мира излучают сплошной позитив. Поэтому я выражаю осторожную надежду на некоторую преувеличенность слухов о том, что продолжения банкета не будет. Право же, даже сейчас результат может на равных конкурировать с основными мобильными платформами, а если еще чуть докрутить, да опереться на поддержку разработчиков…

Long Live MeeGo!

P.S. Если хотите прочитать действительно большой текст о первом смартфоне на MeeGo, рекомендую труд Сергея Маленковича, подготовленный при некотором вмешательстве с моей стороны.

Мероприятие получилось одновременно и уникальным, и знаковым. Понимаю, насколько заезжены эти определения, но все же употреблю их, потому что точнее-то не скажешь. Еще ни разу на моей памяти Intel не собирала в России больших конференций для разработчиков, где бы говорилось только программных продуктах. О них обычно было вскользь, после «железа». Теперь же главной героиней стал набор программных средств Intel® Parallel Studio XE с пакетом обновления SP1, а о «железе» вспоминали только если приходилось к слову.

Открывавший конференцию Камиль Исаев, генеральный директор по исследованиям и разработкам Intel в России и СНГ, начал, конечно же, с более глобальных вещей, о чем можно было предположить еще по первому слайду презентации с названием доклада – «Вычислительный континуум и роль программного обеспечения». Камиль говорил о роли программного обеспечения в приближающуюся эру экзафлопных вычислений и о весьма ощутимом вкладе российского подразделения SSG в создание удобных и добротных инструментов для разработчиков.

Специально приглашенной звездой ISC2011 стал Роберт Гева, старший ведущий инженер Intel SSG (вот такие бывают должности). Именно он был изображен на всех баннерах конференции, которая, к слову, рекламировалась, словно рок-концерт. Если, конечно, бывают рок-концерты для программистов. С Робертом у меня связана небольшая история. Во всех материалах конференции его представляли, как американца. Однако по его английскому было очень заметно, скажем так, иностранное происхождение, а мягкое «л» заставляло вспомнить о Ближнем Востоке. Я набрался наглости, подошел к Роберту поинтересовался – откуда он родом? Ну и потом мы отлично поговорили на иврите. Некоторые участники нашего сообщества потом подшучивали – мол, откуда еще быть человеку с фамилией Гева? Так-то оно так, коллеги, но Робертов я среди израильтян-сабр прежде как-то не встречал.

В своем докладе Роберт Гева говорил о средах разработки программного обеспечения, которые поддерживают инструменты Intel, и об их будущем. Затронул общие вопросы развития программного обеспечения, особенности инструментов для высокопроизводительных вычислений и интегрированных решений. Кроме того, Гева рассказал об операционных системах Linux, Windows, Mac OS X и MeeGo и представил прогнозы Intel по каждой из них.

О других докладах я писать, пожалуй, не рискну, боясь исказить пересказом серьезный смысл, и приглашаю посетить страничку с названием каждого из них и краткой аннотацией. Знаете, что на меня произвело самое большое впечатление? Неослабевающее внимание участников. Часто ведь как бывает? Собрался народ с утра, получил раздаточные материалы и сувениры, кое-как досидел до обеда, перекусил, и ищи ветра в поле. А на ISC2011 в Москве большинство участников слушало до последнего, да и в Питере, говорят, была похожая картина.

Значит действительно интересные вопросы подняли, и рассказывали хорошо. Не комом первый блин. И если в будущем конференция распространится на Новосибирск или, скажем, Екатеринбург, я бы с удовольствием последовал за ней

Аннотация

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

PVS-Studio становится все лучше и лучше

Начну с последнего момента, по поводу пользы инструмента PVS-Studio. ReactOS косвенно подтверждает, что PVS-Studio развивается в правильном направлении. Вот новость о проверке ReactOS с помощью такого тяжеловеса, как Coverity - "Статический анализ в Coverity" [1]. Я, конечно, знаю и понимаю, что до возможностей Coverity нам далеко. Но, тем не менее, там, где благодаря Coverity "было найдено несколько новых ошибок", PVS-Studio находит их целый вагон и маленькую тележку. При этом никакой код никуда отправлять не надо. Можно просто взять и проверить проект. Значит мы на верном пути.

Что такое ReactOS?

ReactOS - это современная, свободная и открытая операционная система, основанная на архитектуре Windows XP/2003. Система была написана с нуля и имеет своей целью повторение архитектуры Windows-NT, созданной Microsoft, от аппаратного до прикладного уровня. Объем исходного кода на языке Си, Си++ и ассемблере составляет порядка 220 мегабайт.

Различные ссылки:

• Официальный сайт проекта ReactOS.
• Как принять участие в разработке ReactOS.
• Wikipedia. ReactOS.
• Статья в Компьютерре. ReactOS: догнать и перегнать.
• Lurkmore. ReactOS.

Ошибки в ReactOS

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

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

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

BOOL WINAPI GetMenuItemInfoA(...)
{
  ...
  mii->cch = mii->cch;
  ...
}

На самом деле должно быть написано вот так: "mii->cch = miiW->cch;". Потеряли букву 'W'. Как результат, программы уже не могут доверять функции GetMenuItemInfoA.

А вот другая опечатка в один символ. В этот раз некорректно работает сравнение двух имён.

static void _Stl_loc_combine_names(_Locale_impl* L,
  const char* name1, const char* name2,
  locale::category c)
{
  if ((c & locale::all) == 0 || strcmp(name1, name1) == 0)
  ...
}

Есть путаница между оператором && и &. Очень распространенная ошибка. Встречаю практически в каждом проекте, где работают с битами или атрибутами файлов.

static LRESULT APIENTRY ACEditSubclassProc()
{
  ...
  if ((This->options && ACO_AUTOSUGGEST) &&
      ((HWND)wParam != This->hwndListBox))
  ...
}

Корректный код должен выглядеть так "(This->options & ACO_AUTOSUGGEST)". Пример ниже содержит родственную ей ошибку, из-за которой всё условие всегда ложно.

void adns__querysend_tcp(adns_query qu, struct timeval now) {
  ...
    if (!(errno == EAGAIN || EWOULDBLOCK || errno == EINTR ||
        errno == ENOSPC || errno == ENOBUFS || errno == ENOMEM)) {
  ...
}

Если присмотреться, то можно заметить коварный фрагмент: "|| EWOULDBLOCK ||".

Кстати, в ReactOS нашлось достаточно много условий, которые всегда истинны или ложны. Некоторые нестрашные, так как, например, располагаются в макросе assert(). Но есть, на мой взгляд, и критичные.

INT WSAAPI
connect(IN SOCKET s,
        IN CONST struct sockaddr *name,
        IN INT namelen)
{
  ...
  /* Check if error code was due to the host not being found */
  if ((Status == SOCKET_ERROR) &&
      (ErrorCode == WSAEHOSTUNREACH) &&
      (ErrorCode == WSAENETUNREACH))
  {
  ...
}

Согласитесь, что реализация таких функций как "connect" должна быть протестирована максимально полно. А здесь мы имеем условие, которое всегда ложно. Быстро заметить дефект не так просто, поэтому выделю суть ошибки:

(ErrorCode == 10065) && (ErrorCode == 10051)

Кстати, часть, связанная с сокетами, вообще выглядит сырой. Возможно, это связано с тем, что в Linux мире SOCKET принято объявлять как знаковый тип. А в Windows он беззнаковый:

typedef UINT_PTR SOCKET;

Как результат имеем разнообразные ошибки в операциях сравнения:

void adns_finish(adns_state ads) {
  ...
  if (ads->tcpsocket >= 0) adns_socket_close(ads->tcpsocket);
  ...
}

Выражение "ads->tcpsocket >= 0" не имеет смысла, так как всегда истинно.

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

if (ERROR_SUCCESS == hres)
{
  Names[count] = HeapAlloc(GetProcessHeap(), 0, strlenW(szValue) + 1);
  if (Names[count])
     strcmpW(Names[count], szValue);
}

Зачем вызывать "strcmpW", если результат никак не используется?

Имеются ошибки, связанные с приоритетом операций.

VOID NTAPI
AtapiDmaInit(...)
{
  ...
  ULONG treg = 0x54 + (dev < 3) ? (dev << 1) : 7;
  ...
}

Я расставлю скобки, чтобы стало ясно, как работает это выражение на самом деле:

ULONG treg = (0x54 + (dev < 3)) ? (dev << 1) : 7;

Следующая ошибка обязательно встречается в любом большом проекте. Есть парочка и в ReactOS. Речь идет о лишней точке с запятой - ';'.

BOOLEAN
CTEScheduleEvent(PCTE_DELAYED_EVENT Event,
                 PVOID Context)
{
  ...
  if (!Event->Queued);
  {
    Event->Queued = TRUE;
    Event->Context = Context;
    ExQueueWorkItem(&Event->WorkItem, CriticalWorkQueue);
  }
  ...
}

Ещё мне нравятся ошибки с инициализацией элементов массива. Не знаю почему. Они трогательны. Возможно, я вспоминаю свои первые эксперименты с массивами на языке Basic.

HPALETTE CardWindow::CreateCardPalette()
{
  ...
  //include button text colours
  cols[0] = RGB(0, 0, 0);
  cols[1] = RGB(255, 255, 255);

  //include the base background colour
  cols[1] = crBackgnd;

  //include the standard button colours...
  cols[3] = CardButton::GetHighlight(crBackgnd);
  cols[4] = CardButton::GetShadow(crBackgnd);
  ...
}

Можно продолжать приводить разные интересные участки кода. К сожалению, тогда статья станет слишком длинной и нужно останавливаться. Напомню, что посмотреть на другие ошибки, найденные мной в ReactOS, можно вот в этом файле. На сладкое только приведу вот этот кусочек кода:

#define SWAP(a,b,c)  c = a;\
                     a = b;\
                     a = c

Пример использования:

BOOL FASTCALL
IntEngGradientFillTriangle(...)
{
  ...
  SWAP(v2,v3,t);
  ...
}

Это – шедевр.

Статический анализ кода

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

Один человек взял и написал в ReactOS вот так:

if ((res = setsockopt(....) == -1))

Код делает не то, что хочется. Корректный вариант: if ((res = setsockopt(....)) == -1). Если придерживаться практики писать константу в начале, то случайно никогда не сделаешь ошибочное присваивание внутри оператора "if". У нас здесь другой тип ошибки. Но если писать код по приведенному правилу, то не получится сделать ошибку и в рассматриваемом выражении: "if (-1 == res = setsockopt(....))".

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

static DWORD CALLBACK
RegistrationProc(LPVOID Parameter)
{
  ...
  if (0 == LoadStringW(hDllInstance, IDS_UNKNOWN_ERROR,
                        UnknownError,
                        sizeof(UnknownError) /
                        sizeof(UnknownError[0] - 20)))
  ...
}

Здесь вначале красиво написана константа 0. Вот только круглая скобка закрывается не там, где надо. Обыкновенная опечатка.

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

В крупных проектах просто необходимы такие вспомогательные технологии, как динамический и статический анализ. Подчеркну:

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

Поясню своё утверждение. В подобных системах невозможно приблизиться к 100% покрытию кода при тестировании с помощью юнит-тестов или регрессионных тестов. Немного уточню. Можно конечно, но затраты на создание и поддержание таких тестов становятся недопустимо высоки.

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

Пример проверки кода, редко получающего управление:

static HRESULT STDMETHODCALLTYPE
CBindStatusCallback_OnProgress(...)
{
  ...
  if (This->szMimeType[0] != _T(''))
    _tprintf(_T("Length: %I64u [%s]\n"), This->Size,
             This->szMimeType);
  else
    _tprintf(_T("Length: %ull\n"), This->Size);
  ...
}

Скорее всего, изначально код был написан неправильно. Потом кто-то заметил, что сообщение формируется неправильно и внес исправление, написав "%I64u". А вот на код по соседству он не обратил внимание. И там по-прежнему имеется некорректный формат "%ull". Видимо ветка вызывается крайне редко. Статический анализ такое не пропустит. Собственно он и не пропустил, раз я могу продемонстрировать этот пример.

Другим хорошим примером может служить большое количество ошибок очистки памяти, которые я увидел ReactOS. Почему их так много, мне понятно. Никто не тестирует, заполнилась память или нет. Во-первых, сложно осознать, что в этих простых местах можно ошибиться. А во-вторых, не так просто проверить очистился внутри функции какой-то временный буфер или нет. Здесь статический анализ вновь на высоте. Приведу только пару примеров. На самом деле я насчитал как минимум 13 ошибок заполнения массивов константным значением.

#define MEMSET_BZERO(p,l) memset((p), 0, (l))

char *SHA384_End(SHA384_CTX* context, char buffer[]) {
  ...
  MEMSET_BZERO(context, sizeof(context));
  ...
}

Очищаем только первые байты массива, так как sizeof(context) возвращает размер указателя, а не структуры.

#define RtlFillMemory(Destination, Length, Fill) \
  memset(Destination, Fill, Length)

#define IOPM_FULL_SIZE          8196

HalpRestoreIopm(VOID)
{
  ...
  RtlFillMemory(HalpSavedIoMap, 0xFF, IOPM_FULL_SIZE);
  ...
}

Перепутаны аргументы при использовании макроса RtlFillMemory. Вызов должен быть таким:

RtlFillMemory(HalpSavedIoMap, IOPM_FULL_SIZE, 0xFF);

Снова о табуляциях и пробелах

Заранее хочу попросить не начинать в комментариях новую бурную дискуссию на эту тему. Я просто выскажу своё мнение. С ним можно быть согласным или нет. Но обсуждать не стоит.

Есть два непримиримых лагеря. Одни за использование табуляции в коде, так как это позволяет подстраивать отображение кода под себя [2]. Другие говорят, что это всё равно не работает и, что нет разумных причин использовать символы табуляции. От табуляции только вред и разъезжающееся форматирование. К их числу отношусь и я [3].

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

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

В стандарте кодирования ReactOS [4] написано хорошее правило с теоретической точки зрения:

Generic note about TABs usage: Don't use TABs for formatting; use TABs for indenting only and use only spaces for formatting.

Example:
NTSTATUS
SomeApi(IN Type Param1,
[spaces]IN Type Param2)
{
[TAB]ULONG MyVar;
[TAB]MyVar = 0;
[TAB]if ((MyVar == 3) &&
[TAB][sp](Param1 == TRUE))
[TAB]{
[TAB][TAB]CallSomeFunc();
...

Поклонники табуляции довольны. Однако я открываю исходные коды ReactOS и наблюдаю во многих местах испорченное форматирование. Почему?

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

Это не шаг назад в оформлении кода! Это шаг вперёд! Это следующий уровень осознания. Теоретическая красота настраиваемых отступов не сочетается с практикой. В первую очередь важно обеспечить однозначное представление кода и легкость разработки в большой команде. В компании Google это понимают. И в их стандарте для форматирования используются только пробелы [5]. Тем, кто ратует за использование табуляции, еще раз рекомендую задумываться, почему распределенная команда высококлассных профессионалов, которые разрабатывают Chromium, выбрала именно пробелы.

И еще раз. Теоретическая красота настраиваемых отступов не сочетается с практикой. Неважно, как красиво звучит теория, если она не работает. А именно так и обстоит дело в ReactOS.

Рекомендую команде разрабатывающей ReactOS модифицировать их стандарт и отказаться от использования табуляции. Любая табуляция должна расцениваться, как ошибка и быть устранена из кода.

Кстати, подобная практика позволит находить вот такие вот безобразия в коде ReactOS:

BOOLEAN
KdInitSystem(IN ULONG BootPhase,
             IN PLOADER_PARAMETER_BLOCK LoaderBlock)
{
  ...
  /* Check if this is a comma, a space or a tab */
  if ((*DebugOptionEnd == ',') ||
      (*DebugOptionEnd == ' ') ||
      (*DebugOptionEnd == ' '))
  ...
}

Последнее сравнение, это сравнение с символом табуляции, а не с пробелом, как может показаться. Нормальный код должен выглядеть так: "(*DebugOptionEnd == '\t')".

Примечание для сторонников табуляции. Не надо мне вновь рассказывать, как правильно использовать табуляции. И это не мой код. Смотрите, вот есть вполне конкретный проект ReactOS. В нем есть плохо отформатированный код. Подумайте, какие действия позволят сделать так, чтобы новый программист мог открыть код проекта и не гадать, какой размер символа табуляции ему необходимо установить в настройках редактора. Мысли в духе "нужно сразу было писать правильно" практической ценности не имеют.

Библиографический список

1. Выпуск новостей ReactOS N79. Статический анализ в Coverity. http://www.viva64.com/go.php?url=722
2. Пора завязывать использовать пробелы вместо табуляции в коде. http://www.viva64.com/go.php?url=725
3. Пора завязывать использовать символы табуляции в коде. http://www.viva64.com/go.php?url=726
4. ReactOS. Coding Style. http://www.viva64.com/go.php?url=724
5. Google C++ Style Guide. http://www.viva64.com/go.php?url=679

Вы, наверное, тоже это видели – планшетный компьютер с 32-нанометровым Atom Medfield, работающий на Android 3.2. Толщина корпуса – 8.9 миллиметра, что лишь на 0.1 миллиметра толще, чем у Главного Планшета на рынке (не будем поминать его имя всуе). Работает все под управлением вполне обычной ОС Android, оптимизированной под Atom, и будущие версии операционной системы Google планируется разрабатывать с прицелом на процессоры Intel. Показанный на IDF прототип, предназначенный для вдохновения многочисленным ODM и OEM, выглядит просто до боли скучно и стандартно. Но в этом ничего страшного нет: главное, что на его примере очень хорошо видны возможности эффективной компоновки обновленной платформы Atom, а добавить в экстерьер рюшечек – дело не хитрое.

Время работы планшета обещают на уровне лучших имеющихся на сегодняшний день аналогов и, знаете, я в это верю. Нет, дело не в умелом укусе симпатичного маркетолога. Просто параллельно с планшетом был показан и смартфон на той же платформе. Практически тот же Medfield, только чуточку потолще (9.5 мм) и версия Android «телефонная» – 2.3. Смартфон вроде бы тоже должен жить от батареи не меньше топовых собратьев на Android (то есть – с утра и до вечера), но пока замеров долгожительства никто не опубликовал – отнесемся к этому предположению со сдержанным оптимизмом. Дело в другом. Пусть даже смартфон проработает половину рабочего дня. Но сам факт, что Medfield можно упаковать до таких миниатюрных размеров, говорит, что в планшете на нем останется просто УЙМА свободного места под большой-большой аккумулятор. А именно в этом и кроется главный секрет долгожительства iPad (эх, не сдержался). Не верите – разберите свой экземпляр или поищите многочисленные видео о потрошении яблочного планшета на Youtube.

Итак – тонкий корпус, Android, стандартный набор приложений, стандартный же экстерьер… Знаете, у меня нет ни малейших сомнений в том, что в ближайшее же время на рынке появятся десятки новых планшетных ПК на Atom. Но этого вообще никто из покупателей не заметит, потому что уже сейчас в больших магазинах планшеты на ARM и x86 кладут в один ряд. А после перехода на Medfield внешние различия между «атом-не атом» вообще исчезнут. Большинству людей абсолютно все равно – что внутри у их гаджетов, лишь бы работало. И, когда не станет остатков внешних различий, мысли об использованной аппаратной платформе будут посещать только маньяков, вроде нас с вами. Покупать же планшеты будут, исходя из экстерьера, цены, качества экрана и других нормальных признаков.

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

Так совпало (впрочем, совпало ли?), что в дни IDF проходило мероприятие разработчика злейшего друга Atom’ов на платформе ARM. Новых моделей там, по-моему, не представили, а развивать платформу, похоже, планируется наращиванием тактовой частоты да числа ядер. Техпроцесс вроде бы скоро улучшат, но когда – не очень понятно. И вот уже выходят телефоны с двухъядерным CPU, работающим на частоте 1.5 ГГц… Нет, работает-то все действительно быстро. Но вот автономность, главное преимущество ARM, отдается в жертву скорости. Наверное, просто нет другого выхода. Да только разве потребителя это волнует?

Есть итоговое ощущение после знакомства с материалами обоих мероприятий, что в грядущем году нам с вами будет очень интересно. А покупателям планшетов – просто ХО-РО-ШО.

Нус, приступим.
Собственно обозревать мы будем 3Q Tablet Qoo! surf Tablet PC модель TU1102T with MeeGo.

Характеристики:

• ОC: MeeGo 1.2 (Kernel 2.6.38.2-8.24-adaptation-pinetrail)
• Процессор: Intel Pineview-M N450 (1.66 GHz)
• Чипсет: ICH8M
• Дисплей: TFT LCD 11.6" (1366*768) Multi-touch
• Память: 1GB 800MHz DDR2 (up to 2GB)
• Жесткий диск: SSD 32GB (64GB option)
• Камера: 1.3MP + встроенный микрофон
• WI-FI: 802.11 b/g/n (Atheros AR9285 Wireless Network Adapter)
• Bluetooth: V2.1 + EDR
• Время работы: до 5 часов
• Battery: Li-Polymer High-energy Battery 4800 mAh
• Разьемы: 2x USB 2.0, 1x 26-pin Connector, 1x Earphone output jack, 1x SDHC slot, 1x SIM card slot, 1x Mini HDMI
• Размеры: 294 x 194 x 13 мм
• Вес: 1 kg
• Цена вопроса: 18 000 руб.

Внешний вид:
Коробка представляет из себя "веcеленкий раскрас" из фиолетового фона и зелёненьких логотипов:

На лицевой стороне коробки гордо наклеено Intel Atom Inside.

На задней стороне коробки приведенно краткое описание характеристик и опять-таки наклейка сведетельствующая о присутствии процессора Intel Atom.

Также на задней стороне есть наклейка от производителя утверждающая, что данное устройство в качестве ОС использует DOS. Каким образом предлагается использовать Tablet PC с такой ОС не понятно. Благо мне этого узнать не пришлось, в лабораторию устройство попало с предустановленной MeeGo 1.2

Теперь откроем коробку и посмотрим, что есть в комплекте:

• Сам планшет
• Зарядник для него
• CD с драйверами для Windows 7
• Quick Start Guide на английском языке
• Гарантийный талон

Если не присматриваться, то лицевая сторона не имеет управляющих элементов, однако в верхнем левом углу есть оптическая кнопка, которую в начале я принял за камеру. Еще присутствуют датчик освещенности, web-камера и микрофон.

На задней стороне располагается кнопка выключения:

На боковой стороне расположены разъемы (слева направо): SIM слот, SDHC слот, MiniJack 3.5, два USB 2.0, mini HDMI, разъем для зарядного устройства:

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

Нижняя сторона:

Операционная система MeeGo:
Как я писал выше планшет попал ко мне в руки с предустановленной ОС MeeGo. Я являюсь счастливым обладателем нетбука с этой ОС и от планшета ожидал, как минимум, такого же удобства использования. Однако, меня постигло разочарование: интерфейс не то, чтобы совсем неудобный, но явно не доработан. Но давайте по порядку.
Первое, что мы решили проверить, так это время загрузки ОС, и тут выяснилась очень интересная подробность. Время загрузки с подключенным внешним питанием составляет всего 28 секунд, а вот на батарее она грузится уже целых 2 минуты 10 секунд. Рискну предположить, что такой разрыв достигается за счет искусственного занижения частоты центрального процессора при работе от батареи.
После того, как система загрузилась, MeeGo встречает нас 6 зонами, в каждой из которых сгруппированы последние открытые файлы.

Первая зона: My tablet. В ней представлен список часто используемых приложений, а также возможность быстрого перехода в настройки.

Настройки, доступные через графический интерфейс, отличаются минималистичностью, однако, не стоит забывать, что мы имеем дело с операционной системой семейства linux, а значит, всё, что угодно, можно настроить через консоль.

Вторая панель: Friends. В ней можно добавить свои аккаунты от социальных сетей, email и jabber

Третья панель: Music. В ней отображается недавно прослушанное, очередь проигрывания, а так же плейлист

Четвертая панель: Photos. В ней показывается список недавно просмотренных изображений, а так же предоставляется возможность создать альбом

Пятая панель: Video. Отображает список последних просмотренных фильмов. Не могу не отметить интересную особенность видеоплеера - при добавлении файла с фильмом на жёсткий диск устройства, он сразу появляется в стартовом меню плеера.

Шестая панель: WEB. Отображает список последних просмотренных страниц в браузере

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

Альтернативный рабочий стол имеет классический вид с ярлыками для запуска установленных приложений.

Из предустановленного софта есть браузер, написанный на webkit, просмотровщик изображений, калькулятор, записная книжка, календарь, контакты, терминал, видео и аудио плеер. Все! Стоит отметить, что все предустановленные приложения разработаны в рамках проекта Meego. Для установки приложений сторонних разработчиков нужно подключить MeeGo Community Repo.

Выводы:
Рассмотренное устройство имеет как достоинства, так и недостатки
Плюсы:

1. Мощный процессор для "планшетника"
2. Присутствие двух USB и одного Mini HDMI портов
3. Долгое время автономной работы
4. Качество материалов и сборки
5. Большой хард
6. Большой объем оперативной памяти.

Минусы:

1. При работе шум кулера временами раздражает
2. Периодически "тупящий" GUI объясняется общей молодостью системы, но всё же, на нетбуке-то всё отлично работает...
3. Также постоянно всплывают недоработки в интерфейсе - например, для работы в терминале приходится подключать внешнюю клавиатуру (вот где пригодились USB-разъёмы!), экранная почему-то не появляется.
4. Отсутствует графический менеджер пакетов - конечно, всё что нужно, я поставил и через консоль, но вкупе с вышеназванной особенностью работы с терминалом, согласитесь, это очень неудобно.

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

PS: Спасибо Корпорации Intel за предоставленное устройство
Обзор подготовили Иванов Сергей и Серебряков Григорий.

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

PVS-Studio сейчас использует внешний препроцессор Microsoft Visual C++, что является существенным недостатком. Препроцессор Visual C++ крайне медленный и имеет ошибки, которые мы не можем исправить. Да, пусть вас не удивляет, что препроцессор работает из вон рук плохо, но это не мешает быстро и правильно компилировать файлы в Visual Studio. Как именно устроен cl.exe я не знаю, но по косвенным уликам могу предположить, что имеется два совершенно разных алгоритма препроцессирования, используемых для компиляции и для создания*.i файлов. Видимо, так удобнее в плане архитектуры компилятора.

В последнее время мы активно занялись поиском альтернативного решения для препроцессирования файлов. И по все видимости, наш выбор остановится на препроцессоре, реализованном в Clang. Предварительные замеры показывают, что он работает в несколько раз быстрее cl.exe, что очень приятно и полезно.

Clang — это новый компилятор для C-подобных языков (C, C++, Objective-C ,Objective-C++, в процессе поддержка C++11). Разработка спонсируется корпорацией Apple. Одной из сильных сторон компилятора Clang является большое количество правил статического анализа кода. Практически, Clang уже используется Apple как инструмент статического анализа.

Clang изначально спроектирован для максимального сохранения информации в ходе процесса компиляции [1]. Эта особенность позволяет Clang создавать развернутые контекстно-ориентированные сообщения об ошибках, понятные как для программистов, так и для сред разработки. Модульный дизайн компилятора позволяет использовать его в составе среды разработки для подсветки синтаксиса и рефакторинга.

Так что, по хорошему, PVS-Studio, возможно, стоило бы основывать именно на Clang, а не на VivaCore [2]. Но теперь уже поздно и всё не так однозначно. В этом случае мы бы слишком сильно зависели от возможностей сторонней библиотеки. Да и поддерживать Microsoft Specific в проекте Clang не спешат.

Однако, мы отвлеклись. Наиболее интересно проверить один анализатор кода другим анализатором кода. Мы это и сделали, раз всё равно уже начали изучать проект Clang.

К сожалению, полноценное сравнение сделать невозможно. Было бы замечательно проверить Clang с помощью PVS-Studio и наоборот. А потом посчитать количество найденных ошибок на одну тысячу строк. Беда в том, что мы можем проверить Clang, а он нас нет. В Clang поддержка MSVC экспериментальная. Плюс дело осложняется тем, что в PVS-Studio уже используются возможности C++11. Простая попытка скомпилировать приводит к ошибкам вида 'Эти расширения языка ещё не поддерживаются'.

Придется ограничиться тем, что удалось найти PVS-Studio в коде Clang. Естественно то, что будет описано в статье, это не все ошибки, которые были найдены. Clang это около 50 мегабайт исходного кода. Я уведомлю разработчиков о найденных дефектах и, если им будет интересно, то они сами смогут проверить свой проект и изучить весь список потенциальных ошибок. Впрочем, они про нас слышали и обсуждали некоторые наши диагностики.

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

Ошибка Copy-Paste N1

static SDValue PerformSELECTCombine(...)
{
  ...
  SDValue LHS = N->getOperand(1);
  SDValue RHS = N->getOperand(2);

  ...
  if (!UnsafeFPMath &&
      !DAG.isKnownNeverZero(LHS) && !DAG.isKnownNeverZero(RHS))
  ...
  if (!UnsafeFPMath &&
      !DAG.isKnownNeverZero(LHS) && !DAG.isKnownNeverZero(LHS))
  ...
}

Диагностика PVS-Studio: V501 There are identical sub-expressions '!DAG.isKnownNeverZero (LHS)' to the left and to the right of the '&&' operator. LLVMX86CodeGen x86isellowering.cpp 11635

В начале код одновременно работает с LHS и с RHS, а потом только с LHS. Причиной тому, видимо, стала описка или скопированный фрагмент строки. Как я понимаю, во втором случае также должна присутствовать переменная RHS.

Ошибка Copy-Paste N2

MapTy PerPtrTopDown;
MapTy PerPtrBottomUp;

void clearBottomUpPointers() {
  PerPtrTopDown.clear();
}

void clearTopDownPointers() {
  PerPtrTopDown.clear();
}

Диагностика PVS-Studio: V524 It is odd that the body of 'clearTopDownPointers' function is fully equivalent to the body of 'clearBottomUpPointers' function (ObjCARC.cpp, line 1318). LLVMScalarOpts objcarc.cpp 1322

Классический Copy-Paste. Функция была скопирована. Было изменено её имя, но не само тело. Правильный вариант:

void clearBottomUpPointers() {
  PerPtrBottomUp.clear();
}

Ошибка Copy-Paste N3

static Value *SimplifyICmpInst(...) {
  ...
  case Instruction::Shl: {
    bool NUW = LBO->hasNoUnsignedWrap() && LBO->hasNoUnsignedWrap();
    bool NSW = LBO->hasNoSignedWrap() && RBO->hasNoSignedWrap();
  ...
}

Диагностика PVS-Studio: V501 There are identical sub-expressions 'LBO->hasNoUnsignedWrap ()' to the left and to the right of the '&&' operator. LLVMAnalysis instructionsimplify.cpp 1891

По всей видимости, хотели написать так:

bool NUW = LBO->hasNoUnsignedWrap() && RBO->hasNoUnsignedWrap();

Ошибка Copy-Paste N4

Sema::DeduceTemplateArguments(...)
{
  ...
  if ((P->isPointerType() && A->isPointerType()) ||
      (P->isMemberPointerType() && P->isMemberPointerType()))
  ...
}

Диагностика PVS-Studio. V501 There are identical sub-expressions 'P->isMemberPointerType ()' to the left and to the right of the '&&' operator. clangSema sematemplatededuction.cpp 3240

Это просто случай, в отличие от пятого примера. Понятно, что хотели написать так:

(P->isMemberPointerType() && A->isMemberPointerType())

Ошибка Copy-Paste N5

static bool CollectBSwapParts(...) {
  ...
  // 2) The input and ultimate destinations must line up:
  // if byte 3 of an i32 is demanded, it needs to go into byte 0
  // of the result. This means that the byte needs to be shifted
  // until it lands in the right byte bucket. The shift amount
  // depends on the position: if the byte is coming from the
  // high part of the value (e.g. byte 3) then it must be shifted
  // right. If from the low part, it must be shifted left.
  unsigned DestByteNo = InputByteNo + OverallLeftShift;
  if (InputByteNo < ByteValues.size()/2) {
    if (ByteValues.size()-1-DestByteNo != InputByteNo)
      return true;
  } else {
    if (ByteValues.size()-1-DestByteNo != InputByteNo)
      return true;
  }
  ...
}

Диагностика PVS-Studio: V523 The 'then' statement is equivalent to the 'else' statement. LLVMInstCombine instcombineandorxor.cpp 1387

А это пример сложной ситуации. Я даже не уверен до конца ошибка здесь или нет. Комментарий мне тоже не помогает. Здесь анализировать код должны создатели. Но всё-таки я думаю, что здесь пример ошибки при Copy-Paste.

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

Вот, например, классическая ошибка в switch

void llvm::EmitAnyX86InstComments(...) {
  ...
  case X86::VPERMILPSri:
    DecodeVPERMILPSMask(4, MI->getOperand(2).getImm(),
                        ShuffleMask);
    Src1Name = getRegName(MI->getOperand(0).getReg());
  case X86::VPERMILPSYri:
    DecodeVPERMILPSMask(8, MI->getOperand(2).getImm(),
                        ShuffleMask);
    Src1Name = getRegName(MI->getOperand(0).getReg());
    break;
  ...
}

Диагностика PVS-Studio: V519 The 'Src1Name' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 211, 215. LLVMX86AsmPrinter x86instcomments.cpp 215

В большом коде просто неизбежны подобные ошибки. Уж очень опасен оператор switch. Можно сколько угодно хорошо знать, как он работает, но всё равно забыть этот проклятый 'break'.

Есть ряд если и не ошибок, то явно бестолковых или подозрительных действий.

Бестолковое действие N1, которое может быть ошибкой

AsmToken AsmLexer::LexLineComment() {
  // FIXME: This is broken if we happen to a comment at
  // the end of a file, which was .included, and which
  // doesn't end with a newline.
  int CurChar = getNextChar();
  while (CurChar != '\n' && CurChar != '\n' && CurChar != EOF)
    CurChar = getNextChar();
  ...
}

Диагностика PVS-Studio: V501 There are identical sub-expressions to the left and to the right of the '&&' operator: CurChar != '\n' && CurChar != '\n' LLVMMCParser asmlexer.cpp 149

Скорее всего, вторая проверка CurChar != '\n' здесь лишняя. Но, возможно, это ошибка и должно быть написано:

while (CurChar != '\n' && CurChar != '\r' && CurChar != EOF)

Бестолковое действие N2, которое точно не является ошибкой

std::string ASTContext::getObjCEncodingForBlock(...) const {
  ...
  ParmOffset = PtrSize;
  // Argument types.
  ParmOffset = PtrSize;
  ...
}

Диагностика PVS-Studio: V519 The 'ParmOffset' variable is assigned values twice successively. Perhaps this is a mistake. Check lines: 3953, 3956. clangAST astcontext.cpp 3956

Бестолковое действие N3, которое я затрудняюсь описать

static unsigned getTypeOfMaskedICmp(...)
{
  ...
  result |= (icmp_eq ? (FoldMskICmp_Mask_AllZeroes |
                        FoldMskICmp_Mask_AllZeroes |
                        FoldMskICmp_AMask_Mixed |
                        FoldMskICmp_BMask_Mixed)
                     : (FoldMskICmp_Mask_NotAllZeroes |
                        FoldMskICmp_Mask_NotAllZeroes |
                        FoldMskICmp_AMask_NotMixed |
                        FoldMskICmp_BMask_NotMixed));
  ...
}

Диагностика PVS-Studio:

V501 There are identical sub-expressions 'FoldMskICmp_Mask_AllZeroes' to the left and to the right of the '|' operator. LLVMInstCombine instcombineandorxor.cpp 505

V501 There are identical sub-expressions 'FoldMskICmp_Mask_NotAllZeroes' to the left and to the right of the '|' operator. LLVMInstCombine instcombineandorxor.cpp 509

Не знаю, это простые дубликаты или должно быть написано иное условие. Затрудняюсь предположить, что здесь должно быть на самом деле.

Есть код, который просто потенциально опасен.

Этот код будет работать до тех пор, пока два enum имеют схожую структуру.

enum LegalizeAction {
  Legal,
  Promote,
  Expand,
  Custom
};

enum LegalizeTypeAction {
  TypeLegal,
  TypePromoteInteger,
  TypeExpandInteger,
  ...
};

LegalizeTypeAction getTypeAction(...) const;

EVT getTypeToExpandTo(LLVMContext &Context, EVT VT) const {
  ...
  switch (getTypeAction(Context, VT)) {
  case Legal:
    return VT;
  case Expand:
  ...
}

Диагностика PVS-Studio:

V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case ENUM_TYPE_B: ... }. LLVMAsmPrinter targetlowering.h 268

V556 The values of different enum types are compared: switch(ENUM_TYPE_A) { case ENUM_TYPE_B: ... }. LLVMAsmPrinter targetlowering.h 270

Имея TypeLegal созвучно Legal, а имя TypeExpandInteger созвучно Expand. Это и стало причиной опечатки. Код работает только потому, что повезло и значения этих имен совпадают.

Заключение

Страшно, когда в компиляторе ошибки находятся?

P. S.

Кажется, я поспешил хвалить Clang. Только что наткнулись на ситуацию, когда при препроцессировании он портит код. Имеем вот такой фрагмент в atlcore.h:

ATLASSUME(p != NULL); // Too .... here
if (*p == '')
  return const_cast<_CharType*>(p+1);

Препроцессор Clang превращает это в:

do { ((void)0);
#pragma warning(push)
#pragma warning(disable : 4548)
 do {__noop(!!(p != 0));} while((0,0)
#pragma warning(pop)
 ); } while(0); // Too .... here if (*p == '')
  return const_cast<_CharType*>(p+1);

Он разместил оператор 'if' после комментария и получилось, что "if (*p == '')" теперь тоже комментарий. В результате имеем некорректный код. Эх, нет счастья в жизни программистов.

Дополнительные ссылки.

1. Wikipedia. Clang. http://www.viva64.com/go.php?url=713
2. Библиотека VivaCore. http://www.viva64.com/ru/vivacore-library/

Планшета нам показали два - TN1002T и TU1102T. Аппаратно они главным образом отличаются диагональю (на без труда вычисляется по названию модели) и разрешением экрана (1366х768 и 1024х600 соответственно), а внутри трудится процессор Atom N450. Разумеется, присутствует набор проводных и беспроводных сетевых интерфейсов (с 3G-модулем для желающих) и веб-камера. Параметры, вроде объема оперативной памяти или жесткого диска (равно как и тип последнего) легко изменяемы, в том числе и в домашних условиях. Интересно, что планшеты собираются в России из комплектующих, прибывших известно откуда. Локализация сборки объясняется не только патриотическими соображениями, но и желанием сохранить полный контроль над компонентами. Первые образцы планшетов прибывали в Россию полностью собранными, но однажды в 3Q столкнулись с тем, что любовно подогнанная версия MeeGo, отлично работающая на предыдущих экземплярах, отказалась запускаться на вновь прибывших. Оказывается, на заводе решили потихоньку заменить одну микросхему, и если Windows к таким вольностям относится довольно благодушно, то MeeGo пока не очень. С тех пор плата, матрица и корпус приезжают порознь, и здесь их собирают воедино, предварительно добавив все необходимое.

С MeeGo все немного хитрее. В 10-дюймовой версии устанавливается версия, подготовленная специалистами "Линукс центр" специально для 3Q. Тот же «Линукс центр» позаботился и об оболочке, делающей версию MeeGo для нетбуков пригодной для использования в планшетных ПК. Стоит заметить, что сборка эта принадлежит 3Q и не предназначена для свободной установки всеми желающими.

А вот на 11-дюймовой модели я увидел до боли знакомый интерфейс WeTab. Оказалось, что его не скопировали, а просто лицензировали у немцев. Знаю, как Дмитрий Оганезов не любит сравнения, и все же скажу: немецкий интерфейс выглядит и работает заметно убедительнее российского. Возможно, дело в форе, которая была у разработчиков WeTab – напомню, они на рынке с октября прошлого года.

Младшая, 10-дюймовая версия планшета TN1002T появится в продаже в июне нынешнего года, и за нее обещают просить не больше 14 000 рублей. А вот TU1102T можно начинать искать на прилавках уже с 10 мая по 18 900 рублей. Мне старшенькую обещали выдать для опытов из первой же официальной партии, тогда и отпишусь о ней подробнее.

А пока с удовольствием сообщаю, что планирую побывать во Львове на украинском IT-фестивале «de:coded». Буду рад общению с участниками Intel Software Network и сочувствующим им лицами

Посмотрите, пожалуйста, вот на эту фотографию.

Правда, симпатяга? И, когда бы не наклейка сзади, никогда не подумаешь, что этот белый кубик работает на архитектуре x86 – уж очень «по-бытовому» выглядит. А вообще система довольно мощная: Intel Atom Media Processor CE4100 с ускорителем SGX535, дополнительный аппаратный декодер, благодаря которому кубик отлично отрабатывает FullHD, гигабайт памяти DDR3, HDMI 1.3a, тюнер Multi DVB, жесткий диск внутри и полный набор сетевых интерфейсов.

А работает все под управлением хитрой операционной системы на ядре MeeGo 1.0. Не вздумайте морщиться по поводу недостаточно новой версии ядра: все выглядит весьма достойно, а скорость реакции Cubovision на действия пользователя впечатляет. Дама из американского офиса Intel сказала, что сейчас в компании очень много сил брошено на доработку связки Atom&MeeGo, и в октябре нынешнего года ожидается мегапрорыв. Последний, думается, связан с выходом MeeGo 1.3, где функционал Smart TV будет реализован максимально полно. Сейчас допишу этот текст и еще раз поговорю с дамой - уже под диктофон.

Но, увидев лишь одно решение, я бы не рискнул говорить о массовом применении Atom. Вот только несколько его собратьев, которых успел отснять на данный момент.

Этого предлагает D-Link. Система работает под Linux, но, по словам моей собеседницы, есть хорошая вероятность переезда на MeeGo – только чуть попозже.

Обратите внимание – какой у него интересный пульт-перевертыш.

Этот Amino тоже на Atom и тоже на ядре MeeGo, только надстроек там еще больше. Тоже буду разбираться подробнее.

А данный продукт тоже на Atom, но система в нем – Microsoft Windows Embedded 7 Consumer Edition. Интерфейс один в один, как на Windows Phone 7.

По соседству всем желающим предлагается готовая аппаратная платформа на Atom – подбирай красивый корпус, пиши софт

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

Вот такие неожиданные открытия. Ждали-ждали мы завтра, а оно взяло и незаметно наступило.

Побежал дальше.