Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?
Есть какие-то принципиальные трудности с определением изменений везде, кроме определённых блоков текста?
Если изменилась метаинформация — то пересобирать,но вот если в комменте поменялась точка на три точки где-нибудь в одном из основных хедеров(рассмотрим случай с С++) — это вызывает пересборку всего проекта (я конечно упускаю некоторые моменты,позволяющие уменьшить влияние отдельного файла,но не в этом суть).Почему?
— Настолько сложно?
— Никому не нужно?
— Просто лень?(напоминает ситуацию с дебаггером С++ в MSVS, когда он не может дебажить после 65535 строчки).

Спасибо за ответы

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

B>Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?

IDE тут совершенно не при чём, сборкой проекта занимается система инкрементальной сборки (GNU make, Maven, CMake, NAnt, тысячи их). Например, Студия использует MsBuild для большинства проектов и VcBuild для C++-проектов.

B>Есть какие-то принципиальные трудности с определением изменений везде, кроме определённых блоков текста?

Сравнение timestamp'ов для определения устаревания работает в самом общем случае, в то время как анализ комментариев должен быть реализован для каждого языка в отдельности.

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

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

B>Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?
Разработчики IDE тут не задействованны.

B>Есть какие-то принципиальные трудности с определением изменений везде, кроме определённых блоков текста?
B>Если изменилась метаинформация — то пересобирать,но вот если в комменте поменялась точка на три точки где-нибудь в одном из основных хедеров(рассмотрим случай с С++) — это вызывает пересборку всего проекта (я конечно упускаю некоторые моменты,позволяющие уменьшить влияние отдельного файла,но не в этом суть).Почему?

Метаинформация здесь — дата модификации файла. Она изменилась, а это соответственно вызывает пересборку всех зависимых частей.

B>- Настолько сложно?
Нужно хранить коментарии там где они совершенно лишние, + как-то согласовывать с тем фактом, что комментарии 'удаляются' на более ранних стадиях компиляции, + как-то детектировать изменения.

B>- Никому не нужно?
Мне — не нужно.

B>- Просто лень?
Приоритет у такой фичи чрезвычайно низкий по сравнению с остальными.

С комментариями не всегда очевидно, пример:

#define trick /##*

int main(){
    char *h="Hello", *w="";
    trick;        
    w = "world"; 
    /*print message*/
    printf("%s %s!",h,w);
    /*return*/
    return 0;
}

Если удалить комментарий «/*print message*/», то перестанет печататся текст.

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

P>С комментариями не всегда очевидно, пример:

P>

#define trick /##*

P>int main(){
P>    char *h="Hello", *w="";
P>    trick;        
P>    w = "world"; 
P>    /*print message*/
P>    printf("%s %s!",h,w);
P>    /*return*/
P>    return 0;
P>}

P>Если удалить комментарий «/*print message*/», то перестанет печататся текст.

Никто не говорит удалять комментарии...
Что мешает делать не сравнивать даты модификации,а сравнивать структуры распарсеного файла(комментарии ведь не несут никакой информации ,используемой компилятором)?

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

B>Что мешает делать не сравнивать даты модификации,а сравнивать структуры распарсеного файла(комментарии ведь не несут никакой информации ,используемой компилятором)?

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

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

B>Почему?

Раз уж название форума такое, то пофилософствую: документация — важная часть исходного кода

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

B>Что мешает делать не сравнивать даты модификации,а сравнивать структуры распарсеного файла(комментарии ведь не несут никакой информации ,используемой компилятором)?
это будет дольше чем перекомпилировать

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

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

B>>Что мешает делать не сравнивать даты модификации,а сравнивать структуры распарсеного файла(комментарии ведь не несут никакой информации ,используемой компилятором)?
C>это будет дольше чем перекомпилировать

Это будет быстрее чем перекопилить и перелинковать(С++).

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

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

B>>Почему?

SE>Раз уж название форума такое, то пофилософствую: документация — важная часть исходного кода
Так при чём тут важная часть?
Никто не предлагает их удалять.
Вопрос состоит в том,что если содержимое файла ,которое необходимо компилятору и,соответственно, линкеру не изменилось — зачем пееркомпилировать?
Очевидно,что компилятору(С++) комментарии ничем помочь не могут.

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

B>Это будет быстрее чем перекопилить и перелинковать(С++).

это утверждение неплохо было бы чемто подтвердить.

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

да и еще нужно будет дебагерную информацию обновить, на случай если мы в комент строчку добавили.

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

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

B>>Это будет быстрее чем перекопилить и перелинковать(С++).

C>это утверждение неплохо было бы чемто подтвердить.

C>главные затраты уйдут на парсинг. который делеть нужно будет и там и там. причем при проверки надо будет поднять старую структуру чтобы было с чем сравнивать.

C>да и еще нужно будет дебагерную информацию обновить, на случай если мы в комент строчку добавили.

Ок.Рассмотрим случай с хедерами.
Я поменял точку на запятую в главном инклюде проекта и получил полню пересборку 40 Мб исходников,хотя я ничего не менял в приложении,тем более я делал изменения в хедере,в который дебаггер не лазит особо.
+ дебаггер же как-то справляется с тем,что хедера инклюдятся как есть и показывает смещения(номера строк) именно как они есть в коде с исходниками ,а не с включёнными в них хедерами.
В чём сложность инклюдить их(хедера) без комментов вообще?

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

B>Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?
B>Есть какие-то принципиальные трудности с определением изменений везде, кроме определённых блоков текста?
B>Если изменилась метаинформация — то пересобирать,но вот если в комменте поменялась точка на три точки где-нибудь в одном из основных хедеров(рассмотрим случай с С++) — это вызывает пересборку всего проекта (я конечно упускаю некоторые моменты,позволяющие уменьшить влияние отдельного файла,но не в этом суть).Почему?
B>- Настолько сложно?
B>- Никому не нужно?
B>- Просто лень?(напоминает ситуацию с дебаггером С++ в MSVS, когда он не может дебажить после 65535 строчки).

Идея хорошая, я в своем собственном языке программирования может быть сделаю такое.
Проще всего результаты лексического анализа скидывать в файлы (по аналогии с *.obj) и сравнивать с предыдущими версиями, которые сохранять. Тогда можно без дальнейшего парсинга отсеивать изменения в комментариях, пробелах/переносах строк и прочих незначащих вещах. Лексический анализ одного файла и сравнение двух небольших таблиц в десяток кибобайт займет всяко меньше времени чем ребилд проекта.

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

B>Спасибо за ответы

В проекте может быть некий препроцессор, генерирующий файлы, пользуясь информацией из специально сформированных комментариев.
Например, Doxygen для генерации документации.
Можно вообразить проект, где в комментарии может добавляться информация, нужная для генерации кода биндингов к скриптовому языку.

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

С>В проекте может быть некий препроцессор, генерирующий файлы, пользуясь информацией из специально сформированных комментариев.
С>Например, Doxygen для генерации документации.
С>Можно вообразить проект, где в комментарии может добавляться информация, нужная для генерации кода биндингов к скриптовому языку.

Я как раз такой подход использовал 1.5-2 года назад для генерации C++ кода для работы с телекоммуникационным протоколом. Структура PDU как раз описывалась в комментариях. Вот некоторые подробности.

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

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

P>С комментариями не всегда очевидно, пример:

P>

#define trick /##*

P>int main(){
P>    char *h="Hello", *w="";
P>    trick;        
P>    w = "world"; 
P>    /*print message*/
P>    printf("%s %s!",h,w);
P>    /*return*/
P>    return 0;
P>}

P>Если удалить комментарий «/*print message*/», то перестанет печататся текст.

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

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

B>Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?
B>Есть какие-то принципиальные трудности с определением изменений везде, кроме определённых блоков текста?
B>Если изменилась метаинформация — то пересобирать,но вот если в комменте поменялась точка на три точки где-нибудь в одном из основных хедеров(рассмотрим случай с С++) — это вызывает пересборку всего проекта (я конечно упускаю некоторые моменты,позволяющие уменьшить влияние отдельного файла,но не в этом суть).Почему?
B>- Настолько сложно?
B>- Никому не нужно?
B>- Просто лень?(напоминает ситуацию с дебаггером С++ в MSVS, когда он не может дебажить после 65535 строчки).

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

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

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

Я в C# использую комментарии вида

/// <summary>
/// Does something
/// </summary>

При перекомпиляции в студии появится измененная всплывающая подсказка к функции.

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

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

С>>В проекте может быть некий препроцессор, генерирующий файлы, пользуясь информацией из специально сформированных комментариев.
С>>Например, Doxygen для генерации документации.
С>>Можно вообразить проект, где в комментарии может добавляться информация, нужная для генерации кода биндингов к скриптовому языку.

E>Я как раз такой подход использовал 1.5-2 года назад для генерации C++ кода для работы с телекоммуникационным протоколом. Структура PDU как раз описывалась в комментариях. Вот некоторые подробности.

Я ж и говорю — не значимых комментов/переносов строк и т.п.
метаинформацию в виде комментов никто не говорит исключать.