Можно ли конвертнуть код написаный на С++ в код 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

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