Вышел CrystaX NDK 10.2.0

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

Какое отношение это имеет к API? Что, в текущем Android Java API требуется reflection?

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

Вот только речь не о классах и методах, а об API. Отсутствие рефлекшна обходится элементарно — плюсовый SDK просто делится на две части, одна вкомпиливается в приложение, другая используется внутри статически линкуемой части как platform API.

Или вы не в курсе, что проект, собранный в Visual Studio 2013 с STL из c++11, прекрасно заработает на WinXP, которая на 10 лет старше c++11?

У Symbian было много недостатков, но сам API был на C++, OS пережила много мажорных релизов, и бинарная совместимость поломана не была.

зато теперь понятно, почему она загнулась.

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

зато теперь понятно, почему она загнулась.

Виндофон и с C# загнулся несмотря на старания Шлюхэлопа, что дальше?

Какое отношение это имеет к API?

это был ответ на ту часть, про которую ты написал «Остальные проблемы не имеют отношения к C++», т.е. не про API.

Что, в текущем Android Java API требуется reflection?

да. для совместимости программ с предыдущими версиями android.

половина примеров кода в SDK напичкана рефлекшеном под завязку.

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

Раньше с вами дискутировать было интереснее.

ну я раньше тоже считал что общаюсь с опытным профессионалом.

интегрированными в язык и были бы лучше плюсовые IDE / SDK

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

Кроме того, была такая BeOS, написанная на ущербном языке цепепе. Была и загнулась, как и Symbian. Не пишите, дети, OS на цепепе. А лучше, вообще ничего не пишите на цепепе, если не хотите, чтобы ваши проекты не постигла участь вышеупомянутых ненужностей :-)

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

настолько сложно, что проще выкинуть цепепе и забыть как страшный сон.

Ну кому как, а XCode и QtCreator с плагином ClangCodeModel расчитывают автодополнение правильно для сколь угодно запутанного кода, за исключением редчайших случаев, где просто у разработчиков не дошли руки сделать нормальное дополнение в заданном контексте.

да. для совместимости программ с предыдущими версиями android.

Reflection — один из вариантов реализации совместимости, а не обязательное требование. Вы ещё скажите, что без сборки мусора в плюсах невозможно управлять памятью и она течёт по 10МБ в секунду даже в hello world.

Что, в текущем Android Java API требуется reflection?

да. для совместимости программ с предыдущими версиями android.

половина примеров кода в SDK напичкана рефлекшеном под завязку.

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

Огосподибожемой! Я-то понимаю. И утверждаю, что все это можно сделать на C++. На том самом, который без reflection. Собственно, мы и делаем. И через некоторое время представим на суд общественности. Практика, знаете ли - критерий истины.

ну я раньше тоже считал что общаюсь с опытным профессионалом.

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

Собственно, мы и делаем. И через некоторое время представим на суд общественности. Практика, знаете ли - критерий истины.

представите на суд общественности _ЧТО_? свою операционку с API на C++? давай не будем давать неосуществимые обещания, а просто посмотрим на ваше виденье как это реализовать на C++. я весь внимание.

юз-кейс: 1 бинарь, собранный с SDK/API версии #2, использующий новые фичи если они доступны, либо использующий фичи версии #1 в противном случае. бинарь должен работать с рантаймом версии #1.

(и если можно, просьба обойтись без очевидных глупостей, которые решают задачу в хеллоуворлде — нужно решение которое будет работать, скажем, 20 лет, с тысячами классов в SDK)

На вашем месте я бы постеснялся столь глупо высказываться на публичном форуме.

Можно и на «ты», невелика я птица :-) А чего мне стесняться? Я тебе факты говорю - беос загнулся. Люди, которые выбились в тузы, типа Линуса, говорят, что на цепепе писать ядра операционок - только искать себе неприятности. Я же знаю, что цепепе - это мерзкий язык, который очень обманчив, и привлекателен лишь тем, что популярен. Я знаю цепепе и могу на нём писать хоть на шаблонах, хоть в абстакных классах, хоть в пимпл, хоть используя ущербный препроцессор. И поэтому я могу себе позволить заявить, что цепепе, как язык - полное говно. Потому что он не позволяет абстрагироваться и решать непосредственно задачу. Борьба со сложностью с помощью классов позволяет рассуждать лишь на невысоком уровне абстракции. Там, в цепепе, сплошь и рядом ловушки и готчи, везде засады, упоротая семантика, уродливый язык шаблонов. Можно писать на цепепе, базара нет, но удовольствия это не доставляет. Эти ваши паттерны. Ну ведь это же уродство, это просто хаки, которые показывают, как решать проблемы на языке, который не позволяет выразить идеи непосредственно. Единственное ценное, что есть в цепепе - это деструкторы, но тогда лучше забыть об исключениях, потому что засада и здесь - из деструктора генерить исключения нельзя «а то произойдут ужасные вещи» (c) Саттер :-)

представите на суд общественности _ЧТО_? свою операционку с API на C++?

Свой C++ API для Android. Над этим идет работа. И совместимость обеспечим.

юз-кейс: 1 бинарь, собранный с SDK/API версии #2, использующий новые фичи если они доступны, либо использующий фичи версии #1 в противном случае. бинарь должен работать с рантаймом версии #1.

(и если можно, просьба обойтись без очевидных глупостей, которые решают задачу в хеллоуворлде — нужно решение которое будет работать, скажем, 20 лет, с тысячами классов в SDK)

Если позволите, я это сделаю не сегодня. Мне надо выспаться и завтра трудный день, а форумные баталии мне в зачет не пойдут. Тем не менее, завтра я потрачу время и дам вам ответ на сей вопрос. Развернутый и с примерами.

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

Свой C++ API для Android. Над этим идет работа. И совместимость обеспечим.

так он и щас есть, JNI называется. то что вы завернете его в какую-то более высокоуровневую обертку — ничего не меняет. вы по прежнему используете java на нижнем уровне. и именно она берет на себя решение проблем обратной совместимости, а не C++, как ты пытаешься себе вообразить.

Тем не менее, завтра я потрачу время и дам вам ответ на сей вопрос. Развернутый и с примерами.

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

Вопросы по делу - это одно, а эмоции оставьте при себе.

по результатам завтрашнего ответа.

Можно и на «ты», невелика я птица :-)

Спасибо.

А чего мне стесняться? Я тебе факты говорю - беос загнулся.

Факт. Только причины не в C++.

Люди, которые выбились в тузы, типа Линуса, говорят, что на цепепе писать ядра операционок - только искать себе неприятности.

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

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

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

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

Если вам нужен Haskell для «решения непосредственно задачи», ну так и берите его. Тем не менее, есть много use-case-ов, когда нужен C++, а не Haskell. И позиция «вот вам Java, а C++ вам не нужен» - как минимум недальновидная (а если честно, то и просто глупая). Мне лучше знать, что мне нужно в конкретном случае. И тот факт, что C++ кривой, ничего не меняет.

Свой C++ API для Android. Над этим идет работа. И совместимость обеспечим.

чиста к слову — у меня есть свой API к андроиду на C, еще и кроссплатформенный ко всему — с гуем, звуком, поддержкой всяких там блютусов, и т.п. работает на android1.6+, линуксе и макоси. на не-андроидах имитирует поведение activities, services, и т.п., что позволяет отлаживать activity lifecycle, поддержку разных разрешений, и т.п., все это без эмулятора и девайса, прямо в xcode например. так что непонятно чем ты удивить хотел.

так он и щас есть, JNI называется.

Это очень неудобный API. Кроме того, очень ошибко-емкий (т.е. используя JNI напрямую, легко наплодить кучу багов). Это мы и хотим исправить.

то что вы завернете его в какую-то более высокоуровневую обертку — ничего не меняет. вы по прежнему используете java на нижнем уровне. и именно она берет на себя решение проблем обратной совместимости, а не C++, как ты пытаешься себе вообразить.

Вы сами себе противоречите. То, как у нас будет реализован C++ API, вас, как пользователя этого API, волновать вообще не должно (за исключением очевидных случаев, когда реализация неоправданно тормозная или глючная). И внутри реализации нет вообще вопросов о бинарной совместимости, поэтому там можно использовать хоть Java API, хоть dlopen/dlsym, хоть вообще полностью свою реализацию.

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

Тем не менее, завтра я потрачу время и дам вам ответ на сей вопрос. Развернутый и с примерами.

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

Договорились.

чиста к слову — у меня есть свой API к андроиду на C, еще и кроссплатформенный ко всему — с гуем, звуком, поддержкой всяких там блютусов, и т.п. работает на android1.6+, линуксе и макоси. на не-андроидах имитирует поведение activities, services, и т.п., что позволяет отлаживать activity lifecycle, поддержку разных разрешений, и т.п., все это без эмулятора и девайса, прямо в xcode например. так что непонятно чем ты удивить хотел.

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

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

я не совсем понимаю, о чем вы спорите.

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

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

И боюсь, что обещанный пример C++ API с сохранением совместимости вы воспримете с недоумением

ну я знал что спрашивал.

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

Откровенно говоря, я уже устал повторять. Я прекрасно понимаю разницу. Тот факт, что наша обертка «бандлится в прогу», конечно, облегчает нам задачу, т.к. в этом случае заботиться об обратной бинарной совместимости не так важно.

Тем не менее, обеспечение обратной бинарной совместимости для C++ API - вовсе не фантатическая нерешаемая задача, и я такого рода задачи уже решал. Коротко говоря, pimpl+mangle/demangle+dlsym - наше все. Подробнее - завтра, если еще будет интересно (а если не будет интересно вам, то возможно, будет интересно другим читателям).

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

Такой API просто делится на две части: библиотека удобных классов, статически линкуемая с приложением, и C++ API, на который эта библиотека опирается. C++ API для библиотеки классов не обязан быть удобным и благодаря этому может поддерживать способы расширения в стиле OpenGL.

P.S. Ну или играться с подгрузкой разделяемых библиотек, как в CrystaX NDK.

Такой API просто делится на две части: библиотека удобных классов, статически линкуемая с приложением, и C++ API, на который эта библиотека опирается. C++ API для библиотеки классов не обязан быть удобным и благодаря этому может поддерживать способы расширения в стиле OpenGL.

Совершенно верно! Вы выразили мою мысль, которую я (из-за усталости) не мог кратко сформулировать, а обещал вместо этого пример в коде. Ну и наличие/отсутствие новых API определяется через dlsym.

> Есть куда более безгеморные области применения лба.
И? Вы пишете как человек, который познал дзен. Хотелось бы продолжения. Пишу (пока) без иронии.

Да пофиг, иронизируйте :) - реальность это не меняет. Дзен я познал с ДотНЕТом, который накрыл весь этот бредомусор из сипипей, дельфей, фокспрош и прочих ваткомов. Пишу на C# обычные виндовые приложения. Да, иногда что-то приходится глубоко рыть, где-то докачивать библиотечки, но в целом процесс программирования напоминает именно то, за что боролись деды: я РЕШАЮ ЗАДАЧИ, а не трачу время на портирования, хаки, ifdef'ы, попутно проверяя сорсы на компилябельность в ещё трёх компиляторах.
Мобильный рынок в этом плане так же уныл и безысходен, как Линукс в FOSS'е: засилье ведроидов не даёт стимула писать что-то мобильное, а мобильная вендоплатформа ещё сыра и анально огорожена (посмотрим, что там будет с «десяткой»).
Поэтому мне очень жаль людей, тратящих столько сил на борьбу с ветряными мельницами - пусть с ними воюет тот, кто эту галиматью создал - Гугл. И когда эта поисковая шпана наконец подавится своей платформой, к ним придёт прозрение, что нельзя писать хелловорлды на 5 экранов! Мобильные приложения - перделки по своей сути, они не стоят усилий, которые запрашивают.

VS2015 уже поддерживает сборку и отладку под андроид

На С++? Издеваетесь?? :) Только C#, ни шагу в средневековье!

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

Во-первых, кривая система сборки Python'а, требующая плясок с бубном для кросс-яомпиляции, во-вторых, кривой bionic, что сведено на нет libcrystax'ом, в-третьих, получившийся бинарь всё равно работает через пень-колоду (там, простите, даже у math проблемы при прохождении тестов). Ну и тот факт, что гуя для этого самого Python'а нет, можно только в терминале с ним работать. А так - разобраться в сборке, взять standalone-toolchain и - вперёд!

Ах да, ещё же есть чудесное требование для 5.0+-девайсов под названием -fPIE. Бинарь, полученный без этого чудного флага, нельзя (на самом деле, можно, но только с жутчайшими костылями) запустить на устройствах >=api21, зато если собирать с ним - не запустишь на pre-Jellybean, сегфолтится. Такие вот два стула.

На С++? Издеваетесь?? :) Только C#, ни шагу в средневековье!

на всем, что поддерживается android sdk/ndk.

C# тоже можно (Xamarin).

Коротко говоря, pimpl+mangle/demangle+dlsym - наше все.

... а COM это как раз и есть одна из реализаций вот этого. костыль т.е. ты когда-нибудь вообще пробовал писать большие проекты на крестах, использующие COM массово? я не знаю кому как, а на мой взгляд — результат полная гадость.

Нужен именно ndk. С ndk-build'ом и ndk-stack'ами.

Тем не менее это именно то, как работают современные ОС

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

Что значит «зачем»? Затем, чтоб люди пользовались, очевидно.

Это сторонний проект, зачем его тянуть в ndk? Хотите поддержку андроеда в boost, ну так шлите патчи разрабам буста. Или делайте форк буста, только не запихивайте его в ndk.

это все портировать под андроид я не знаю.
zlib http://www.zlib.net

Оно есть из коробки. Обычно собрано с оптимизацией под конкретную архитектуру.

Остальное или есть или собирается с пол пинка.

Такой был. Это Trolltech Greenphone, а чуть позже смартфоны на Symbian от Nokia, которые похоронил Microsoft.

И приложения с этим sdk были еще теми уродцами, размером с планету.

Сначала отпугивает, но потом понимаешь, что он лучше, проще и удобнее, чем C++.

- Армяне лучше чем грузины!
- Чем лучше?
- Чем грузины.
(с) народный анекдот.

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

Покупали не майнкрафт, а пользователей.

а для этого надо собирать с минимальным API level (в нашем случае это 9, т.е. Android 2.3

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

от факт, что другие компиляторы (Microsoft) этому ABI не следуют

ага, т.е. все таки стандарта нет?

С такой логикой и на C++ стандарта нет и не было (в головах разработчиков из майкрософта).

ты ошибаешься. в C++ нет рефлекшена

Так это и хорошо - меньше шансов получить bottleneck там. Как по мнет, так и rtti тоже нафиг не нужен.

Дзен я познал с ДотНЕТом,

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

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

Так это и хорошо - меньше шансов получить bottleneck там. Как по мнет, так и rtti тоже нафиг не нужен.

полностью согласен.

Это сторонний проект, зачем его тянуть в ndk? Хотите поддержку андроеда в boost, ну так шлите патчи разрабам буста. Или делайте форк буста, только не запихивайте его в ndk.

не пойму, чем тебе плохо что они пихают буст в NDK? это же NDK для крестовых программеров, которым буст часто нужен — экономия времени. или я чего-то не понимаю? а тем кому все это не надо, типа меня, и обычного NDK с головой.

// буст не юзал

не пойму, чем тебе плохо что они пихают буст в NDK?
это же NDK для крестовых программеров,

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

которым буст часто нужен

Ну что тут сказать. Я рад, что мне с такими приходилось работать редко. У них свое, особое, видение подхода к разработке проекта.

С такой логикой и на C++ стандарта нет и не было (в головах разработчиков из майкрософта).

ORLY?

Это как в рендерер впихнуть физический движок, загрузчик ресурсов, парсер конфигов, етц.

s/рендерер/игровой движок/ — и все становится на свои места (хотя аналогия и неуместна вообще).

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

С такой логикой и на C++ стандарта нет и не было (в головах разработчиков из майкрософта).

http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2...

И по ссылке видим подтверждение моих слов. Даже c++11 в еще не вышедшей vs_2015 не полностью поддерживается. Что уж говорить про c++14.

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

s/рендерер/игровой движок/ — и все становится на свои места (хотя аналогия и неуместна вообще).

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

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

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

- наш отличный автомобиль по скромной стоимости.
- а что это за труп лежит в багажнике?
- да он вам ничего не будет стоить.
(с) народный анекдот.

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

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

пришлось бы весь софт раз в полгода пересобирать или переписывать, после каждого релиза qt ломающего API.

API они почти не ломали. Да, в новых версиях, старые функции могут выкидывать, но это сознательное решение. Хочешь - используй старую версию, хочешь - обновляйся и подправь код, что, впрочем, не всегда и требуется. Будь Qt «основой» чего-нибудь - пришлось бы оставлять всё старое барахло «навечно». Язык бы тут никак не мешал и не помогал бы.

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

и поюзать новые фичи android5, но при этом прога будет работать на android 1.6, автоматически отключая эти фичи в рантайме. все это в 1 бинаре.

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

Тот факт, что другие компиляторы (Microsoft) этому ABI не следуют,

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