Android портирован на C#

Но в случае с C++ именно програмеру придется собирать все это дело под разные платформы. Да и тестировать сложнее будет.

Спасибо, я в курсе как внутри устроены APK :) Раньше Гугл предлагал пихать все в один APК, независимо от целевого девайса, но с относительно недавних пор можно загружать несколько APK одного приложения под разные целевые платформы. Например, чтобы уменьшить их размер, нe поставляя библиотеки под все платформы, a только нужные. Или, например, выгружать версию с ActionBarSherlock под старые версии Android, а для Honeycomb и выше сделать нативный интерфейс на Holo.

>Coding in ASM since 1993
На этом закончим наш спор.

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

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

если честно, всегда считал, что рисовать гуй в одном потоке с приложением, которое должно че-то в бэкграунде делать, — это моветон.

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

OpenGL нужен чтобы что-то более сложное рендерить, чем список с элементами.

В конечно счете вам нужно рендерить кучу векторных примитивов. Именно по этому в том же WPF UI рисуется через DirectX.

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

А как влияют дженерики?

Для начала тест следует хотя бы привести к корректному состоянию, ибо сейчас он что для явы, что для Mono считает попугаев, т. к. замеряет в т. ч. загрузку рантайма, библиотек и время работы JIT, что в нормальном приложении происходит один раз на старте. Сейчас если включить в Mono AOT-кэш сборок (устанавливается в переменной окружения MONO_AOT_CACHE, dll-ки компилируются в машинный код один раз, нативные бинарники лежат в ~/.mono/aot-cache), то тест покажет совершенно иные результаты, но они всё равно будут некорректны. По-хорошему же надо вынести весь код теста в функцию, прогнать её один раз, после чего вызвать снова и уже тогда считать затраченное время.

А вообще компилить следует gmcs (а лучше компилятором от MS), использовать параметры -O=all --gc=sgen, в идеале ещё и само Mono собрать с поддержкой LLVM, тогда, соответственно, добавить параметр --llvm. Ну вот как-то так.

Ну есть же ещё J#. При наличии явовских библиотек классов из IKVM никаких проблем с переходом на CLR быть не должно.

процесс миграции между C# и Java не такой уж затратный по времени. Это не Питон <--> Руби.

Но чтобы сменить парадигму, нужна очень веская причина. Для Гугла. И претензии Оракла здесь ни при чем. Судиться — это удел юристов, а не программистов.

Веских причин может быть две: 1) архитектурная; 2) политическая.
В случае 1) недостаточно просто «конвертнуть» код и подивиться недюжинной экономии ресурсов.
Нужны:
— тщательное тестирование работоспособности всех компонентов системы,
— проверка безопасности такой системы,
— создание и длительное нагрузочное/повседневное тестирование рабочих прототипов,
— подробное прогнозирование возможных финансовых потерь своих/разработчиков сторонних приложений, оценка затрат сторонних разработчиков на переход с одной платформы на другую;
— подготовка средств разработки и тестирования ПО/
— и так далее.

Если в результате выполнения всех этих пунктов окажется (теоретически), что компания+разработчики+пользователи приобретут за МИНИМУМОМ временных-финансовых затрат РЕАЛЬНЫЙ профит (компании), упрощение разработки/тестирования (разработчикам), счастье (пользователям),
тогда да, можно говорить о том, что такой переход оправдан.

2) политическая — это решение сверху (например, что маловерятно, под давлением внешних факторов), которое всё равно приведет к необходимости всего, что было в пункте 1).

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

P/Invoke даёт возможность передавать неуправляемому коду делегат. Т. е. для сишного кода это выглядит как обычный указатель на функцию, который потом CLR разворачивает в нужный вызов.

Ну ещё следует понимать, что в CLR есть возможность нормально работать с памятью вручную. В шарпе это выражено как ключевое слово unsafe, внутри блока которого этот управляемый язык превращается, фактически, в обычный C, спокойно перемалывающий указатели, имея при этом доступ к управляемой среде.

Если я правильно Вас понял, то стоит смотреть на эту статью, чтобы вызывать Managed-методы из неуправляемого кода…
Я сам экспериментировал с этим (в частности на iPhone) и это вполне себе работает. Думаю и на андроиде и на других платформах это будет работать аналогично.

Слушайте, вы издеваетесь? Я вам дал ссылку на вашей же вики, в которой видно, что стандартизирован весь .NET 2.0 кроме частей завязанных на винформы, студийный дизайнер форм, GDI+, ADO и IIS, т. к. это по сути мосты к гвоздями приколоченным к Windows технологиям.

Вон, гугл тоже так думали когда Dalvik создавали.