[Шаманъ 0]

Я задумался.

Убрал из VS 2015 community все преинсталлированные тулсы и подключение к аккаунту, и получил запуск 5 сек с пустым воркспейсом.

А когда снес VisualGDB то получил 1 сек!

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

 

С пустым воркспейсом стартует мгновенно.

[AlexandrY 3]

Попробовал reshaper - не понравился сразу ибо медленнее асиста. Дальше разбираться с плюшками не стал - на такой скорости нет смысла

 

Покопался сутки в этой теме.

Все оказалось не так радужно как показалось.

 

Концептуальная проблема VS и его плагинов в том что они не заточены строго под embedded и не предполагают что VS будет использоваться просто как редактор.

Отсюда их требовательность к полноте набора символов, структуре дерева проекта, настройкам отладки.

 

Если взять обычный мой проект с RTOS на C-и, там около 2-х тысяч файлов, то:

 

Стандартный парсер VS путается в именах. Рефакторинг его работает с ошибками на C текстах.

 

Resharper да, отстой. Медленнее ассистента, заточен именно под C++ , а не C. Также путается в именах. Управление неудобное. Кроме того блокирует некоторые тулбоксы VS насчет навигации и рефакторинга.

 

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

Пользу от ViasualGDB увидел только в том что он построил автоматом структуру проекта повторяющую структуру директорий и автоматом нашел все директории с инклудами и объявил их парсеру.

Почему-то в VS большая проблема это сделать нативно. Народ извращается как может. Но нормального универасального синхронизируемого решения я не нашел.

Пытался в ViasualGDB два раза создать проект мигания светодиодом по предлагаемой ими схеме. Оба раза он сгенерил проект вызывающий ошибку линкера.

Но скорость компиляции там уже достаточно показательная. В несколько раз медленнее обычной IDE.

 

Visual Assist использует нативный парсер VS поэтому его рефакторинг также может попортить исходники.

 

И всех их тупо вводят в ступор ассемблер и интринсики IARа.

 

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

Slick не требует строгости в определении символов, спокойно работает с неопределённостями имён и никогда не делал мне ошибок в рефакторинге.

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

И не лезет со своей отладкой и билдингом.

 

Короче VS я очередной раз отложил в сторону, явно еще не его время для embedded.