Здравствуйте, Константин, Вы писали:

К>В Visual Assist есть переименование. Полезная вещь, и работает неплохо.

Visual Assist — кривая поделка, там даже overload resolution не могут осилить уже сколько лет. О каком корректном переименовании может вообще идти речь?

Здравствуйте, enji, Вы писали:

E>Здравствуйте, vsb, Вы писали:

E>Это крайний случай, на самом то деле, такого кода обычно немного. А большая част кода — вполне себе классическая. В том же cdt для эклипса переименование есть, работает более-менее нормально.

При инстанцировании шаблонов (самый что ни на есть классический код) образуются связи между разными сущностями. Не зря же собирались вводить концепты, которые более явно эти связи будут образовывать. И сейчас, насколько я знаю, ни одна плюсовая IDE не умеет корректно переименовывать код с шаблонами. Тот же Eclipse CDT косячит только так...

Здравствуйте, kamre, Вы писали:

K>Visual Assist — кривая поделка

Не нравится — не ешь

Здравствуйте, kamre, Вы писали:

K>Был корректный компилирующийся код с шаблонами и макросами. После переименования в IDE получается не компилируемый код или не сохраняется семантика кода. Ни одна IDE для плюсов сейчас не справляется даже с rename.

Да ладно рассказывать. Netbeans (и он кстати ещё и бесплатный и кроссплатформенный) нормально парсит любой код с макросами и шаблонами (включая самые дикие из boost). Надо только правильно подключать все библиотеки (пути их указать) в анализаторе кода. И рефакторинг там тоже полноценно работает.

Здравствуйте, kamre, Вы писали:

K>При инстанцировании шаблонов (самый что ни на есть классический код) образуются связи между разными сущностями. Не зря же собирались вводить концепты, которые более явно эти связи будут образовывать. И сейчас, насколько я знаю, ни одна плюсовая IDE не умеет корректно переименовывать код с шаблонами. Тот же Eclipse CDT косячит только так...

Классический шаблон — что-то вроде std::vector. Если для него поменять push_back на pushBack — все сработает относительно нормально. За исключением случаев вроде

template<class C> void f(C& c, int i) { c.push_back(i); }

которые понятно только руками лечатся. Однако это не инстанцирование шаблона, а его определение и реализация. У меня обычно реализаций шаблонов немного, основной код шаблоны только использует, и сильно похож на какую-нить Яву. Для него переименование обычно работает, и даже виртуальные методы обычно нормально обрабатываются.

А макросы и шаблоны — да, руками, увы.

Здравствуйте, alex_public, Вы писали:

_>Да ладно рассказывать. Netbeans (и он кстати ещё и бесплатный и кроссплатформенный) нормально парсит любой код с макросами и шаблонами (включая самые дикие из boost). Надо только правильно подключать все библиотеки (пути их указать) в анализаторе кода. И рефакторинг там тоже полноценно работает.

Гм, пару лет назад смотрел — чет по сравнению с эклипсом у его парсера проблем было больше. Надо еще глянуть, может что-то улучшилось...

Здравствуйте, alex_public, Вы писали:

_>Да ладно рассказывать. Netbeans (и он кстати ещё и бесплатный и кроссплатформенный) нормально парсит любой код с макросами и шаблонами (включая самые дикие из boost). Надо только правильно подключать все библиотеки (пути их указать) в анализаторе кода. И рефакторинг там тоже полноценно работает.

Да ладно уж заливать, никак там рефакторинг с шаблонами и макросами не работает:

Здравствуйте, enji, Вы писали:

E>За исключением случаев вроде
E>

E>template<class C> void f(C& c, int i) { c.push_back(i); }
E>

E>которые понятно только руками лечатся. ... А макросы и шаблоны — да, руками, увы.

При инстанцировании шаблона функции "f" образуется связь между push_back в определении шаблона и функцией push_back конкретного класса "C". При переименованиях это должно учитываться, иначе код сломается и перестанет компилироваться. Вроде же очевидно все, а ни одна IDE вообще этого не проверяет.

Точно также и с макросами:

struct node {
    void* data;
    node* next;
};

struct list { node* head; }; // rename "head"

struct queue { node *head, *tail; };

#define init(l) l.head = 0;

int main() {
    list l;
    queue q;
    init(l);
    init(q);
}

Здравствуйте, kamre, Вы писали:

K>При инстанцировании шаблона функции "f" образуется связь между push_back в определении шаблона и функцией push_back конкретного класса "C". При переименованиях это должно учитываться, иначе код сломается и перестанет компилироваться. Вроде же очевидно все, а ни одна IDE вообще этого не проверяет.

А есть ещё второй конкретный класс "C", который тоже используется с "f". Вот только он ещё используется с std::back_inserter и переименовывать его push_back нельзя.
Да, и конечно же функция "f" ещё используется в другом проекте, код которого IDE не видит.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>А есть ещё второй конкретный класс "C", который тоже используется с "f". Вот только он ещё используется с std::back_inserter и переименовывать его push_back нельзя.

Вот именно, а IDE делают что попало и не отслеживают все нюансы использования символа при его переименовании. Нельзя полагаться на такой "рефакторинг"...

EP>Да, и конечно же функция "f" ещё используется в другом проекте, код которого IDE не видит.

Ну это уже вряд ли претензия к IDE, скорее к тому кто сконфигурировал workspace/solution, когда в него не все нужные для рефакторинга проекты входят.

Здравствуйте, enji, Вы писали:

E>Гм, пару лет назад смотрел — чет по сравнению с эклипсом у его парсера проблем было больше. Надо еще глянуть, может что-то улучшилось...

Netbeans как раз парсит библиотеки, которые Eclipse не осилил у меня. Например помнится Эклипс не смог распознать инклуд файла с путём генерируемым макросами. Но это именно в смысле разбора. А кроме этого у них ещё и принципиально разные подходы по архитектуре парсеров. Эклипсовский создаёт кэш анализа (включая все библиотеки) в папке workspace'a. Это мне не совсем нравится по ряду причин. Netbeans анализирует данные каждый раз и держит всё в памяти. Так что долго стартует и много оперативки отжирает. Но зато шустро работает (хотя и медленнее чем Visual Assist) и не замусоривает проект. У Visual Assist'а наверное одна из самых эффективных архитектур — хранит анализ библиотек на диске у себя (а не в проекте) и при этом быстрее всех. Но к сожалению он как раз меньше всех умеет понимать (возможно поэтому и шустрый такой)...

P.S. Данные про Эклипс и VA где-то 1,5 летней давности — с тех пор я их окончательно перестал открывать. )))

Здравствуйте, kamre, Вы писали:

K>Да ладно уж заливать, никак там рефакторинг с шаблонами и макросами не работает:

А никто и не говорил про подобное. Фраза про шаблоны и макросы была отдельно (т.к. для C++ актуальна проблема что бы парсер вообще разобрал код, ещё без всякого рефакторинга — мало какие это могут), а про рефакторинг отдельно. Обычный рефакторинг (в стиле Java, без шаблонных хитростей) вполне работает. Ну а такой что бы учитывал при переименование потенциальную возможность подстановки шаблонов... Я даже не уверен что это вообще возможно сделать.

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

Здравствуйте, alex_public, Вы писали:

>Здравствуйте, kamre, Вы писали:

K>>Да ладно уж заливать, никак там рефакторинг с шаблонами и макросами не работает:

>А никто и не говорил про подобное.

Как это не говорил: "И рефакторинг там тоже полноценно работает."? Какая же это полноценная работа, если "в стиле Java", без учета кучи вещей специфических для C++?

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

Дак нет для C++ IDE с полноценным рефакторингом, который учитывает все аспекты C++. Выбирать просто не приходится по этому критерию. Так что можно попытаться сравнить их по "умной навигации по коду и правильному автодополнению".

Берем первый попавшийся пример из boost. И смотрим как NetBeans на нем работает:

Автодополнение не нашло функцию insert, хотя она явно имеется у ns, точно также не работает навигация для insert (пишет Can't open element "insert").

Попробуем еще с итератором:

Тоже фейл, и навигация для name срабатывает куда-то в левое место, а совсем не к функции name_record::name.

Так что похоже, что утверждение "нормально парсит любой код с макросами и шаблонами (включая самые дикие из boost)" — голословное, далеко не все из boost умеет парсить NetBeans.

Здравствуйте, kamre, Вы писали:

EP>>А есть ещё второй конкретный класс "C", который тоже используется с "f". Вот только он ещё используется с std::back_inserter и переименовывать его push_back нельзя.
K>Вот именно, а IDE делают что попало и не отслеживают все нюансы использования символа при его переименовании. Нельзя полагаться на такой "рефакторинг"...

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

EP>>Да, и конечно же функция "f" ещё используется в другом проекте, код которого IDE не видит.
K>Ну это уже вряд ли претензия к IDE, скорее к тому кто сконфигурировал workspace/solution, когда в него не все нужные для рефакторинга проекты входят.

Почему же проблемы с конфигурацией? Просто проект внешний, кода нет. Точно также как твой проект является внешним для STL.
Это же изменение интерфейса, которое усугублено тем, что в общем случае он определён реализацией, причем на нескольких уровнях.

Здравствуйте, kamre, Вы писали:

K>Как это не говорил: "И рефакторинг там тоже полноценно работает."? Какая же это полноценная работа, если "в стиле Java", без учета кучи вещей специфических для C++?

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

K>Автодополнение не нашло функцию insert, хотя она явно имеется у ns, точно также не работает навигация для insert (пишет Can't open element "insert").

Хы, кстати, я глянул в описание класса и тоже с ходу не нашёл insert — оно там из хитрого mixin'а берётся. Видимо такое ему всё же не по зубам. )))

K>Так что похоже, что утверждение "нормально парсит любой код с макросами и шаблонами (включая самые дикие из boost)" — голословное, далеко не все из boost умеет парсить NetBeans.

Ну я естественно не все библиотеки из Буста тестировал. ))) И в любом случае суммарно Netbeans осиливает больше библиотек из моего набора чем Eclipse и Visual Assist.

Здравствуйте, Cirrus, Вы писали:

C>Подробности: http://habrahabr.ru/company/JetBrains/blog/184830/

Ненужно!

Есть Visual Assist X, который прекрасно справляется со своей задачей.

Здравствуйте, alex_public, Вы писали:

K>>Так что похоже, что утверждение "нормально парсит любой код с макросами и шаблонами (включая самые дикие из boost)" — голословное, далеко не все из boost умеет парсить NetBeans.

_>Ну я естественно не все библиотеки из Буста тестировал. ))) И в любом случае суммарно Netbeans осиливает больше библиотек из моего набора чем Eclipse и Visual Assist.

А можешь дать списочек бустовских либ, которые ты используешь и которые нормально парсит нетбинс? Хочется сравнить с эклипсом, а ставить и разбираться в его настройках неохота.

Здравствуйте, Sni4ok, Вы писали:

S>конечно, нужно анальное рабство от апла, майкрософта и других проприетарных производителей.

Настоящие программисты пишут с помощью бабочек (добываемых от настоящих принцесс).
В емаксе даже команда соответствующая есть — старая добрая C-x M-c M-butterfly.

Здравствуйте, noone, Вы писали:

N>http://ic.pics.livejournal.com/gorart/13343372/560135/original.jpg

Внезапен сыч, но истина дороже...
вика / Туберкулиновая проба # Мифы

F>Ненужно!
F>Есть Visual Assist X, который прекрасно справляется со своей задачей.

Ты знаешь, я тоже так подумал. Т.к. с ReSharper не знаком вообще.
После просмотра видео в статье мнение немного изменилось. Там есть вещи которые ассистант делать не умеет.
Например, раскрытие макросов.
Но тут может возникнуть другой интересный момент.
В WholeTomato тоже посмотрят это видео и решат что то допилить к Visual Assist-анту.

Другое приимущество ИМХО это в обещанной кроссплатформенной среде разработки с такими возможностями.