Можно ли конвертнуть код написаный на С++ в код Java (ну как код Паскаля можно автоматом перегнать в код С++).
Может есть проги специальные? 

Не слыхал, да и нетривиальная это задача. Как минимум, API конвертации не поддается. 

Анор, как ты себе это представляешь? Программа на C++ использует соответсвующие средства системы для работы с файловой системой, сетью, графикой и т п. Java-программа использует стандартные библиотеки, поддерживаемые JVM. 

А идиому "Захват ресурса - есть инициализация объекта" как конвертить? 

Конечно есть, например С2J, C2J++, Ephedra и куча других - посмотри в гугле...



http://www.jazillian.com/how.html
а все остальное оборачиваем JNI и вперед!
 

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

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

Вспомним, что некоторые библиотечные классы (точнее, их методы) как раз и реализованы через JNI - просто иначе никак!
И кросс-платформенное приложение, которое взаимодействует, например, с ком-портом, мы никак не напишем на Java (хотя можно сделать по аналогии с этими библиотечными классами - для каждой ОС - библиотеку + JNI - и сказать, что оно кроссплатформенно, хотя и не pure-java).



Замечательно поддаются конвертации - написать конвертор из С++ в Java (не считая библиотек - про некоторые библиотечные функции и их представление после конвертации написано в статье по ссылке, что я дал)  не так уж сложно самому - нудно и долго, конечно, но вполне реализуемо... 
Это не голосовное утверждение - почти все мои курсовики и дипломная + несколько
проектов связатны с конвертацией из одного языка в другой (или расширенного языка в таргет)...
Тем более что в джава можно реализовать псевдо-множественное наследование классов через
интерфейсы - по свойствам оно ничем не будет отличаться от множественного наследования классов в
С++.
И вообще - такой предмет как "Теория языков и трансляций" ничего не говорит!? - не знаю, во всех
ли тех. вузах он входит в программу..

 

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

Beard - спасибо, полез искать 

В том то и дело, что БИБЛИОТЕЧНЫЕ классы - т е те, что входят в состав JRE! То бишь собственно бинарники программы не будут отличаться в общем случае в зависимости от платформы, они будут одинаково обращаться к библиотеке ( javax.comm в случае ком порта), а то, что дальше - это уже дело JRE и для каждой платформы у нее своя реализация. А если речь идет о конвертации C++-программы в Java, то JNI идет в коде программы, т е теряется независмость от платформы. Смысл то такой конвертации, если она все равно сможет исполняться только на той оси, под которой работает программа на С++? 

Естественно, в тех случаях, когда что-то невозможно сделать стандартными библиотеками Java и приходится прибегать к явному JNI, тогда при конвертации ничего не теряется. Однако ничего и не приобретается. Опять таки, есть ли смысл в подобной конвертации? Только если реализовать, как ты говоришь, для каждой оси свою либу. 

to Amortisator: Мы, наверное, о разных вещах говорим...
Есть задача из области реинжиниринга - сорцы программы C++ -> сорцы Java.
Если наши сорцы на С++ на выходят за рамки Standart C++ (т.е. не используют сторонних
библиотек), то проблем никаких (может я и вру, но ничего в стандарте C++, что нельзя
реализовать (найти аналог) на Java, нет! - если не прав, ткните).
Если же мы пользуем такие библиотеки, то у нас не получится
pure-Java приложение (и я с этим не спорю)... 
Тем более, если у нас, например, все жестко завязано на пользовательский интерфейс (придется буквально все ручками переписывать)..
Но мы хотим заставить (программа - минимум) сконвертированное
в Java приложение работать под исходную платформу (где и C++) - используя JNI мы этого добиваемся
(причем практически автоматом).
Кросплатформенность в смысле платформы (простите за тавтологию, да и за возможные опечатки - 
алкоголь из крови еще не вышел) Java естественно теряется...
Если этого кода (завязанного на JNI) немного (да если и много, то уж чего делать - босс сказал..), то мы также ручками доводим его до кросплатформенного (если есть возможность) решения - реинжиниринг произведен, все довольны.

Добавлено @ 21:41 


Да, я про это и говорил.
А приобрестись может то, что мы доведем этот код ручками до кроссплатформенного

Добавлено @ 21:46 
Вобщем, если главная цель - логика приложения (тем более при конвертации могут "отсекаться" даже 
паттерны проектирования) - мы много приобретаем для дальнейшего развития нашего проекта на 
новой платформе 

JNI упоминался как средство реализации функциональности сторонных библиотек. Если оставаться в рамках стандартной библиотеки C++ то да, почти для всего найдутся аналоги в JRE.

У меня есть кое-какой опыт создания трансляторов между ЯВУ. И навскидку при преобразовании C++ -> Java я вижу основную проблему:
Указатели. В общем случае адресную арифметику перенести на Java нельзя. Можно только распознать некоторые типичные случаи применения адресной арифметики и эмулировать ее с помощью массивов, спец. классов и т.д. В общем случае придется либо прибегать к помощи JNI, либо поднимать лапки.

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

Все остальное вроде решаемо.
Множественное наследование эмулируется интерфейсами и дублированием кода.
Шаблоны — тоже дублирование кода и, возможно, дженерики.

Наименьшая из проблем. Каждый блок в try..finally и вызывать деструкторы в finally.

И, наконец, не забываем про исключительную сложность самого парсера C++. Хотя конечно можно подцепить GCC-XML, OpenC++ или купить у EDG исходники фронтэнда 

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

Это сообщение отредактировал(а) Void - 5.6.2006, 23:32

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

А я имел ввиду как раз не средства самого языка (С++), а проблемы на уровне 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.