Инструментарий для переписывания кода с C++ на C

Emacs, C-x 3

переписать объектно-ориентированный код или автогенерируемый на темплейтах в процедурный - весьма нетривиальная задача. если оно работает, не проще просто линковать новый код к уже работающему? C и C++ прекрасно между собой линкуются, по крайней мере из С++ в С точно

Если коротко, то код на C++ не соответствует требованиям ТЗ на целевую платформу. Просто он писался совсем без учета реальной жизни и дохлых железок. Тулчейн под железо немного кривой, да и не может оно позволить себе гонять толстый рантайм, так что переписывать все равно надо, а если переписывать, так проще на C, потому как проще оно там в инфраструктуру ляжет.

Ну и для меня проще, чтобы это было C, так как это мне поддерживать потом.

нужно мне оторвать здоровый (клиентский) кусок этой софтины, переписать на C, дабы оно запускалось в более дружественной к embedded среде.

Интересно, что это за embedded среда, в которой запускается большой клиентский кусок, но в которой нет компилятора Си++.

Тупое переписывание не даст никакого выигрыша в скорости / потреблении ресурсов.

Надо узнать узкие места у этого кода, внимательно все изучить.

После этого, продумав архитектуру, можно начинать _писать_ код на другом языке.

Этот кусок надобно сделать маленьким, отучить выжирать память, сделать полный контроль за аллоцированием памяти, обстрипать структуры данных, etc. Относительно большого проекта, клиент - мелкая фиговина, но она уже слишком жирная для железки, избыточна, и написана вообще без мыслей об экономии ресурсов и производительности, а чтобы потешить ЧСВ прикольными абстракциями, шаблонами и прочим подобным. ООП на C вполне можно делать, примеров и работ на тему завались. И делать таки придется - просто ищу путь наименьшей крови.

Именно это я и хочу сделать - поэтому ищу инструментарий.

компилятор C++ есть, нет рантайма, точнее, его нельзя использовать.

(пожимая плечами) Если ты решил писать заново, пиши. Инструменты для этого обычные - редактор, компилятор, отладчик.

поэтому ищу инструментарий.

Хороший редактор, отладчик и профилировщик.

Не, нужно сделать workalike-софтину без недостатков оригинала, соответственно нужно изучить работу первой, то есть создать документацию по коду, то есть извлечь максимум информации из оригинала, вот это наверное самая сложная задача, и хотелось бы найти инструментарий для этого. По крайней мере способ идентификации мертвого кода, разбор с учетом шаблонов, деревья вызовов, переменные, инициализаторы, и прочее C++-ное, в чем я себя уверенно не чувствую, а делать надо.

разбор с учетом шаблонов, деревья вызовов, переменные, инициализаторы, и прочее C++-ное

Это и есть «хороший редактор». Начни с Eclipse CDT.

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

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

В идеале, конечно, можете попробовать написать какой-нибудь «интеллектуальный» транслятор, но оно того не стоит :)

Если читабельность не важна, попробуйте найти компилятор из C++ в C типа Cfront.

Хардкорный вариант — специализировать специализатор под интерпретатор C++, написанный на C.

Руками придется. По кусочкам переписывать.

Читаемость кода очень важна. Cfront смотрел - оно полезно, но местами совсем шлак получается...

Почему С++ не соответствует ТЗ? С++ так же быстр, местами даже быстрее(за счет шаблончиков и встраивания).

Кроме исключений. А тут тулзы не помогут - придется ручками.

В общем, нужно просто навести порядок в С++ коде. На С переписывать смысла нет.

есть такая софтинка Source Navigator (http://developer.berlios.de/projects/sourcenav) очень помогала разбираться в больших чужих проектах. Как редактор - мягко говоря так себе, зато в плане именно навигации равных нет.

TDD

Не парься, просто скомпилируй с llvm C backend. Получится не очень читабельный, но вполне стандартный код на Си.

Про рантайм лошара не услышал? И почему плюсисты все такие тупые?!?

И в чем заключается кривость тулчейна? Что за железка?

Закрытый китайский ASIC «для модемов» с ARM7TDMI на борту. Имеет закрытые либы, без которых девайс не поднять. В качестве тулчейна - gcc. Мистически рантайм дохнет при вызове конструкторов/деструкторов/инициализаторов, причем не всегда и не везде, но в любом сколько-нибудь осмысленном приложении, но не в синтетических тестах. Разбираться долго. От версии gcc не зависит. Чинить некому, и незачем, потому как старье и legacy, и вообще эта работа по суппорту, и фича эта должна была быть сделана пять лет назад. Вообще, там все так хрупко и волшебно, что трогать тулчейн уже совсем не хочется - хватило 6-месячного перехода на gcc-4.5.

Да, если в коде нет ни одного MySuperClass t; и подобного, то есть неявного вызова статических конструкторов, то проблема проявляется редко, мифическим образом v = new MySuoperClass(20); иногда помирает, иногда нет. Но код конструктора при умирании даже не начитает выполняться. Эксепшны тоже не работают. Буст не работает, короче, в морг.

Что именно вам мешает? Обычные плюсовые классы? Не смешите - табличка с указателями на функцию.

А для остального -fno-rtti -fno-exceptions и никакого «рантайма».

Исключения для таких систем отключают, RTTI тоже (см. выше).

new/delete чаще всего переопределяются глобально.

Да, в таких условиях о boost лучше забыть - максимум что-то можно выдрать руками и подредактировать(заменить исключения и т.п.). Даже stl лучше убрать, максимум - заточить под себя какой-нибудь stlport.

Но даже в таком урезанном виде С++ приятнее голого С. Шаблоны, классы(с «дешевыми» вызовами виртуальных функций) и пр. реально упрощают создание и сопровождение софта.

Ну, я писал выше, одна из проблем - статические конструкторы, которые не работают. Что там еще не заработает - хз, я не знаю, что будет проще - переписать на такой урезанный C++ (который я в общем знаю плохо) или на C.

Можно написать прослойку между плюсами и сями. У меня так камера работает: библиотечка на плюсах, а сама утилитка на сях.

Я не знаю, что вы имеете в виду под статическими конструкторами(они есть, например, в D, но в С++ их нет), но конструкторы в С++ - это просто функция инициализации, которая отвечает за то, чтобы из сырой памяти сделать объект. Никакой магии и накладных расходов. Даже выделением памяти конструкторы не занимаются. Так что если ошибка и есть, то она в коде конструктора, а не в языке/его реализации.

Урезанный С++ в данном случае лучше тем, что у Вас будет меньше работы по переносу. Но для этого Вам нужно знать С++. Впрочем, его Вам в любом случае нужно знать...

Я подозреваю, что проблема там в китайском закрытом newlib, а не в libstdc++, но конструкции вида SomeClass t; валят софтину напрочь, при этом конструктор класса не вызывается.

Ну это надо, чтобы плюсы работали адекватно.

И код-то тогда все равно переписывать. Ну, тупые плюсисты все, тупые!

Не переписывать, а править. Причем если код написан нормально, то править немного. А вот переписывание на С обойдеться большим геморром.