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

Виды сенсоров

Не берусь говорить точно о том, какие именно датчики будут устанавливаться, но скорее всего в стандартный набор будут входить:

• Датчик освещенности
• Акселерометр
• Компас
• Датчик ориентации
• GPS

Зачем они нужны

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

Благо предпосылки к созданию программ, работающих с сенсорами, появились еще в Windows 7 - Sensor and Location Platform. Это унифицированный интерфейс взаимодействия с сенсорами, который позволяет избежать неразберихи, когда каждый датчик поставлялся со своими драйверами и своим API.

Как начать использовать сенсоры уже сейчас

С софтом разобрались, теперь про железо - ультрабуков с сенсорами на борту на рынке пока нет. Что делать, если уже чешутся руки попрактиковаться и создать что-то новое, уникальное?

Существуют два варианта:

• Использовать сторонний датчик (набор сенсоров), например, от Freescale или STMicroelectronics
• Использовать датчики, которые уже есть, практически у каждого - сенсоры смартфона

Далее я как раз и хочу рассказать о втором пункте, на примере использования смартфона на базе ОС Android в качестве «донора» данных.

Однажды, в поисках подобного решения я наткнулся на интересное приложение - PCRemote, которое представляет из себя программу для удаленного управления компьютером с помощью устройств, работающих под Android. В сети полно подобных проектов, но этот оказался интересным потому, что предлагал использовать не только сенсорный экран (как множество других проектов) для управления компьютером, но и акселерометр, компас, гироскоп. Причем поддержка сенсоров организована таким образом, что после установки всего необходимого софта в системе появляются реальные "виртуальные" сенсоры. Windows их "видит" как обычные датчики, подключенные (интегрированные) к компьютеру, благодаря этому работа с ними возможна посредством стандартного API из состава Sensor and Location Platform.

Данное решение поддерживает:

• GPS
• Акселерометр
• Датчик ориентации
• Датчик освещенности

Огромным плюсом использования этого решения является то, что после того как на замену "виртуальным" сенсорам придут "реальные, железные", разработчику не нужно будет ничего менять, т.к. взаимодействие с датчиками останется прежним, на уровне Sensor and Location Platform API.

Как установить

Первое, что необходимо сделать, это перейти на страницу RemoteSensors и скачать RemoteSensors driver for Windows 7. На сайте представлены драйвера для 32-х и 64-х систем. Скачиваем, запускаем установку, следуем подсказкам.

После завершения установки идем в панель управления, раздел Hardware and Sound, далее Location and Other Sensors.

Ставим галочку (Enabled) напротив PcRemote Sensors Device и нажимаем Apply.

В системе появились сенсоры. Осталось привязать их показания к показаниям сенсоров смартфона. Для этого скачиваем приложение PCRemoteServer и запускаем его.

Последний шаг - через Google Play скачиваем и устанавливаем приложение PcRemote Advance.

Запускаем, выбираем пункт Discovery Server, после того, как сервер обнаружен и произошло подключение - выбираем пункт - Sensors to PC.

Готово! Наш ПК (ноутбук, ультрабук, нетбук) теперь имеет сенсоры!

Как проверить работоспособность данного решения? Для этого я написал простое приложение, которое при запуске инициализирует Sensor and Location Platform, перечисляет все сенсоры, доступные в системе и выводит их в виде списка (Sensors). При выборе сенсора в списке в нижней части окна (Values) можно видеть текущие показания сенсоров.

Если все было сделано правильно, то при запуске приложения вы увидите список как на картинке.

Теперь можно смело приступать к разработке сенсоро-ориентированного приложения для новых мобильных платформ.

Если у вас остались вопросы о том как использовать сенсоры в своих приложениях - приходите послушать доклады, посвященные сенсорам на КРИ и DevCon 12.

В первую очередь я, конечно, хочу порекомендовать наш сайт viva64.com. Здесь можно найти много статей и записей в блоге, касающихся разработке качественного кода. Например, предлагаю познакомиться с 28 уроками, посвященными разработке 64-битных приложений на языке Си/Си++.

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

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

Си++ живее всех живых

• Большой список известных проектов, которые разрабатываются на языке Си/Си++: C++ Applications. И после этого кто-то говорит, что язык Си++ вымирает?
• Computer Language Benchmarks Game. Как всегда по скорости лидируют языки Fortran, Си и Си++. И вряд ли что-то в обозримом времени изменится. Если вы разрабатываете ресурсоемкое программное обеспечение, то Си++ может оказаться оптимальным выбором.
• Why is C++ still a very popular language in quantitative finance?
• Why do they program in C++?
• 9 reasons to start using C++11

Интересные блоги

• Steve Hanov's Blog
• Visual C++ Team Blog
• The Old New Thing

Арифметика с плавающей запятой

• What Every Computer Scientist Should Know About Floating-Point Arithmetic
• Tricks With the Floating-Point Format
• Stupid Float Tricks
• Comparing Floating Point Numbers, 2012 Edition

Разные приёмы при программировании

• Bit Twiddling Hacks
• Table-driven methods with no relocations
• Reduce Compilation Dependencies in Large Scale C++ Projects: Factory Pattern
• Exceptions in C with Longjmp and Setjmp
• Catching Integer Overflows in C. Article N1, N2
• Cool C Tricks

О кодировках символов и управляющих символах

• Unicode, UTF-8 and all that: An intentionally incomplete character set introduction for hasty C programmers
• What the xxxx Is UTF-8? A Character Encoding Primer.
• ASCII Characters
• Control character
• The UTF-8 Everywhere manifesto

Стандарты кодирования

• Google C++ Style Guide
• CERT. C Secure Coding Standard, C++ Secure Coding Standard
• Joint Strike Fighter (F-35) C++ Coding Standard

Группы

• Reddit: Cpp, C_Programming.
• Facebook: C++ Programming, For the love of C++, C Programming, Visual C++ Developer, C Plus Plus (C++)
• LinkedIN: C++ Community Group, C++ Developers Forum, C++ Developers Group, C++ Professionals

Разное

• What's Wrong With GNU make?
• Почему strncpy не безопаснее strcpy: strncpy? just say no
• A Guide to Undefined Behavior in C and C++. Part N1, N2, N3
• Компиляция 64-битных приложений в Visual C++ 2008 Express Edition. Visual C++ 2008 Express Edition And 64-Bit Targets
• Windows Data Alignment on IPF, x86, and x64
• C/C++ Low Level Curriculum. Part N1, N2, N3, N4, N5, N6, N7, N8
• Ссылки на различные ресурсы по тематике Си++. Список ссылается на много старых ресурсов, но его стоит посмотреть.
• Functional Programming in C++
• The C++ Lands (забавная картинка)
• Translate C declaration
• Arbitrary Data Sizes with C

Тривиальный пример вызова встраиваемой функции:

inline int sum(int a, int b)
{
   return a+b;
}

int main()
{
   int a = 2, b = 5, с;
   c = sum(a, b);     // c = a+b
}

Следует отметить, что inline - лишь рекомендация, а не команда компилятору заменять вызов функции ее телом. Он может подсчитать встраивание нецелесообразным и просто проигнорировать модификатор inline и трактовать функцию как обычную. Так что как говорится, на все воля компилятора... (прим.: на Windows существует модификатор __forceinline, который заставляет компилятор встроить функцию)

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

Скорость:

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

Размер исполняемого файла:

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

Пробуксовка (thrashing):

• увеличить - слишком частое использование встраиваемых функций, к тому же больших, приведет к разрастанию кода, что может привести в пробуксовке, т.е. в процессе работы программы операционной системе постоянно потребуется производить подкачку новых страниц
• уменьшить - может уменьшить количество страниц виртуальной памяти, которые должны быть в оперативной памяти одновременно. Например, когда функция f() вызывает функцию g(), коды функций, скорее всего, находятся на разных страницах виртуальной памяти, при внедрении компилятором кода функции g() в код функции f(), часто код обеих функций находится на одной странице

Multiply defined
Компилятор может вставить тело функции в код лишь в том случае, если ее тело находится в текущей единице трансляции. Таким образом, встраиваемые функции должны быть определены в каждой единице трансляции, где они используются, что очень не нравится компоновщику.
Для решения этой проблемы были созданы так называемые слабые (weak) символы. Как только компоновщик найдет один из таких символов, остальные будут проигнорированы. Даже если компилятор проигнорирует модификатор, компоновка пройдет успешно.
Благодаря модификатору inline? символ функции становится слабым символом, поэтому смело можно ставить встраиваемую функцию в один *.h-файл и использовать его в различных единицах трансляции.
Пример:

// test.cpp
#include "my.h"
int main()
{
  int x = 1, y = 1;
  my(x, y);

  return 0;
}

// test1.cpp
#include "my.h"
void f()
{
  int x = 1, y = 1;
  my(x, y);
}

// my.h
inline void my(int x, int y)
{
  x+y;
}

g++ test.cpp -c
g++ test1.cpp -c
g++ test.o test1.o -o // без inline возникает ошибка "multiple definition"

Хорошо, а что с макросами?
Заметим, что макросы обрабатываются препроцессором, а inline-функции компилятором. Так как макросы не видны компилятору, их сложнее отлаживать.
Встраиваемые функции знают об области видимости и делают проверку типа в отличие от макросов.
Встраиваемые функции могут быть перегруженными, функциями-членами классов, задаваться шаблонами и обладают другими достоинствами, недоступными макросам.

Кто знает о модификаторе Inline?
Модификатор поддерживается стандартами C++, C99, GNU C. Причем везде работа с модификатором различна.

Итак,
1) при уместном использовании встраиваемые функции могут повысить скорость выполнения и уменьшить размер исполняемого файла.
2) Могут (и должны) быть определены в разных единицах трансляции
3) Чтобы встраиваемая функция давала существенный выигрыш по сравнению с обычной функцией, она должна быть небольшого размера.
4) Компилятор все равно сделает все по своему, модификатор inline лишь подсказка. Он может проигнорировать модификатор там, где он есть, и поставить там, где его нет.

Основная литература
http://www.parashift.com/c++-faq/inline-functions.html
http://alenacpp.blogspot.com/2005/01/blog-post_28.html
http://stackoverflow.com
www.intuit.ru/

Ссылка на первую часть.

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

Замечательные сравнения делают ребята из МГУ, посмотреть можно тут: compression.ru

Если говорить о сравнении, то можно выделить два критерия: качество (субъективное или объективное) и производительность. Редкий кодек способен победить в обеих номинациях сразу. Однако, речь пойдет о тестировании энкодеров.
Итак, на входе у нас разжатое видео и реализация какого-нибудь кодека (собственно энкодер), на выходе – сжатый клип. Немного про входные данные мы уже поговорили выше, но хочется отметить, что ограничены мы лишь своей фантазией и... лицензиями. Т.е. всегда можно снять видео самому и потом с помощью него издеваться над декодером/энкодером, и не всегда можно скачать кино из интернета для тех же целей. Кроме того, бывает полезно создавать искусственные последовательности: шумы, кадры одного цвета и т.д.
После длительного процесса сжатия мы получим строгими спецификациями выверенный сжатый поток. В нем есть почти все, что было в исходных данных (мы ведь про сжатие с потерями). Именно этот файл нам и предстоит исследовать. И раз уж речь зашла о спецификациях, то одна из важных проверок будет заключаться в том, чтобы убедиться, что наш клип соответствует стандарту.

Это лучше делать сторонними инструментами - так доверие к оценке выше для сторонних пользователей.

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

Любителям x264 придется смириться с меньшим количеством переключателей

Но вернемся к нашему закодированному файлу. Как оценить качество картинки, которую увидит пользователь? Все очень похоже на то, что было в первой части: нам нужен декодер,
желательно сторонний, референсный, чтобы избежать двойных ошибок
с помощью которого мы получим разжатую видеопоследовательность, которую сможем сравнить с исходной с помощью уже знакомых нам метрик - PSNR и SSIM.
Однако, здесь мы приходим к важному вопросу: какие должны быть пороги “похожести” видео? Иначе говоря, какие значения PSNR/SSIM нас удовлетворят, а какие нет? В общем случае, хорошо - это когда не плохо, т.е. нет артефактов, искажений и всего прочего, что так не нравится глазу. И хорошо, если наши метрики это уловили. Не забудем записать нужную циферку в тайное место и использовать при следующей проверке - а вдруг что-то сломалось. Но вот “сломаться” может по-разному.
Итак, допустим вчера наш энкодер давал X dB при Y битрейте (кодировать будем с постоянным битрейтом)

все остальные параметры мы учитывать не будем, оставим их фиксированными

сегодня наш же энкодер выдает X1 dB при том же битрейте. В чем дело? Бьем тревогу? Минуту, а X1 больше X? Если так, то все хорошо, энкодер стал работать лучше! Или нет? Не все так просто, как хотелось бы: при использовании постоянного битрейта нет гарантии, что он и правда будет постоянным - возможны небольшие отклонения (в обе стороны). Теперь представим, что якобы возросшее качество объясняется возросшим битрейтом. А это значит, что никакого реального улучшения нет: энкодер “схитрил”, забрав побольше бит, которые и использовал для улучшения качества. Так же и уменьшение значения X1 по сравнению с X не говорит об ухудшении энкодера - может, он нам битов сэкономил. Мораль: больше не значит лучше, меньше не значит хуже.

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

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

И вроде бы все, можно закончить на этом, но есть одно но: у нас же SDK! А значит, что все варианты работы с памятью, потоками и еще всем, что пользователю доступно изменять, надо проверить. В теории, в большинстве случаев, все способы использования SDK должны давать один и тот же результат.

ну правда, почему качество должно пострадать, если пользователь использует D3D память, вместо системной? Или глубину асинхронности поменяли. Или потоков решили побольше (или поменьше) использовать.

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

Подводя итог, хочется отметить, что если при тестировании декодера нам наиболее интересны входные данные (и чем разнообразнее, тем лучше), то при тестировании энкодеров важно все: и входные данные, и параметры кодирования, коих может быть очень и очень много. Да и сами проверки во втором случае должны быть более интеллектуальными.

Ох уж эти заветные 256 килобит! Какими недостижимыми они казались, когда мы кое-как подключались к провайдеру через старую аналоговую АТС, и кое-как соединялись на скорости 14400 или, если повезет, 18600. Пара килобайт в секунду прокачивается – и уже отлично! При этом у самого «крутого» саратовского провайдера ширина канала на Москву равнялась мегабиту. У остальных – поменьше. У кого в два раза, а у кого и в четыре.

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

Что до устройств, способных выходить в Сеть, то с ними у нас все просто замечательно. Смартфон, планшет, ноутбук – это уж наверняка. Иногда им на помощь приходят еще умные плееры и портативные игровые консоли. Пара кликов – и вот они, любимые почта, мессенджер, Facebook да Twitter. Все знакомые здесь, словно ты и не уезжал никуда (кстати, это «словно никуда не уезжал» работает и в другую сторону. Недавно прикинули с другом, давно живущим в Китае, сколько же мы с ним не виделись. Оказалось – не меньше пяти лет. При этом ощущения разлуки нет никакого, потому что мы почти каждый день общаемся по ICQ и почте). Помню, поначалу меня это ощущение очень радовало – надо же, чувствуешь себя дома по всему миру. Но вот в последние годы меня это ощущение стало почему-то раздражать…

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

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

Все мы сейчас напоминаем эдаких гребцов, прикованных к галерам. Разве что галеры у нас довольно изящные, и обычно мы их подбираем себе сами. Добавить еще к Интернету постоянно работающий мобильник («спасибо» подешевевшему роумингу), и причины неуклонного роста благосостояния врачевателей неврозов становятся очевидными.

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

Что скажете, коллеги? Нагнетаю не по делу? Или есть рациональное зерно? Просто скоро сезон отпусков, а у вас-то рабочее место тоже всегда при себе. Как бороться с работой, если она так заманчиво близка на любом расстоянии от дома?

Добро пожаловать!

Так же на страничке документации, как обычно, документы из последнего обновления и выложен новый вариант doxygen-документации.

--Владимир

Сегодня мы с вами поговорим о любви C/C++ к Java. Связь не очевидна, но она есть. Итак, поехали!

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

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

Рассмотрим опять что-нибудь незамысловатое, чтобы не пудрить сильно мозги.

Допустим, у нас есть Java класс, в котором реализован метод, который приветствует другой объект. Вот как выглядит класс с методом:

public class Hello {
      public static int HelloObject(PeopleObject people)  {
	    System.out.println("Height" + people.height);
	    System.out.println("Name:" + people.name);
	    System.out.println("Town:" + people.town);
	    System.out.println("Age:" + people.age);
	    return OK;
	}
}

Вот как выглядит сам класс:

public class PeopleObject {
	public int height;
	public String name;
	public String town;
	public int age;
	public PeopleObject(int height, String name, String town, int age) {
		this.height = height;
		this.name = name;
		this.town = town;
		this.age = age;
	}
}

Со стороны Java всё готово, теперь подготовим площадку в C/C++, для вызова нашего метода.

Для того что бы вызвать наш метод из C/C++, вначале нам понадобится загрузить (создать) JVM (виртуальную Java машину) используя следующее:

JNIEnv * loadJVM(JavaVM ** jvm) {
    JavaVMOption jvmOptions;
    jvmOptions.optionString = "-Djava.class.path=C:\\JavaClassFiles";
    JavaVMInitArgs jvmArgs;
    jvmArgs.version = JNI_VERSION_1_6;
    jvmArgs.nOptions = 1;
    jvmArgs.options = &jvmOptions;
    jvmArgs.ignoreUnrecognized = JNI_TRUE;
    JNIEnv * env;
    int OK = JNI_CreateJavaVM(jvm, (void**)&env, &jvmArgs);
    if(OK < 0) printf("\nUnable to Launch JVM\n");
    return env;
}

Итак, по порядку:
jvmOptions.optionString = "-Djava.class.path=C:\\JavaClassFiles";
в этой строке мы указываем папку исходников, где располагаются файлы классов. Далее jvmArgs описывает аргументы для вызова Java машины.

jvmArgs.version = JNI_VERSION_1_6;
jvmArgs.nOptions = 1;
jvmArgs.options = &jvmOptions;
jvmArgs.ignoreUnrecognized = JNI_TRUE;

в первой строчке мы задаём версию Java, во второй мы задаём кол-во опций, так как они хранятся в массиве, в данном случае мы задаём опцию для Java машины, и в четвёртой строке мы указываем игнорировать все нераспознанные опции, строка которых начинается с "-X" or "_" (Не обязательно).

Теперь вызовем создание Java машины:

JNIEnv *env;
JavaVM * jvm;
env = loadJVM(&jvm);
if (env == NULL) return BAD;

А теперь всё готово для начала работы с Java методами, объектами. Для начала найдём два наших класса:

jclass clsH = env->FindClass("Hello");
jclass clsP = env->FindClass("PeopleObject");

Метод “FindClass” ищет класс по имени.

Теперь у класса “Hello”, получим метод “HelloObject”.

jmethodID midHelloObject = NULL;
if (clsH != NULL)  {
	midHelloObject = env->GetStaticMethodID(clsH,"HelloObject","(LPeopleObject;)I");
} else {
    	printf("\nUnable to find the requested class\n");
}

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

Метод GetStaticMethodID ищет метод в классе clsH с именем HelloObject и нужной сигнатурой. О том как генерировать сигнатуру не ручками, скажем позже.

Теперь получим конструктор класса “PeopleObject”, для того, чтобы в него передать нужные параметры для создания объекта.

jmethodID midPeopleObjectConst = NULL;
if(clsP != NULL)  	{
	midPeopleObjectConst = env->GetMethodID(clsP, "<init>", "(ILjava/lang/String;Ljava/lang/String;I)V");
} else  {
	printf("\nUnable to find the requested class\n");
}

Словом "<init>" мы показываем, что это будет именно конструктор.
Ну а теперь сделаем то, что задумали:

jobject jobjPeople = NULL;
if (midHelloObject!=NULL)  {
	if(clsP != NULL && midHelloObjectConst != NULL)  {
		char  cName[255] = “Yuki”;
		jstring name = env->NewStringUTF(cName);
		char  cTown[255] = “Tokyo”;
		jstring town = env->NewStringUTF(cTown);
		int cHeight = 169;
		jint height = (jint) cHeight;
		int cAge = 17;
		jint age = (jint) cAge;
		jobjPeople = env->NewObject(clsP, midPeopleObjectConst, height, name, town,  age);
	}
	if(jobjPeople != NULL && midHelloObject!= NULL)
		env->CallStaticIntMethod(clsH,midHelloObject,jobjPeople);
}

Что тут происходит? Да всё то же самое, подготавливаются параметры для создания объекта PeopleObject. Далее создаётся объект класса PeopleObject через его конструктор. А дальше вызывается метод из класса Hello, с передачей в функцию HelloObject, объекта класса PeopleObject.

Ну и в конце не забываем уничтожить Java машину: jvm->DestroyJavaVM();

Вот и всё

Ах, да, как же генерировать правильно сигнатуру? Это можно делать и руками, но можно легко ошибиться, да и очень много работы. Генерировать сигнатуры можно при помощи утилиты “javap”, входящей в состав JDK. Например, если запустить её для класса “Hello” (javap -s -p Hello), то мы получим:

//Compiled from "Hello.java"
public class Hello extends java.lang.Object{
public Hello ();
  	Signature: ()V
public static void main(java.lang.String[]);
  	Signature: ([Ljava/lang/String;)V
public static int HelloObject(PeopleObject);
  	Signature: (LPeopleObject;)I
}

Cкажу напоследок, что если у вас 64-битная архитектура, то у вас возможно возникнут проблемы с компиляцией и запуском приложения. Дело в том что JDK 64-bit поставляет не совсем пригодные для таких операций библиотеки, поэтому лучше скачать JDK 32-bit и подключать либы оттуда.

Теперь мы показали взаимную любовь Java & C/C++, и можно за них порадоваться
Подробнее обо всё можно почитать по-прежнему на сайте Oracle.

Краткое описание
Возникла технология MapReduce из необходимости обрабатывать данные, которые в оперативную память ну никак не влезут. Да и на жесткий диск, в общем-то, тоже: технология нацелена на обработку петабайтов (10^15) данных. Обрабатываются данные, соответственно, на кластере. Данными являются таблицы, содержащие список записей вида (KEY, VALUE). Пользователю достаточно задать функции обработки Map и Reduce (подробнее о них - чуть позже), и платформа сама позаботится о сортировке данных, запуске функций обработки, повторном исполнении упавших транзакций и много чем еще.

Две функции, которые предлагается реализовать пользователю, таковы:

Map - функция, принимающая на вход одну запись вида (KEY, VALUE), и возвращающая по ней любое количество новых записей (KEY1, VALUE1), (KEY2, VALUE2), ...

Reduce - функция, принимающая на вход все записи с данным ключом. Итерируясь по ним, она так же может возвращать любое количество новых записей.
Более формально, функция работает по принципу {(KEY, VALUE1), (KEY, VALUE2), ...} → (KEY1, VAL1), (KEY2, VAL2), ...

В чем смысл таких функций? Суть в том, что обрабатывать петабайты данных можно, грубо говоря, только линейными алгоритмами. Если алгоритм работает O(n^2) - можно считать, что он просто не работает
Для поточной линейной обработки данные можно менять и преобразовывать (Map), и можно сливать, комбинируя полученные результаты (Reduce). Эти операции легко параллелятся на кластерах из любого числа машин, поэтому и допускают столь впечатляющие объемы масштабирования.

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

Пусть сохраненные страницы хранятся в виде (KEY = URL, VALUE = PAGE_TEXT).

Шаг 1) Запустим на этой базе данных операцию Map. Получив на вход текст страницы, она выделит все исходящие ссылки:

void Map(String key, String value) {
    for url in GetUrls(value) {
        OutputRecord(url, 1)
    }
}

После запуска этой операции, мы получим список записей вида (KEY = URL, VALUE = 1). В чем смысл этой единички? Идем дальше:
Шаг 2) Операция Reduce. Здесь мы принимаем все записи с одинаковым ключом (то есть одинаковым URL). Псевдокод:

void Map(String key, Iterator it) {
    int count = 0;
    while (it.HasMoreRecords()) {
        count += it.GetValue();
    }
    OutputRecord(key, count);
}

Проследим работу этого псевдокода на примере.
Пусть есть страница aa.com со ссылками на aa.com, bb.com, cc.com, страница bb.com с двумя ссылками на aa.com и страница cc.com, на которой нет ссылок вообще.
После первого этапа программы, получим выходную таблицу:

(aa.com, 1)
(bb.com, 1)
(cc.com, 1)
(aa.com, 1)
(aa.com, 1)

Между запусками Map и Reduce таблица будет отсортирована, чтобы можно было объединить записи с одинаковым ключом. Получим:

(aa.com, 1)
(aa.com, 1)
(aa.com, 1)
(bb.com, 1)
(cc.com, 1)

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

(aa.com, 3)
(bb.com, 1)
(cc.com, 1)

Вуаля, ровно это мы и искали.

Заключение
В следующем посте я хотел бы рассказать про одну из реализаций MapReduce с открытым исходным кодом, Apache Hadoop, а также поговорить про вспомогательные операции, которые предоставляет эта платформа (Combine и Partition). Воспользовавшись этим фреймворком, мы напишем программу, подсчитывающую топ наиболее частых слов в википедии.

Сегодня мы с вами поговорим о любви Java к C++. Связь не очевидна, но она есть. Итак, поехали!

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

• Пускай у вас есть проверенный на 100% код на другом языке. Для того что бы его перевести на язык Java, потребуется немало времени, а полученный код нужно опять проверять и отлаживать. Особенно если это огромная библиотека или проект.
• Или нам нужны низкоуровневые операции для доступа к аппаратным средствам, в таком случае Java не очень подходит для таких операций.
• Или если нам нужно множественное применение сложных операций с машиной, требующих очень оптимизированного кода, чего на Java опять не добьёшься (хотя этому можно поставить в противовес just-in-time компиляцию).

Если мы всё же столкнулись с одной из вышеперечисленных проблем, то, скорее всего нам-таки придётся научиться вызывать платформенно-ориентированный код прямиком из Java. Для этого в Java предусмотрены специальные способы работы с системными библиотеками, а JDK содержит инструменты, которые позволят нам справиться с этими проблемами.

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

Но выбор за вами, стоит ли это делать в ситуации, с которой вы столкнулись или нет

Я не буду описывать кучу методов, кучу ситуаций, и тому подобное, это лучше всего расскажет специализированная книжка, а тут будет приведены примеры почти стандартных задач, вида Hello “damn” world!

Итак, наша задача: на языке C/C++ есть функция, которая выполняет какие-то сумасшедше-полезные действия. И мы хотим её вызвать из Java (да-да, нам лень переписать её на Java ). Пускай это функция вывода printf (можно использовать и другие, но будем ориентироваться на C), которая приветствует передаваемую строку и какое-то число.

Для того, чтобы в Java показать, что функция будет платформенно-ориентированной, есть ключевое слово “native”, которое предупреждает компилятор о внешнем определении данного метода. Саму функцию нужно описывать в классе.

public static native void welcome(String str, int value);

В данном случае функция объявлена как статическая, но это не обязательное условие. Теперь поместим её в класс:

class Hello {
      public static native void welcome(String str, int value);
}

Такой класс откомпилировать вы сможете, но вылетит исключение, говорящее, что программа не может найти метод. Для того? чтобы метод был найден, его тело нужно создать на C/C++, причём не просто метод, а метод говорящий что его будут вызывать из кода на Java. Но об этом попозже, просто знайте, что мы создадим разделяемую библиотеку для экспорта на C/C++, а далее загрузим её в Java. И только тогда программа найдёт этот метод и сможет успешно выполняться.

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

class Hello {
   public static native void welcome(String str, int value);
   static  {
      System.loadLibrary("JAVALOVECHELLO");
   }
}

Метод loadLibrary("JAVALOVECHELLO"), загружает библиотеку по имени JAVALOVECHELLO.

Теперь настало время для создания C/C++ функции, имя которой должно строго (значит точно) соответствовать соглашениям об именовании:

• Имя метода в C/C++ должно полностью соответствовать ПОЛНОМУ имени в Java программе. Например, если мы поместим программу в пакет com.intel, тогда полное имя Java-метода будет com.intel.Hello.welcome. Теперь нужно заменить все точки на нижние подчёркивания (_) и добавить префикс “Java_”, получим строку Java_com_intel_Hello_welcome. Если код находится в пакете “default”, то имя C-функции должно выглядеть так: Java_Hello_welcome.
• Стоит быть внимательными с различными Unicode-символами: их нужно заменять на их 16-ричное представление, но об этом не будем тут. На самом деле и это ещё не все соглашения, но сейчас расскажем, как не делать этого ручками.

Для правильно описанных методов не стоит их создавать руками, для этого воспользуемся специальной утилитой “javah”, которая есть в JDK. Для начала откомпилируем наш Java-файл, используя “javac”.

javac Hello.java

Теперь воспользуемся “javah”.

javah Hello

В результате выполнения этих операций мы получим файл “Hello.h”

/* DO NOT EDIT THIS FILE - it is machine generated */
#include
/* Header for class Hello */
#ifndef _Included_Hello
#define _Included_Hello
#ifdef __cplusplus
extern "C" {
#endif
/*
 * Class:     Hello
 * Method:    welcome
 * Signature: ()V
 */
JNIEXPORT void JNICALL Java_Hello_welcome
  (JNIEnv *, jclass, jstring, jint);
#ifdef __cplusplus
}
#endif
#endif

Как видно, так как мы пишем на C++, то добавлена строчка extern "C", которая об этом сообщает. Имена JNIEXPORT и JNICALL описаны в jni.h, они задают спецификаторы функций, экспортируемых из динамических библиотек .

В данном файле всё довольно понятно, всё как мы и предполагали (на самом деле не всё, но об этом позже).

Осталось для данного файла заголовка написать соответствующий файл c исходным кодом, где мы и опишем тело метода.

Вот как он будет выглядеть:

#include "Hello.h"
#include
JNIEXPORT void JNICALL Java_Hello_welcome(JNIEnv* env, jclass cl, jstring str, jint value)
{
   const char * ccstr;
   ccstr = (*env).GetStringUTFChars(str, NULL);
   printf("Hello damn World, %s, %d!\n", ccstr, (int)value);
}

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

Как наверно можно догадаться jstring, jint это по сути те же string, int, но только в понимании JNI (их соответствия).

Функция GetStringUTFChars() возвращает указатель const jbyte * на символы строки, представленные в формате UTF-8. Также не помешает после использования строк освобождать память. Если же этого не делать, то это может повлиять на работу метода (память не безгранична). Для этих целей нужно использовать метод ReleaseStringUTFChars().

Очень подробное описание всех функций (API JNI) можно найти сайте Oracle, по этой ссылке - http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/jniTOC.html.

Как компилировать динамическую библиотеку каждый выбирает сам, это можно сделать вручную, или можно предоставить всё MVS.

Нужные вам библиотеки, необходимые для успешной компиляции C/C++, лежат в JDK/include.

Ну и осталось написать вызов функции из Java-программы:

class HelloTest {
   public static void main(String[] args)    {
      Hello.welcome("I'm a string", 100500);
   }
}

На этом закончим, хоть и было рассмотрено материала 7% от общего, но тут главное смысл, а дальше уже как по маслу, берёшь и намазываешь