А я имел ввиду как раз не средства самого языка (С++), а проблемы на уровне API платформы. Однако, если говорить о языковых различиях, то и здесь, как указал Void, проблем не оберешься. По сути, надо готовиться к тому, что после конвертации среднестатической программы с С++ на Java, получится абсолютно нечитаемый и плохо поддерживаемый код. Как, например, такое: операции над указателем на указатель - придется в самом деле заводить ссылку объект, содержащий массив ссылок на другие объекты или просто на массив (проще, но будут имхо минусы), и далее детерминировать операции над указателем на указатель индексацией по массиву. Тут как минимум служба сопровождения может устроить забастовку 

А на reflection вообще б загнулись 


Либо пользовать Java-ские "дырки", типа sun.misc.Unsafe, что не есть хорошо - не поспоришь...



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

Ну если рассматривать подмножество языка без классов, шаблонов и т.д, чаще всего используемое при реализации алгоритмов, а использование STL транслировать ad-hoc, то еще как-то подъемно. Для конвертации пары функций можно и написать… Правда, для пары функций может оказаться достаточно copy&paste, find&replace 

Имхо, для данного случая — нереально.

Добавлено @ 23:42 

Я ни разу не спец в Java, так что если там есть unsafe, тем лучше 

Нет, ну почему… Раз мы можем навязать в своем коде single-root иерархию, проблем особых не будет.

Грамматика C++ не является контекстно свободной, не укладывается ни в LL(k), ни в LALR(1), которые могут разбирать большинство генераторов парсеров. Поддается GLR, но все равно лучше взять готовое решение, например на базе того же GCC. Существуют десятки компиляторов C++ и приличные в плане корректной поддержки всех конструкций можно перечислить на пальцах одной руки — это ли не свидетельство сложности задачи? 

а что у нас за случай? Автор вроде словом не обронился  .
Я в своё время как раз использовал конвертер для проекта из С++ в Java. C одной стороны find/replace конечно тоже поможет, но с другой там много чего ещё. 

Эта… ссылку в студию! На конвертер 

Вот именно. Как он вопрос с библиотеками-то разруливает? 

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

Ссылку не дам, проект 5 лет назад был.

Добавлено @ 00:01 
PPS: 
Насчёт библиотек:
Он просто вызовы функций пишет и всё. естесственно их не имплементирует 

Не совсем понял - можно поподробней?


Не спорю, но тем не менее это возможно, и есть
готовые решения (Зуев, например, написал приложение к русскому Ахо, Ульман, Сети, где описывается
грамматика С++ для YACC/bison, правда с кой-какими допущениями)


Это почему "абсолютно нечитаемый" (если опустить указатели на указатели на..., и то, мне помнится,
что-то неплохое придумали по этому поводу - не про читаемость, а про возможность реализовать
трансляцию на Java - попытаюсь найти и кинуть ссылку)?
Как я сказал, даже распространенные шаблоны (~GoF) "отсекаются"!
 

В сгененрированном по Java C++ коде все классы будут унаследованы от одного, скажем, JObject. Ничто нам не мешает сделать ряд виртуальных методов для рефлексии и саморегистрацию всех методов и членов в каждом классе. Многие C++ библиотеки таким образом обеспечивают свой собственный RTTI.


Угу, видел я эту грамматику. Вопрос в том, с какими именно допущениями  Разработчики GCC, начиная с версии 3.4, отказались от использования Bison и переключились на собственный вручную написанный рекурсивно-нисходящий парсер. Не от хорошей жизни, наверное, учитывая огромную инерцию такого большого проекта, и сколько на него завязано кода.

Есть еще Elkhound — генератор GLR-парсеров. С его помощью написан парсер C++ Elsa.