Здравствуйте, VladD2, Вы писали:
VD>В современных компиляторах современных языков есть инкрементальная компиляция. Это намного лучше чем "отслеживание изменений в комментариях". Тем более, что в современных языках комментарии — это часть метаинформации которая включается в бинарные файлы (например, сборки дотнета).
VD>С++ — это древнебытный язык не имеющий не только понятия об инкрементальной компиляции, но и даже о модульности. Файлы включаются друг в друга простой текстуальной подстановку. При это еще работает текстовый препроцессор который может изменить содержимое файла как бог черепаху. Так что отслеживание изменений в комментариях или пробелов даже никто не обдумывает.
То что СиПласПлас отсосал — это ясно.
Спасибо всем за ответы.
Это никому не нужно.
Здравствуйте, blackhearted, Вы писали:
B>Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?
В принципе, как и любые другие изменения, — добавление табов, пробелов, перетасовка деклараций функций и т.д. Проще не заниматься этим вообще, имхо, время на перекалькуляцию для больших и сложных проектов может возрасти в разы.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, VGn, Вы писали:
VGn>Из-за этого вы решили, что она попадает в бинарник?
Не надо за меня придумывать что я решил. Я всего лишь привел пример того, что изменения в комментариях могут нести полезную информацию. А куда они попадают мне, если честно, все равно.
VGn>>Из-за этого вы решили, что она попадает в бинарник?
ZS>Не надо за меня придумывать что я решил. Я всего лишь привел пример того, что изменения в комментариях могут нести полезную информацию. А куда они попадают мне, если честно, все равно.
1. Vlad2 заявил, что включается, но несколько в общем виде, его никто не оспорил. Следующим сообщением шло ваше, с конкретикой.
2. Был знак вопроса.
Здравствуйте, blackhearted, Вы писали:
B>Вот меня уже давно мучает вопрос — что мешает разработчикам IDE игнорировать изменения в комментариях при пересборке проекта?
Коментарии — это еще ладно. Вот в .net при компиляции можно было бы отслеживать изменилась ли интерфейсная часть зависимой сборки — изменились сигнатуры public-классов, появились новые методы в public-интерфейсах. И пересобирать проекты, юзающую сборку, только если она поменялась.
И тогда бы фикс в реализации какого-нибудь метода в Utilities, подцепленного всеми проектами здоровенного солюшна, не вызывал бы пересборку всех проектов солюшна.
Например в C++ что-то подобное есть — интерфейсы там в h-файлах и лавинной перекомпиляции изменения в сpp-файлах не вызывают.
С другой стороны C# довольно быстро строится, так что необходимость этого всего не так ощутима. У большинства даже "copy local" стоит, а на это уходит порой до 90% времени компиляции. И ничего — не парятся люди.
Здравствуйте, 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, Вы писали:
B>Здравствуйте, blackhearted, Вы писали:
B>>Здравствуйте, cvetkov, Вы писали:
B>>>>И что из этого следует? Что нельзя скипать изменения в compilation unit? C>>>то что найти эти изменения стоит половины компиляции
B>>Это с какого перепугу ? B>>Я уже приводил пример с 40 Мб исходников выше по ветке.
B>+ интеллисенс и т.п. штукам(решарпер и т.п.) в "реальном времени" как-то получается мониторить изменения в файлах, строить подсказки,предлагать рефакторинги и т.п.
Для С++?!
B>Но вот "компилятору"(может быть не конкретно cl.exe, но суть ,думаю,ясна)/IDE уже никак?
Если ошибется интеллисенс — ничего страшного не случится. Если ошибется компилятор — ... В общем нельзя ему
Здравствуйте, blackhearted, Вы писали:
C>>то что найти эти изменения стоит половины компиляции B>Это с какого перепугу ?
потомучто для того чтобы понять где комментарии нужно распарсить весь проект. а это полоаина компиляции.
приэтом нужно всю эту информацию скинуть на диск и при следующей компиляции с диска достать и сравнить два слепка.
куча мороки.
B>Я уже приводил пример с 40 Мб исходников выше по ветке.
да. ситуация на первый взгляд странная. только ты от компилятора отличаешся тем что ты знаеш что это был комментарий, а компилятору надо это выяснить.
Здравствуйте, blackhearted, Вы писали:
B>+ интеллисенс и т.п. штукам(решарпер и т.п.) в "реальном времени" как-то получается мониторить изменения в файлах, строить подсказки,предлагать рефакторинги и т.п.
Решарпер написан для как бы другого языка. Для языка построенного на модульном принципе. В этом языке просто нет текстовых включений и текстовых макросов, так что можно анализировать только изменяемый файл.
B>Но вот "компилятору"(может быть не конкретно cl.exe, но суть ,думаю,ясна)/IDE уже никак?
А ты видел IDE для С++? Видел как "качественно" они работают?
А видел какие они создают базы данных для хранения разобранной информации?
Есть такое понятие "сложность". Если сложность начинает зашкаливать, то начинаются баги. Если обрабатывать С++-ные файлы в лоб, то сложность остается приемлемой. Если же начинать изгаляться, то сложность начинает расти в геометрической прогрессии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, cvetkov, Вы писали:
C>потомучто для того чтобы понять где комментарии нужно распарсить весь проект. а это полоаина компиляции.
Не весь проект, а модуль компиляции (файл). Но вместе со всеми включениями. А это может быть очень много.
B>>Я уже приводил пример с 40 Мб исходников выше по ветке. C>да. ситуация на первый взгляд странная. только ты от компилятора отличаешся тем что ты знаеш что это был комментарий, а компилятору надо это выяснить.
Именно. Для этого в языках есть такие понятия как лексика. Если не ошибаюсь, в С++ макросы не могут раскрываться внутри комментариев, так что потенциально это возможно. Только вот ты правильно заметил, что проблем будет выше крыши. И все ради чего? Все равно в 99% случаев изменяется сам код.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.