| 1.3, Аноним (-), 11:35, 23/01/2015 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Неужто даже для мусорного ведра можно будет компилить программы более-менее по человечески?
| | |
| |
| 2.6, Аноним (-), 10:06, 24/01/2015 [^] [^^] [^^^] [ответить]
| –6 +/– |
Не очень понимаю зачем это нужно, может для игр? Но гуя и 3D вроде на андроиде и так прилично бегает за счет JIT.
Решать свои потребности на С/С++ - это совсем не вариант, для этих целей существует perl (в основном демоны с init.d стартуют).
Для тяжелых вычислении? - Но телефон и планшеты - это далеко не лучшие варианты для вычислении. Если припрет, лучше тем же perl-скриптом скинуть задачу на числодробление на удаленный хост. Вообщем я не понимаю целесообразность этого NDK.
| | |
| |
| 3.7, Crazy Alex (ok), 03:50, 25/01/2015 [^] [^^] [^^^] [ответить]
| +2 +/– |
 1) Кроссплатформенный софт, меняющий только морду, Как тот же deadbeef. Или менее кросспалтформенный - где ядро одно и то же для Android и iOS.
2) Удалённый хост - это хорошо... когда он доступен и имеет приемлемые задержки. Что бывает отнюдь не всегда. А чем дальше - тем больше всякого распознавания образов и прочих тяжелых вичслений на мобильных девайсах. И результаты нужны, как правило, как можно быстрее.
3) даже с JIT игры тащили и тащат плюсовые ядра. Может, начиная с Android L c AOT что-то изменится, но очень не факт.
4) на некоторых задачах пожирание памяти аккуратно написанным сишным кодом по сравнению с джавовским с GC может отличаться на порядок. Вплоть до разницы "будет вообще работать или нет".
5) Чем дальше - тем ближе андроид-системы к обычным десктопным по мощности. А значит - хочется, чтобы на них работали привычные для десктопа инструменты. И с минимальной морокой.
| | |
| |
| 4.10, тоже Аноним (ok), 09:40, 26/01/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Добавлю к 1, что возможен кроссплатформенный софт с кроссплатформенной же мордой.
При использовании библиотек типа Cocos2d-x в проекте код для Android и iOS может отличаться только в тех местах, где действительно выполняются разные действия. Остальные отличия возьмет на себя библиотека.
| | |
|
|
|
| |
| |
| 3.8, Crazy Alex (ok), 03:53, 25/01/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну раздел как раздел... Единственное, что непонятно - чего у них дефолтный вариант сайта - русскоязычный.
| | |
| |
| 4.13, crystax (?), 18:20, 29/01/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Там нет дефолтного варианта сайта. Он просто смотрит на HTTP AcceptLanguage, присылаемый браузером, и выдает страницу на нужном языке.
| | |
|
|
|
| 1.11, Ne01eX (ok), 11:40, 26/01/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Хм. А разве само наличие libcrystax не гробит на корню саму идею комплекта для нативной разработки?
| | |
| 1.14, Аноним (-), 01:03, 02/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
> Но при этом станут доступными многие возможности, отсутствующие в 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 достаточно давно.
| | |
| |
| 2.15, crystax (?), 01:20, 02/02/2015 [^] [^^] [^^^] [ответить] | +/– | gt оверквотинг удален Это ошибочное представление Версии system gabi stlp... большой текст свёрнут, показать | | |
| |
| 3.16, crystax (?), 01:33, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
И кстати - 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(), пришлось продраться через огромную гору кода, и затратить на это несколько дней.
| | |
| |
| 4.17, Аноним (-), 02:41, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
Спасибо за пояснения!
(спаведливости ради следует отметить, что 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 с программой статически?
| | |
| |
| 5.18, crystax (?), 02:52, 02/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> (спаведливости ради следует отметить, что 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-shared-library-w)
- либо просто статически слинковаться с libcrystax.a
> 2. Можно ли слинковать вашу библиотеку libcrystax с программой статически?
Да, можно. Если используется ndk-build, то просто добавьте в ваш Application.mk:
APP_LIBCRYSTAX := static
| | |
|
|
|
|
|
