Причины для инструментов рефакторинга для C/С++ настолько ограничены

Ответ 1

Рассмотрим только один базовый рефакторинг: Переименовать функцию

Реализация выглядит очень просто. Найдите все ссылки и замените используемый идентификатор.

С виртуальными функциями он немного усложняется. Теперь необходимо найти базовую декларацию (и реализацию, если не абстрактную), а ссылки могут быть для любой производной реализации в иерархии классов. Гораздо сложнее, но все же возможно, потому что группа функций, которые нужно переименовать, четко определена.

Это сложность, применимая к таким языкам, как С# и Java. Теперь идет кикер: шаблоны С++ утка напечатана. Набор реализаций в иерархии классов уже не является корректным, поскольку он может включать любую функцию с тем же именем и, возможно, совместимыми параметрами. Вы помнили о поиске Koenig, верно?

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

Итак, оставьте свой список претензий/желаний:

• "облегчить скучный синтаксис". Это просто троллинг и ничего не значит в каком-либо техническом смысле. Если инструмент не вводит и не выводит синтаксис С++, это не инструмент рефакторинга С++.
• "С++ развивается". Это означает, что такой инструмент необходимо будет поддерживать на значительных затратах, чтобы идти в ногу со временем. Это также означает, что хорошо сохранившийся инструмент легко украл бы долю рынка от старых стабильных инструментов. И это означает, что любой инструмент нуждается в тонне пользовательской конфигурации - вы не хотите генерировать С++ 0x-isms на кодовой базе С++ 03 в конце концов - так что пользователям придется использовать этот инструмент очень много, чтобы отмените время, потраченное на настройку.
• "Каждая ошибка - это выживание"? Не уверен, что означает это грамматически бессмысленное утверждение, но, возможно, это означает, что допустимость толерантности к нулю? Но это лучше всего достигается путем поддержания стабильности (антитеза автоматизированного рефакторинга, затрагивающего несколько файлов), прочной архитектуры и документации (которую инструмент рефакторинга не будет автоматически обновлять, или вы тоже этого хотите?), Массивные тестовые пакеты и статический анализ, Фактически, рефакторинг делает массивные комплекты тестов еще более важными, если это возможно, для проверки того, что инструмент ничего не сломал. Обратите внимание, что автоматизированный статический анализ сталкивается с некоторыми из тех же проблем, что и рефакторинг, но поскольку он не изменяет код, который он может и работает, и работает на пост-препроцессорном коде и/или компиляторе AST.
• "уменьшить время компиляции"? Это неподдерживаемое требование, требующее серьезных доказательств или, по крайней мере, обоснованных аргументов. Ожидаете ли вы, что инструмент рефакторинга вводит pimpl для компиляции firewalling? Ни один из рефакторингов С# и Java не уменьшит время компиляции С++.
• "возможно" Нет, на самом деле кажется, что это не так. Если вы или я не можем создать один базовый рефакторинг, например, функцию Rename, разумно, неважно, правильно ли это реализовано, как можно реализовать десятки из них? Если это возможно, это также чрезвычайно дорого, что приводит к:
• "это чрезвычайно выгодно". Рентабельность требует не только большой базы пользователей, которые готовы платить за продукт, но и то, что потенциальные валовые продажи превышают затраты. Я утверждаю, что вы серьезно недооценили затраты, поэтому пока вы не представите какие-либо реальные исследования по расходам и рынкам, я также назову это одним желаемым замыслом.
• "его не существует". Поразмыслив, чтобы объяснить, почему такой инструмент не может существовать, я сейчас скажу вам, что он уже делает это? Ага. По крайней мере, поскольку рефакторинг делает конечный код лучше, делая такие вещи, как подъем общих подвыражений внешних циклов, разворачивание циклов, обмен порядком итерации, встраивание, оптимизация кеширования, векторизация, они уже предоставляются путем оптимизации компиляторов, области, в которой С++ ведет оба С# и Java с широким диапазоном. С++ просто не требует много настроек на уровне исходного кода, необходимых для С# и Java, чтобы получить хороший конечный продукт. Это только манипуляция исходным кодом, чтобы сделать его более доступным для людей, который остается, и существующие инструменты выполняют адекватное, если не исключение работу этого.

Ответ 2

Эта ссылка рассказывает о некоторых деталях и сложности.

Ответ 3

Причина в том, что С++ не обрабатывается большинством обычных методов синтаксического анализа (LALR, LL и т.д.) и на самом деле требует некоторого довольно тяжелого подъема для правильного анализа. Некоторые инструменты, такие как clang и gcc-xml, позволяют другим инструментам обрабатывать С++ без реализации собственных С++-парсеров, хотя оба они довольно новы, и все еще сложно обрабатывать С++ даже с помощью этих инструментов синтаксического анализа. Я думаю, что индустрия в конечном итоге увидит все связанные с Java плюсы, перенесенные/адаптированные к С++... вопрос в том, когда.

Ответ 4

Проблема в том, что С++ трудно разобрать (его грамматика не является контекстной) и трудно понять, не компилируя исходный код. Инструменты Java могут работать, потому что язык намного проще, как грамматика, так и семантика.