Цитата(Lamer George @ 4.6.2006, 09:49  ) |
| Не слыхал, да и нетривиальная это задача. Как минимум, API конвертации не поддается. |
А идиому "Захват ресурса - есть инициализация объекта" как конвертить?
| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Java: Общие вопросы > C++ --> Java |
| Автор: Анор 3.6.2006, 23:52 |
| Можно ли конвертнуть код написаный на С++ в код Java (ну как код Паскаля можно автоматом перегнать в код С++). Может есть проги специальные? |
| Автор: batigoal 4.6.2006, 09:49 |
| Не слыхал, да и нетривиальная это задача. Как минимум, API конвертации не поддается. |
| Автор: Амортизатор 4.6.2006, 10:48 |
| Анор, как ты себе это представляешь? Программа на C++ использует соответсвующие средства системы для работы с файловой системой, сетью, графикой и т п. Java-программа использует стандартные библиотеки, поддерживаемые JVM. |
| Автор: DeadSoul 4.6.2006, 11:35 | ||
А идиому "Захват ресурса - есть инициализация объекта" как конвертить? |
| Автор: Beard 4.6.2006, 11:59 | ||||
Конечно есть, например С2J, C2J++, Ephedra и куча других - посмотри в гугле...
http://www.jazillian.com/how.html а все остальное оборачиваем JNI и вперед! |
| Автор: Амортизатор 4.6.2006, 12:21 |
| Beard, ну прям так просто. Обернув JNI, ты получишь платформенно-зависимый код, а это нельзя считать полноценной конвертацией. На мой взгляд, полноценная конвертация - это замена платформенно-зависимых вызовов на обращения к библиотеке Java. А этот процесс невозможно автоматизировать. |
| Автор: Tirael 4.6.2006, 12:29 |
| Beard, как я понимаю конвертнуть можно только совсем простые выражения. Но вот множественное наледование, перегрузка операторов как-то плохо поддаются переводу. |
| Автор: Beard 4.6.2006, 14:15 | ||||
Вспомним, что некоторые библиотечные классы (точнее, их методы) как раз и реализованы через JNI - просто иначе никак! И кросс-платформенное приложение, которое взаимодействует, например, с ком-портом, мы никак не напишем на Java (хотя можно сделать по аналогии с этими библиотечными классами - для каждой ОС - библиотеку + JNI - и сказать, что оно кроссплатформенно, хотя и не pure-java).
Замечательно поддаются конвертации - написать конвертор из С++ в Java (не считая библиотек - про некоторые библиотечные функции и их представление после конвертации написано в статье по ссылке, что я дал) не так уж сложно самому - нудно и долго, конечно, но вполне реализуемо... Это не голосовное утверждение - почти все мои курсовики и дипломная + несколько проектов связатны с конвертацией из одного языка в другой (или расширенного языка в таргет)... Тем более что в джава можно реализовать псевдо-множественное наследование классов через интерфейсы - по свойствам оно ничем не будет отличаться от множественного наследования классов в С++. И вообще - такой предмет как "Теория языков и трансляций" ничего не говорит!? - не знаю, во всех ли тех. вузах он входит в программу.. |
| Автор: Beard 4.6.2006, 14:33 |
| Да - по поводу перегрузки операторов - этот механизм фактически является одним из видов перегрузки функций, а здесь уж никакой сложности нет... |
| Автор: Анор 5.6.2006, 14:41 |
Beard - спасибо, полез искать |
| Автор: Амортизатор 5.6.2006, 18:27 | ||
В том то и дело, что БИБЛИОТЕЧНЫЕ классы - т е те, что входят в состав JRE! То бишь собственно бинарники программы не будут отличаться в общем случае в зависимости от платформы, они будут одинаково обращаться к библиотеке ( javax.comm в случае ком порта), а то, что дальше - это уже дело JRE и для каждой платформы у нее своя реализация. А если речь идет о конвертации C++-программы в Java, то JNI идет в коде программы, т е теряется независмость от платформы. Смысл то такой конвертации, если она все равно сможет исполняться только на той оси, под которой работает программа на С++? |
| Автор: Амортизатор 5.6.2006, 21:23 |
| Естественно, в тех случаях, когда что-то невозможно сделать стандартными библиотеками Java и приходится прибегать к явному JNI, тогда при конвертации ничего не теряется. Однако ничего и не приобретается. Опять таки, есть ли смысл в подобной конвертации? Только если реализовать, как ты говоришь, для каждой оси свою либу. |
| Автор: Beard 5.6.2006, 21:37 | ||
| to Amortisator: Мы, наверное, о разных вещах говорим... Есть задача из области реинжиниринга - сорцы программы C++ -> сорцы Java. Если наши сорцы на С++ на выходят за рамки Standart C++ (т.е. не используют сторонних библиотек), то проблем никаких (может я и вру, но ничего в стандарте C++, что нельзя реализовать (найти аналог) на Java, нет! - если не прав, ткните). Если же мы пользуем такие библиотеки, то у нас не получится pure-Java приложение (и я с этим не спорю)... Тем более, если у нас, например, все жестко завязано на пользовательский интерфейс (придется буквально все ручками переписывать).. Но мы хотим заставить (программа - минимум) сконвертированное в Java приложение работать под исходную платформу (где и C++) - используя JNI мы этого добиваемся (причем практически автоматом). Кросплатформенность в смысле платформы (простите за тавтологию, да и за возможные опечатки - алкоголь из крови еще не вышел) Java естественно теряется... Если этого кода (завязанного на JNI) немного (да если и много, то уж чего делать - босс сказал..), то мы также ручками доводим его до кросплатформенного (если есть возможность) решения - реинжиниринг произведен, все довольны. Добавлено @ 21:41
Да, я про это и говорил. А приобрестись может то, что мы доведем этот код ручками до кроссплатформенного Добавлено @ 21:46 Вобщем, если главная цель - логика приложения (тем более при конвертации могут "отсекаться" даже паттерны проектирования) - мы много приобретаем для дальнейшего развития нашего проекта на новой платформе |
| Автор: Void 5.6.2006, 23:03 | ||||
JNI упоминался как средство реализации функциональности сторонных библиотек. Если оставаться в рамках стандартной библиотеки C++ то да, почти для всего найдутся аналоги в JRE. У меня есть кое-какой опыт создания трансляторов между ЯВУ. И навскидку при преобразовании C++ -> Java я вижу основную проблему: Указатели. В общем случае адресную арифметику перенести на Java нельзя. Можно только распознать некоторые типичные случаи применения адресной арифметики и эмулировать ее с помощью массивов, спец. классов и т.д. В общем случае придется либо прибегать к помощи JNI, либо поднимать лапки. Думаю, не ошибусь, если скажу, что для такого транслятора «специальные случаи» и применение эвристик будут постоянной практикой. Если, например, при реализации Java -> C++ основную сложность составила бы реализация рантайма (GC, портирование библиотек), а сам транслятор был бы сравнительно простым, то тут возникает масса проблем именно при преобразовании исходного кода. Все остальное вроде решаемо. Множественное наследование эмулируется интерфейсами и дублированием кода. Шаблоны — тоже дублирование кода и, возможно, дженерики.
Наименьшая из проблем. Каждый блок в try..finally и вызывать деструкторы в finally. И, наконец, не забываем про исключительную сложность самого парсера C++. Хотя конечно можно подцепить GCC-XML, OpenC++ или купить у EDG исходники фронтэнда Проблема в том, что практическая польза от такого транслятора не оправдывает трудности реализации из-за огранчиений на библиотеки. Единственно, диплом может хороший получится или даже диссер. |
| Автор: sergejzr 5.6.2006, 23:30 |
| Не усложняйте задачу В большинстве стучаев конвертер нужен для перегона алгоритмов из одного языка в другой. Иногда проектов. Для этих задач конверторы и существуют. Конечно они являются ничем другим, как инструментом - помощником. какую часть всегда придётся править ручками, но рутину они перенимают. |
| Автор: Амортизатор 5.6.2006, 23:36 | ||
А я имел ввиду как раз не средства самого языка (С++), а проблемы на уровне API платформы. Однако, если говорить о языковых различиях, то и здесь, как указал Void, проблем не оберешься. По сути, надо готовиться к тому, что после конвертации среднестатической программы с С++ на Java, получится абсолютно нечитаемый и плохо поддерживаемый код. Как, например, такое: операции над указателем на указатель - придется в самом деле заводить ссылку объект, содержащий массив ссылок на другие объекты или просто на массив (проще, но будут имхо минусы), и далее детерминировать операции над указателем на указатель индексацией по массиву. Тут как минимум служба сопровождения может устроить забастовку |
| Автор: Beard 5.6.2006, 23:36 | ||||||
А на reflection вообще б загнулись
Либо пользовать Java-ские "дырки", типа sun.misc.Unsafe, что не есть хорошо - не поспоришь...
Эээ, а в чем его сложность? Есть специфицированная грамматика и куча тулзов, которая запросто построит парсер по этой грамматике. Или я не так понял? |
| Автор: Void 5.6.2006, 23:37 | ||||||||||
Ну если рассматривать подмножество языка без классов, шаблонов и т.д, чаще всего используемое при реализации алгоритмов, а использование STL транслировать ad-hoc, то еще как-то подъемно. Для конвертации пары функций можно и написать… Правда, для пары функций может оказаться достаточно copy&paste, find&replace
Имхо, для данного случая — нереально. Добавлено @ 23:42
Я ни разу не спец в Java, так что если там есть unsafe, тем лучше
Нет, ну почему… Раз мы можем навязать в своем коде single-root иерархию, проблем особых не будет.
Грамматика C++ не является контекстно свободной, не укладывается ни в LL(k), ни в LALR(1), которые могут разбирать большинство генераторов парсеров. Поддается GLR, но все равно лучше взять готовое решение, например на базе того же GCC. Существуют десятки компиляторов C++ и приличные в плане корректной поддержки всех конструкций можно перечислить на пальцах одной руки — это ли не свидетельство сложности задачи? |
| Автор: sergejzr 5.6.2006, 23:47 | ||
а что у нас за случай? Автор вроде словом не обронился .Я в своё время как раз использовал конвертер для проекта из С++ в Java. C одной стороны find/replace конечно тоже поможет, но с другой там много чего ещё. |
| Автор: Void 5.6.2006, 23:51 | ||||
Эта… ссылку в студию! На конвертер
Вот именно. Как он вопрос с библиотеками-то разруливает? |
| Автор: sergejzr 5.6.2006, 23:54 | ||
Никак. Он не для того предназначен, чтобы программу из языка в язык переводить, а для того, чтобы помочь перевести (об этом я собственно в первом посте и писал). Ссылку не дам, проект 5 лет назад был. Добавлено @ 00:01 PPS: Насчёт библиотек: Он просто вызовы функций пишет и всё. естесственно их не имплементирует |
| Автор: Beard 6.6.2006, 00:26 | ||||||
Не совсем понял - можно поподробней?
http://www.nobugs.org/developer/parsingcpp/, но тем не менее это возможно, и есть готовые решения (Зуев, например, написал приложение к русскому Ахо, Ульман, Сети, где описывается грамматика С++ для YACC/bison, правда с кой-какими допущениями )
Это почему "абсолютно нечитаемый" (если опустить указатели на указатели на..., и то, мне помнится, что-то неплохое придумали по этому поводу - не про читаемость, а про возможность реализовать трансляцию на Java - попытаюсь найти и кинуть ссылку)? Как я сказал, даже распространенные шаблоны (~GoF) "отсекаются"! |
| Автор: Void 6.6.2006, 16:30 | ||||
В сгененрированном по Java C++ коде все классы будут унаследованы от одного, скажем, JObject. Ничто нам не мешает сделать ряд виртуальных методов для рефлексии и саморегистрацию всех методов и членов в каждом классе. Многие C++ библиотеки таким образом обеспечивают свой собственный RTTI.
Угу, видел я эту грамматику. Вопрос в том, с какими именно допущениями Разработчики GCC, начиная с версии 3.4, отказались от использования Bison и переключились на собственный вручную написанный рекурсивно-нисходящий парсер. Не от хорошей жизни, наверное, учитывая огромную инерцию такого большого проекта, и сколько на него завязано кода.Есть еще http://www.cs.berkeley.edu/~smcpeak/elkhound/ — генератор GLR-парсеров. С его помощью написан парсер C++ Elsa. |