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

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

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

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

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

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

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

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

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

B>>>>И что из этого следует? Что нельзя скипать изменения в compilation unit?
C>>>то что найти эти изменения стоит половины компиляции

B>>Это с какого перепугу ?
B>>Я уже приводил пример с 40 Мб исходников выше по ветке.

B>+ интеллисенс и т.п. штукам(решарпер и т.п.) в "реальном времени" как-то получается мониторить изменения в файлах, строить подсказки,предлагать рефакторинги и т.п.

Для С++?!

B>Но вот "компилятору"(может быть не конкретно cl.exe, но суть ,думаю,ясна)/IDE уже никак?

Если ошибется интеллисенс — ничего страшного не случится. Если ошибется компилятор — ... В общем нельзя ему

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

B>Почему?

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

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

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

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

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

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

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

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

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

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

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

То что СиПласПлас отсосал — это ясно.
Спасибо всем за ответы.
Это никому не нужно.

Вот меня уже давно мучает вопрос — что мешает разработчикам 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>Что мешает делать не сравнивать даты модификации,а сравнивать структуры распарсеного файла(комментарии ведь не несут никакой информации ,используемой компилятором)?
это будет дольше чем перекомпилировать

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

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

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

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

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

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

B>>Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С>В проекте может быть некий препроцессор, генерирующий файлы, пользуясь информацией из специально сформированных комментариев.
С>Например, 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 строчки).

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

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

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

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

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

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

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

ZS>

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

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

Из-за этого вы решили, что она попадает в бинарник?

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

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

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

VGn>Из-за этого вы решили, что она попадает в бинарник?

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

VGn>>Из-за этого вы решили, что она попадает в бинарник?

ZS>Не надо за меня придумывать что я решил. Я всего лишь привел пример того, что изменения в комментариях могут нести полезную информацию. А куда они попадают мне, если честно, все равно.

1. Vlad2 заявил, что включается, но несколько в общем виде, его никто не оспорил. Следующим сообщением шло ваше, с конкретикой.
2. Был знак вопроса.

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

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

Коментарии — это еще ладно. Вот в .net при компиляции можно было бы отслеживать изменилась ли интерфейсная часть зависимой сборки — изменились сигнатуры public-классов, появились новые методы в public-интерфейсах. И пересобирать проекты, юзающую сборку, только если она поменялась.

И тогда бы фикс в реализации какого-нибудь метода в Utilities, подцепленного всеми проектами здоровенного солюшна, не вызывал бы пересборку всех проектов солюшна.

Например в C++ что-то подобное есть — интерфейсы там в h-файлах и лавинной перекомпиляции изменения в сpp-файлах не вызывают.

С другой стороны C# довольно быстро строится, так что необходимость этого всего не так ощутима. У большинства даже "copy local" стоит, а на это уходит порой до 90% времени компиляции. И ничего — не парятся люди.

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

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

C++ header file — ничем не отличается.

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

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

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

А как же компилятор понимает?

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

B>А как же компилятор понимает?
а компилятор не анализирует хеадер сам по себе. он про него ничего не знает.
он анализироет compilation unit, а то что этот юнит состоит из нескольких файлов ему глубоко фиолетово.

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

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

B>>А как же компилятор понимает?
C>а компилятор не анализирует хеадер сам по себе. он про него ничего не знает.
C>он анализироет compilation unit, а то что этот юнит состоит из нескольких файлов ему глубоко фиолетово.
И что из этого следует? Что нельзя скипать изменения в compilation unit?

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

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

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

B>>>А как же компилятор понимает?
C>>а компилятор не анализирует хеадер сам по себе. он про него ничего не знает.
C>>он анализироет compilation unit, а то что этот юнит состоит из нескольких файлов ему глубоко фиолетово.
B>И что из этого следует? Что нельзя скипать изменения в compilation unit?
то что найти эти изменения стоит половины компиляции

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

B>>И что из этого следует? Что нельзя скипать изменения в compilation unit?
C>то что найти эти изменения стоит половины компиляции

Это с какого перепугу ?
Я уже приводил пример с 40 Мб исходников выше по ветке.

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

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

B>>>И что из этого следует? Что нельзя скипать изменения в compilation unit?
C>>то что найти эти изменения стоит половины компиляции

B>Это с какого перепугу ?
B>Я уже приводил пример с 40 Мб исходников выше по ветке.

+ интеллисенс и т.п. штукам(решарпер и т.п.) в "реальном времени" как-то получается мониторить изменения в файлах, строить подсказки,предлагать рефакторинги и т.п.
Но вот "компилятору"(может быть не конкретно cl.exe, но суть ,думаю,ясна)/IDE уже никак?

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

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

B>Я уже приводил пример с 40 Мб исходников выше по ветке.
да. ситуация на первый взгляд странная. только ты от компилятора отличаешся тем что ты знаеш что это был комментарий, а компилятору надо это выяснить.

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

B>+ интеллисенс и т.п. штукам(решарпер и т.п.) в "реальном времени" как-то получается мониторить изменения в файлах, строить подсказки,предлагать рефакторинги и т.п.

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

B>Но вот "компилятору"(может быть не конкретно cl.exe, но суть ,думаю,ясна)/IDE уже никак?

А ты видел IDE для С++? Видел как "качественно" они работают?
А видел какие они создают базы данных для хранения разобранной информации?

Есть такое понятие "сложность". Если сложность начинает зашкаливать, то начинаются баги. Если обрабатывать С++-ные файлы в лоб, то сложность остается приемлемой. Если же начинать изгаляться, то сложность начинает расти в геометрической прогрессии.

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

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

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

B>>Я уже приводил пример с 40 Мб исходников выше по ветке.
C>да. ситуация на первый взгляд странная. только ты от компилятора отличаешся тем что ты знаеш что это был комментарий, а компилятору надо это выяснить.

Именно. Для этого в языках есть такие понятия как лексика. Если не ошибаюсь, в С++ макросы не могут раскрываться внутри комментариев, так что потенциально это возможно. Только вот ты правильно заметил, что проблем будет выше крыши. И все ради чего? Все равно в 99% случаев изменяется сам код.