Вышел CrystaX NDK 10.2.0

размером с планету.

Чего? Они по 30-500 КБ были.

ты бы прочитал про остальные проблемы, помимо API/ABI.

Ну так расскажи.

но он категорически несовместим с встроенной объектной моделью крестов.

В чём?

а вот java, C#, и ObjC — очень хороши для этой задачи (хотя первые два и имеют миллион других недостатков). непонятно, зачем ты споришь с очевидными вещами.

Потому что ты ничем эти «очевидные вещи» не подкрепил.

В любом случае читать о и верить в «факты» на сайте майкрософта не стоит. На деле эти факты далеко не факты.

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

Можно сделать задел для абстракции, не более.

в данном случае, никакая абстракция не нужна, потому что буст можно тупо не подключать в свой проект. но видимо тебе просто места на винте жалко.

Иначе получится еще одна юнити-три-дэ.

haters gonna hate.

Только я до сих пор не могу понять, зачем мне покупать то, что я использовать не буду?

ага, т.е. таки я прав, и тебе жаль места на винте. ок.

Что за вещи такие? Желательно с примерами этих вещей в других языках.

дочитай тред.

Потому что ты ничем эти «очевидные вещи» не подкрепил.

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

Можно подробнее про то как это будет работать? Вот нужны мне для работы программы какие-то апи-функции. Их нет, что будет делать программа?

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

Поддержка Objective-C v2 runtime и начальных Cocoa-совместимых фреймворков (Foundation и CoreFoundation).

кстати, забыл задать вопрос — сколько весит это дело? в основном интересует прибавка в весе APK «per-ABI».

Чего? Они по 30-500 КБ были.

Скорее 300-5000 Кб.

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

Это подходит только для случаев когда новые функции делают что-то более оптимально. Если же, «тех, что есть» вообще нет, то как ты себе это представляешь? Если же новое апи делает что-то принципиально новое, то в своём приложении никак не обойтись без проверки его наличия.

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

Ну ок, про стандарты они знают, но забивают на них. Я только это и хотел сказать.

в данном случае, никакая абстракция не нужна, потому что буст можно тупо не подключать в свой проект. но видимо тебе просто места на винте жалко.

При чем тут место на харде? Я скачиваю ndk, а прицепом получаю буст. Где логика?

ага, т.е. таки я прав, и тебе жаль места на винте. ок.

В каком месте вы прочитали про «мне жалко места на харде»?

Эти ваши паттерны.

Паттерны, как ни странно, есть в любом мейнстримовом языке, С++ тут не при чём. Причём наиболее известный набор относится, скорее, к ООП в целом, а не к конкретному языку. Языки разве что слегка меняют отдельные нюансы.

Макросы могут решать эту проблему в той или иной степени, но в мейнстрим они плохо проникают.

Это подходит только для случаев когда новые функции делают что-то более оптимально. Если же, «тех, что есть» вообще нет, то как ты себе это представляешь?

очень легко представляю. например, хочу сделать поддержку lockscreen widget + AVRCP интеграцию на андроиде, а RemoteControlClient — Added in API level 14, Deprecated since API level 21.

моя программа работает на API level 4 и выше (android 1.6+).

java позволяет в рантайме проверить версию доступного API, и переключиться на fallback (все это реализовано в рамках готового класса RemoteControlClientCompat, который предоставляется гуглом где-то в примерах).

При чем тут место на харде? Я скачиваю ndk, а прицепом получаю буст. Где логика?

по аналогии, ты скачиваешь ndk, а прицепом получаешь zlib. в чем разница?

java позволяет в рантайме проверить версию доступного API, и переключиться на fallback

Ну а я о чём? Это всё работает, только если есть fallback.

Ну а я о чём? Это всё работает, только если есть fallback.

я не знаю о чем ты. fallback в данном случае это «ничего не делать если функций нет». (т.е., он как бы есть _всегда_)

fallback в данном случае это «ничего не делать если функций нет».

Правда не видишь возможных проблем? Вот жмёт пользователь на кнопку, программа что-то вызывает и ничего не происходит. Круто да?

В общем, не будет оно нормально работать во всех случаях.

Правда не видишь возможных проблем? Вот жмёт пользователь на кнопку, программа что-то вызывает и ничего не происходит. Круто да?

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

В общем, не будет оно нормально работать во всех случаях.

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

ps: я так понял, что ты просто не сталкивался с этими вещами, поэтому объясняю: твоя программа должна удалять (или не добавлять) такую кнопку в интерфейсе, если функциональность недоступна.

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

Вот всем и интересно, а в чем ты видишь трудность в организации такого поведения на C++?

Вот всем и интересно, а в чем ты видишь трудность в организации такого поведения на C++?

запусти программу собранную с Qt X.Y на системе с Qt X.(Y-1), и сразу поймешь все самостоятельно. вместо Qt можно использовать, например, GTK — роли не играет.

я не утверждаю, что это вообще невозможно реализовать. если бы ты прочитал тред — ты бы заметил, что неоднократно упоминались всякие COM/pimpl/..., и они как раз позволяют эту проблему решать. но совсем не так, как в жабе/шарпе/обжце. на самом деле ваш цэплюсплюс превращается в тыкву, и писать на нем становится еще больнее, чем обычно.

Потому что в Qt для этого ничего не делалось. Если бы делалось, то спокойно все запустилось бы.

Это от C++ никак не зависит, о чем тебе все и пытаются донести.

на самом деле ваш цэплюсплюс превращается в тыкву, и писать на нем становится еще больнее, чем обычно.

Может дело не в C++?

Может дело не в C++?

может пропустим прелюдии, и сразу перейдем к делу?

Это от C++ никак не зависит, о чем тебе все и пытаются донести.

можешь дать линк на пост где некие «все» пытаются до меня донести что некое «это» никак не зависит от C++?

Никаких дел. :)

С этим сложно поспорить:

и они как раз позволяют эту проблему решать. но совсем не так, как в жабе/шарпе/обжце

а еще не так как в форте, го и аде. :)

Вышел CrystaX NDK 10.2.0 (комментарий) Вышел CrystaX NDK 10.2.0 (комментарий) Вышел CrystaX NDK 10.2.0 (комментарий)

а еще не так как в форте, го и аде. :)

под «не так» скорее имелось ввиду «не так гибко и удобно», чем «не так на уровне синтаксиса».

ты действительно не понимаешь разницу между рефлекшеном и COM? проходи мимо, и не демонстрируй безграмотность.

2 из 3 линков которые ты дал — школобред. на 3й я отвечал. тебе что-то еще непонятно?

Ну вот мы и добрались до «не так гибко и удобно», а все начиналось с «категорического нельзя».

Значит можно, но «не так удобно». Удобство это понятие субъективное, кому-то удобно, кому-то нет. Вам удобней как в java - хорошо, кому-то удобней как в форте - ну и замечательно. :)

а все начиналось с «категорического нельзя».

нет. (последнее предложение)

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

Вообще-то, я с первого сообщения об этом и говорю. Если «подходящего» fallback для функциональности нет, то придётся это обрабатывать самостоятельно. И код в С++ или джаве будет одинаковый, по сути.

И код в С++ или джаве будет одинаковый, по сути.

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

твое первое сообщение - это вот это чтоли?

не будет. на жаве будет использоваться рефлешкен. на C++ общего решения просто нет.

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

буду ждать с нетерпением.

Итак, обещанные примеры обеспечения C++ API с сохранением обратной совместимости.

Use case: бинарник, собранный с использованием API v2, который, тем не менее, должен запускаться и работать как на системе, в которой есть только библиотека, обеспечивающая API v1, так и на системе, в которой есть библиотека, обеспецивающая API v2.

Код, использующий такое API:

static std::string dumplocation(geo const &g)
{
    std::ostringstream os;
    os << g.latitude() << "/" << g.longitude();
    if (version::apilevel() >= 2)
    {
        // This is new method, introduced in v2
        os << "/" << g.altitude();
    }

    return os.str();
}

void test()
{
    std::cout << "We're running on system v" << version::apilevel() << "\n";

    geo g;
    std::cout << "my location: " << dumplocation(g) << "\n";
    if (version::apilevel() >= 2)
    {
        // This is new class, introduced in v2
        map m;
        std::cout << "map location: " << dumplocation(m.location()) << "\n";
    }

    try
    {
        // This is class, defined in v1, but deprecated in v2
        md m;
        std::cout << "md altitude: " << m.location_altitude() << "\n";
    }
    catch (std::exception &e)
    {
        std::cerr << e.what() << "\n";
    }
}

Рассмотрено три случая:

- Класс «geo» с двумя методами в API v1, в API v2 в него добавлен новый метод

- Класс «map», отсутствующий в API v1 (добавлен в API v2)

- Класс «md», существующий в обеих версиях, но объявленный устаревшим в API v2.

Сначала - решение «в лоб», которое, тем не менее, прекрасно работает на современных операционных системах, в которых dynamic linker резолвит внешние символы «по требованию» (OS X и GNU/Linux этому требованию соответствуют).

$ git clone -b master https://github.com/crystax/cxx-api-example.git
.......

$ cd cxx-api-example

$ make all
.......

$ make run
=== Run with libv1:
LD_LIBRARY_PATH=bin/linux/:bin/linux/libv1/ ./bin/linux/app
We're running on system v1
my location: 1.1/2.2
md altitude: 1.3
=== Run with libv2:
LD_LIBRARY_PATH=bin/linux/:bin/linux/libv2/ ./bin/linux/app
We're running on system v2
my location: 1.1/2.2/3.3
map location: 1.1/2.2/3.3
Method md::location_altitude() is deprecated! Use geo::altitude() instead!

К сожалению, не везде dynamic linker столь умный (или же по какой-то причине загрузка executable требует немедленного резолвинга всех внешних символов. В этом случае разработчик API берет эту работу (ленивую загрузку внешних символов) на себя, предоставляя две библиотеки для пользователя - статическую с интерфейсом на C++, и динамическую, которая присутствует на целевой системе, с интерфейсом, известным внутри реализации C++ API, и до которой пользователю API нет никакого дела, т.к. он с ним не работает. В этом случае используется dlsym для динамического определения наличия символа.

$ git clone -b generic https://github.com/crystax/cxx-api-example.git cxx-api-example-generic
.......

$ cd cxx-api-example-generic

$ make all
.......

$ make run
=== Run with libv1:
LD_LIBRARY_PATH=bin/linux/:bin/linux/libv1/ ./bin/linux/app
We're running on system v1
my location: 1.1/2.2
md altitude: 1.3
=== Run with libv2:
LD_LIBRARY_PATH=bin/linux/:bin/linux/libv2/ ./bin/linux/app
We're running on system v2
my location: 1.1/2.2/3.3
map location: 1.1/2.2/3.3
Method md::location_altitude() is deprecated! Use geo::altitude() instead!

Работа того же кода под Android:

$ make run NDK=/opt/android/crystax-ndk-10.2.0
=== Deploy binaries to device
adb shell 'test -e /data/local/tmp/cxxapi && rm -r /data/local/tmp/cxxapi'
adb shell 'mkdir -p /data/local/tmp/cxxapi'
adb shell 'mkdir -p /data/local/tmp/cxxapi/libv1'
adb shell 'mkdir -p /data/local/tmp/cxxapi/libv2'
adb push /opt/android/crystax-ndk-10.2.0/sources/crystax/libs/armeabi-v7a/libcrystax.so /data/local/tmp/cxxapi/
4349 KB/s (3296588 bytes in 0.740s)
adb push /opt/android/crystax-ndk-10.2.0/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi/libgnustl_shared.so /data/local/tmp/cxxapi/
3556 KB/s (5930856 bytes in 1.628s)
adb push bin/android/libv1/libv.so /data/local/tmp/cxxapi/libv1/
3973 KB/s (69460 bytes in 0.017s)
adb push bin/android/libv2/libv.so /data/local/tmp/cxxapi/libv2/
4236 KB/s (72188 bytes in 0.016s)
adb push bin/android/libapp.so /data/local/tmp/cxxapi/
3477 KB/s (68496 bytes in 0.019s)
adb push bin/android/app /data/local/tmp/cxxapi/
1510 KB/s (7056 bytes in 0.004s)
adb shell 'chmod 0700 /data/local/tmp/cxxapi/app'
=== Run with libv1:
adb shell 'cd /data/local/tmp/cxxapi && LD_LIBRARY_PATH=/data/local/tmp/cxxapi:/data/local/tmp/cxxapi/libv1 ./app'
We're running on system v1
my location: 1.1/2.2
md altitude: 1.3
=== Run with libv2:
adb shell 'cd /data/local/tmp/cxxapi && LD_LIBRARY_PATH=/data/local/tmp/cxxapi:/data/local/tmp/cxxapi/libv2 ./app'
We're running on system v2
my location: 1.1/2.2/3.3
map location: 1.1/2.2/3.3
md altitude: Method md::location_altitude() is deprecated! Use geo::altitude() instead!

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

Второй способ, когда API разделяется на static и shared части, чуть более трудоемок для разработчика API (но не очень, т.к. педалить вручную переходники не надо, это все хорошо автоматизируется в виде кодогенерации), но с точки зрения пользователя этого API разницы нет вообще никакой. Зато такой способ будет работать всегда, не полагаясь на особенности реализации dynamic linker-а.

В примерах намеренно не используется C++11, чтобы избежать нерелевантных выкриков из зала в духе «C++11 совсем недавний и мало где поддерживается».

На этом все. Ссылки на репозиторий на гитхабе я привел. Можете проверить у себя. Если есть вопросы, готов ответить.

твое первое сообщение - это вот это чтоли?

Ага.

на C++ общего решения просто нет.

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

На этом все. Ссылки на репозиторий на гитхабе я привел. Можете проверить у себя. Если есть вопросы, готов ответить.

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

так-то да, это интересный хак. с классами сработает, или только с методами?

(upd: увидел про class map в коде, таки работает)

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

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

вопросы есть. почему ты проигнорировал просьбу не предъявлять решения уровня хелловорлдов?

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

по моим прикидкам, эта штука сломается уже на втором релизе, если у тебя будет пара десятков классов использующих друг друга.

Прикидки неверные. Я такие API делал, и они переживали много версий. Приведенный мною ранее пример C++ API в Symbian тоже это подтверждает. Это исключительно вопрос продуманности API, и он не имеет отношения к языку реализации. Непродуманный API развалится на втором релизе вне зависимости от языка - будь то Java, Objective-C или C++.

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

Это вопрос, ортогональный первоначальному. Безусловно, обеспечивать бинарную совместимость тяжелее, чем не обеспечивать. Тем не менее, если это нужно, то обеспечить можно, и на C++ в том числе.

Давно пора минимальный api ставить в 10, а это как раз андроед 2.3.3. Тем более, что api 9 сто лет как выпилен из андроед-манагера в пользу api 10.

В NDK нет API level 10, т.к. разницы между API level 9 и API level 10 на нативном уровне нет. Поэтому в качестве миниального используется API level 9.

Тут вообще не всё так просто. Тот же интеловский компилер подстраивается под платформу, то есть под виндой он будет совместим с майкросовтовским. Под линуксом - с GCC. Насколько clang сейчас полноценно работает под виндой хз, но, вроде, они собирались так же делать.

Безусловно, так и есть. Но в контексте разговора про обеспечение ABI под Android нет смысла говорить о поведении icc под Windows. В случае сборки под Linux и Android все компиляторы (gcc, clang и icc) используют единый ABI.

Безусловно, обеспечивать бинарную совместимость тяжелее, чем не обеспечивать. Тем не менее, если это нужно, то обеспечить можно, и на C++ в том числе.

Да, но учитывая то, что ключевым моментом в программировании является управление сложностью (потому-то и выдумана ОО-технология, - именно для управления сложностью, а не потому что просто взяла да и возникла такая идея у бородачей), то чем тяжелее решения, тем дальше стоит от них держаться. К тому же, библиотеки на цепепе обладают такой мерзостью как манглинг. А это доставляет дополнительно ещё одну баррикаду, на преодоление которой нужно опять городить ещё один косвенный уровень в виде extern «C» { /* C API to ugly C++ */ }. Поэтому низкоуровневые библиотеки лучше уж писать на C.

Поэтому низкоуровневые библиотеки лучше уж писать на C.

Абсолютно без разницы на чем написаны «низкоуровневые библиотеки». Это целиком и полностью забота разработчиков таких библиотек. Но внешний интерфейс надо предоставлять в виде C API, т.к. это де-факто наименьший общий знаменатель в современном мире.

Ну а я показал примером как, используя ту же технику, обеспечить еще и C++ API (если это требуется).

Абсолютно без разницы на чем написаны «низкоуровневые библиотеки». Это целиком и полностью забота разработчиков таких библиотек.

Почти всех испортила концепция «повторного использования от сферического чужого разработчика». Я тебе про сложность разработки «таких библиотек». А ты мне в ответ: «пусть некий разработчик библиотеки сам разбирается». Поэтому я тебе ещё раз говорю с позиции разработчика библиотек, что низкоуровневые библиотеки лучше писать на C, потому что проблем меньше :-) А вообще, все эти подходы с пимплами в цепепе или void *dummy в це устаревшие, как говно мамонта. Это всё задача машины, потому технологии JIT-компиляции многим лучше, чем этот геммор с динамическими линковками.

Поэтому я тебе ещё раз говорю с позиции разработчика библиотек, что низкоуровневые библиотеки лучше писать на C, потому что проблем меньше :-)

Это индивидуально. Я вот тоже разработчик библиотек (низкоуровневых, да), но если есть выбор, писать на C или C++, выбираю C++. Т.к. с моей точки зрения, у C перед C++ никаких преимуществ нет, за исключением простоты изучения (но это меня никак не волнует, т.к. вопрос изучения давно пройден и новые вещи изучаются и начинаются использоваться естественным образом).

Тем не менее, я никому этой точки зрения не навязываю. Хотите писать на C? На Java? На Haskell? Lisp? Ради бога. Только не указывайте, на чем писать мне. Мне виднее.

А вообще, все эти подходы с пимплами в цепепе или void *dummy в це устаревшие, как говно мамонта.

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

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

Планируете ли добавить python, кстати? Было бы здорово

Очень хотелось бы. Но руки пока не доходят.

Кстати, меня всегда мучал вопрос в чем проблема сборки python под android?

Принципиальной проблемы нет. Это вопрос потраченного времени и приложенных усилий. Пока что никто не потратил достаточно ресурсов на это, поэтому имеем то, что имеем.

Т.к. с моей точки зрения, у C перед C++ никаких преимуществ нет, за исключением простоты изучения

Из этого следует, что имеются некие преимущества у Си++ перед Си? Пожалуйста, назови их.

Только не указывайте, на чем писать мне. Мне виднее.

Я и не указываю, я говорю, что с моей т.з. цепепе - говно.

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

Непонятно, почему такой вывод возник. Я же сказал, что не говно - JIT-компиляция из декларативного языка, пусть даже прямо в тот самый маш. код.

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

Да в этом предложении только воздух и ущербные языки упомянуты :-)

И делаю вроде неплохо, судя по результату.

Ну респект тебе и уважуха. (Без иронии!)

PS. Жду аргументов про Си.

PS. Как видно из примера, который ты привёл и выложил на гитхаб, ты испльзуешь условную компиляцию. Тут как-то пробегал кукарекающий любитель шаблонов цепепе, который утверждал, что препроцессор ненужен и всё можно сделать на шаблонах :-) Они же тьюринг-полные :-) :-) :-)

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

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

Прикидки неверные. Я такие API делал, и они переживали много версий.

не поверю, пока своими глазами не увижу. извини, в данном вопросе одних слов недостаточно. вот будет у тебя проект масштаба Qt, например, на крестах, с нативным крестовым API, и чтобы вот это все работало, как в твоем примере, на протяжении всего жизненного цикла (всмысле, как если бы Qt 1,2,3,4,5 были бы вот так друг с другом совместимы) тогда можно продолжать разговор.