Доступен CrystaX NDK 10.1.0 (https://www.crystax.net/android/ndk), набор инструментов для разработки на C/C++ (и Objective-C) под Android. CrystaX NDK разработан как прозрачная замена для Android NDK от Google, но при этом добавляет немало возможностей, отсутствующих в оригинальном NDK. Прежде всего это означает, что CrystaX NDK можно использовать вместо Google NDK, и всё будет продолжать работать как раньше. Но при этом станут доступными многие возможности, отсутствующие в Google NDK, такие как поддержка широких символов (https://ru.wikipedia.org/wiki/%D0%A8%D0%... полноценная система Си-локалей, библиотека расширенных математических функций, поставка более новых версий GCC и Clang, поддержка C++11/C++14, наличие библиотеки Boost и т.д.
В новом выпуске основной упор сделан на совместимость с POSIX, и в большой степени этого удалось достичь. Иными словами, при использовании CrystaX NDK Android становится для разработчика намного более POSIX-совместимым, чем он есть на самом деле, а потому сильно облегчается задача портирования кода с других платформ — в частности, с Linux. Код наработок CrystaX NDK опубликован (https://github.com/crystax) на GitHub.URL: https://www.crystax.net/android/ndk
Новость: http://www.opennet.me/opennews/art.shtml?num=41520
Щастье есть
Если не есть - помрешь.
Ешь не ешь, а помрешь неминуемо.
Неужто даже для мусорного ведра можно будет компилить программы более-менее по человечески?
Не очень понимаю зачем это нужно, может для игр? Но гуя и 3D вроде на андроиде и так прилично бегает за счет JIT.
Решать свои потребности на С/С++ - это совсем не вариант, для этих целей существует perl (в основном демоны с init.d стартуют).
Для тяжелых вычислении? - Но телефон и планшеты - это далеко не лучшие варианты для вычислении. Если припрет, лучше тем же perl-скриптом скинуть задачу на числодробление на удаленный хост. Вообщем я не понимаю целесообразность этого NDK.
1) Кроссплатформенный софт, меняющий только морду, Как тот же deadbeef. Или менее кросспалтформенный - где ядро одно и то же для Android и iOS.
2) Удалённый хост - это хорошо... когда он доступен и имеет приемлемые задержки. Что бывает отнюдь не всегда. А чем дальше - тем больше всякого распознавания образов и прочих тяжелых вичслений на мобильных девайсах. И результаты нужны, как правило, как можно быстрее.
3) даже с JIT игры тащили и тащат плюсовые ядра. Может, начиная с Android L c AOT что-то изменится, но очень не факт.
4) на некоторых задачах пожирание памяти аккуратно написанным сишным кодом по сравнению с джавовским с GC может отличаться на порядок. Вплоть до разницы "будет вообще работать или нет".
5) Чем дальше - тем ближе андроид-системы к обычным десктопным по мощности. А значит - хочется, чтобы на них работали привычные для десктопа инструменты. И с минимальной морокой.
Добавлю к 1, что возможен кроссплатформенный софт с кроссплатформенной же мордой.
При использовании библиотек типа Cocos2d-x в проекте код для Android и iOS может отличаться только в тех местах, где действительно выполняются разные действия. Остальные отличия возьмет на себя библиотека.
звучит годно, надо будет попробовать
Раздел "Услуги" посмотри и убоись.
Ну раздел как раздел... Единственное, что непонятно - чего у них дефолтный вариант сайта - русскоязычный.
Там нет дефолтного варианта сайта. Он просто смотрит на HTTP AcceptLanguage, присылаемый браузером, и выдает страницу на нужном языке.
снова что то дельное
Хм. А разве само наличие libcrystax не гробит на корню саму идею комплекта для нативной разработки?
> Но при этом станут доступными многие возможности, отсутствующие в Google NDK,
> такие как ... поддержка C++11/C++14, наличие библиотеки Boost и т.д.Видел Ваши сообщения еще на двух ресурсах. Например, на rsdn Вы утверждаете:
"В Android NDK доступны на выбор две реализации стандартной библиотеки C++ — GNU libstdc++ и LLVM libc++. К сожалению, обе работают плохо. Используя GNU libstdc++, вы не получите ни std::thread, ни std::mutex, ни std::chrono — и это далеко не все. Фактически, о полноценном C++11 можно забыть."
Но вообще-то, это совсем не так. Стандартный NDK содержит не 2, а 4 реализации STL ( http://www.kandroid.org/ndk/docs/CPLUSPLUS-SUPPORT.html ):
- system - та самая обрезаная версия "без всего", которую Вы ошибочно называете GNU libstdc++
- gabi++
- stlport
- gnustl - собственно GNU libstdc++ с полной поддержкой std::thread, std::mutex, std::chrono, и всего остального, что входит в C++11 - при условии выбора соответсвующего toolchain (например, gcc 4.8 или 4.9).
Так что C++11 доступен в NDK достаточно давно.
>[оверквотинг удален]
> забыть."
> Но вообще-то, это совсем не так. Стандартный NDK содержит не 2, а
> 4 реализации STL ( http://www.kandroid.org/ndk/docs/CPLUSPLUS-SUPPORT.html ):
> - system - та самая обрезаная версия "без всего", которую Вы ошибочно
> называете GNU libstdc++
> - gabi++
> - stlport
> - gnustl - собственно GNU libstdc++ с полной поддержкой std::thread, std::mutex, std::chrono,
> и всего остального, что входит в C++11 - при условии выбора
> соответсвующего toolchain (например, gcc 4.8 или 4.9).Это ошибочное представление. "Версии" system/gabi++/stlport я во внимание не принимаю, т.к. system и gabi++ - это вообще даже рядом не "стандартная библиотека C++", а stlport сильно устарела и C++11 возможностей в ней просто нет.
Так что я говорил о gnustl (GNU libstdc++ - $NDK/sources/cxx-stl/gnu-libstdc++) и libc++ (LLVM libc++ - $NDK/sources/cxx-stl/llvm-libc++). Они обе вполне реализуют то, что требует стандарт C++11 от стандартной библиотеки. Проблема только в том, что конкретно в NDK реализация GNU libstdc++ неполная, а LLVM libc++ - нестабильная.
Что касается std::mutex и std::thread - то да, они действительно теперь доступны в Google NDK при использовании GNU libstdc++ (gnustl), однако еще совсем недавно они не были доступны. Причины этого - бедная и не соответствующая стандартам libc (Bionic). При сборке GNU libstdc++ запускает много тестов, чтобы проверить, реализована ли на target-системе определенная функциональность и, если нет, отключает все от нее зависящие фичи. Ранее std::thread и std::mutex не работали из-за того, что Bionic не предоставляла pthread_mutex_timedlock(). Сейчас это поправлено, но много других вещей остались неисправленными и далее. Предлагаю открыть файл $NDK/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include/bits/c++config.h и оценить, сколько макросов там не определено, а затем самостоятельно поискать в $NDK/sources/cxx-stl/gnu-libstdc++/4.9/include, что от этих макросов зависит. Например, std::stol.
LLVM libc++ реализована по другому, поэтому для ее сборки в Google пришлось ее очень сильно покромсать, что плачевно сказалось на ее стабильности. Иными словами, при ее использовании регулярные падения вам обеспечены.
Мы же в CrystaX NDK исправили очень много низкоуровневых вещей, из-за чего стало возможным а) собрать полноценную GNU libstdc++, в которой все фичи включены и б) собрать LLVM libc++ из upstream исходников, а не покромсанную Google-ом.
> Так что C++11 доступен в NDK достаточно давно.
Как видите, это не так. В Google NDK C++11 как язык доступен, но со стандартной библиотекой беда.
И кстати - std::chrono в Google NDK более-менее доступен (при использовании), но std::chrono::monotonic_clock, к примеру, не гарантирует монотонности, а просто и тупо является алиасом к std::chrono::system_clock. Как говорится, удачи в отладке. Даже предупреждения не выдается при сборке.А в CrystaX NDK std::chrono::monotonic_clock - это честный monotonic clock, на ход времени которого не влияет переустановка системного времени.
И это только один из множества примеров, когда, чтобы поймать ошибку, приходится отлаживаться не то чтобы часами или днями, но иногда даже неделями - и все только для того, чтобы выяснить, что баг в системной libc или в gnustl. До сих пор вспоминаю, сколько времени пришлось потратить, чтоб в конце концов выяснить, что strtod() не парсит строки "0xNNN", а просто возвращает нуль. Если б хотя бы падала, легче найти причину было бы - но нет, просто 0 на выходе. А чтобы дойти до strtod(), пришлось продраться через огромную гору кода, и затратить на это несколько дней.
Спасибо за пояснения!(спаведливости ради следует отметить, что std::thread и std::mutex работали корректно уже в r9c - в более ранних версиях не пробовал).
Еще два вопроса:
1. Вы говорите, что можно просто заменить Google NDK на CrystaX и все будет работать также, как и ранее с NDK, "только лучше" :-)
Однако при попытке сделать это ("просто заменить") с проектом с native activity запускаемым через native_app_glue, и использующим минимиум third-party библиотек (Box2D, tinyxml2 и libpng) проект успешно компилируется, однако не запускается на планшете ("...could not load application...").
2. Можно ли слинковать вашу библиотеку libcrystax с программой статически?
> (спаведливости ради следует отметить, что std::thread и std::mutex работали корректно
> уже в r9c - в более ранних версиях не пробовал).Верно, это я ошибся. Просто я с этим столкнулся намного ранее r9c (еще в r7), и мне немало пришлось потрудиться, чтоб заставить std::thread и std::mutex корректно работать. Ну а сейчас произошла некоторая аберрация памяти и я назвал std::thread/std::mutex в списке недоступных фич.
> Однако при попытке сделать это ("просто заменить") с проектом с native activity
> запускаемым через native_app_glue, и использующим минимиум third-party библиотек (Box2D,
> tinyxml2 и libpng) проект успешно компилируется, однако не запускается на планшете
> ("...could not load application...").Надо просто загрузить libcrystax.so перед загрузкой native activity. Если у вас есть хоть сколько-нибудь Java кода, то проще всего это сделать так:
static {
System.loadLibrary("crystax");
}Если же Java нет и добавлять не хочется, то можно:
- написать свой stub, в котором делать dlopen() для libcrystax.so и затем передавать управление native activity (вот тут это хорошо объясняется: http://stackoverflow.com/questions/12524664/cant-load-native...
- либо просто статически слинковаться с libcrystax.a
> 2. Можно ли слинковать вашу библиотеку libcrystax с программой статически?
Да, можно. Если используется ndk-build, то просто добавьте в ваш Application.mk:
APP_LIBCRYSTAX := static