Самый быстрый C++ компилятор

← →
Игорь Шевченко © (2010-03-10 18:25) [40]

> А не надо просматривать. Надо сразу правильно писать

научи ?

← →
Kerk © (2010-03-10 18:35) [41]

> Игорь Шевченко © (10.03.10 18:25) [40]
>
> научи ?

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

← →
Alkid © (2010-03-10 18:44) [42]

> Игорь Шевченко © (10.03.10 18:25) [40]
> научи ?

Хороший Code Insight позволяет устранять кучу проблем. Только С++ имеет родовую травму в виде идиотской системы включения файлов, что делает создание таких инструментов проблематичным.

← →
Игорь Шевченко © (2010-03-10 18:53) [43]

Kerk © (10.03.10 18:35) [41]

А кто говорит о двух минутах ? Написал логический кусок кода, откомпилировал, радуешься.

> Хороший Code Insight позволяет устранять кучу проблем

Или показывать кучу проблем там, где их нет. Я в курсе, о том, что есть Code Insight.

> Только С++ имеет родовую травму в виде идиотской системы
> включения файлов, что делает создание таких инструментов
> проблематичным.

А как пишутся большие проекты на С, ты не в курсе ?

← →
Kerk © (2010-03-10 18:55) [44]

> Игорь Шевченко © (10.03.10 18:53) [43]
>
> Kerk © (10.03.10 18:35) [41]
>
> А кто говорит о двух минутах ? Написал логический кусок
> кода, откомпилировал, радуешься.

Тут в теме говорят.
"Две строки написал - компильнул"

← →
oldman © (2010-03-10 19:10) [45]

> Игорь Шевченко © (10.03.10 18:53) [43]
> Kerk © (10.03.10 18:35) [41]
>
> А кто говорит о двух минутах ? Написал логический кусок
> кода, откомпилировал, радуешься.
>
> Kerk © (10.03.10 18:55) [44]
> > Игорь Шевченко © (10.03.10 18:53) [43]
> Тут в теме говорят.
> "Две строки написал - компильнул"

Иногда и две строки - большой логический кусок :)))

← →
Alkid © (2010-03-10 19:11) [46]

> Игорь Шевченко © (10.03.10 18:53) [43]
> Или показывать кучу проблем там, где их нет. Я в курсе,
> о том, что есть Code Insight.

Где как. Сейчас разрабатываю на C# в Visual Studio 2008 + Resharper, все просто шикарно. Там тебе и классный auto-complete и поиск ошибок "на лету", и статический анализ кода. Впечатления очень положительные. А работа на С++ с Visual Studio 2005 + Visual Assist оставили средние впечатления.

> А как пишутся большие проекты на С, ты не в курсе ?

Это очень смелое предположение с твоей стороны :)

На прошлой работе у нас была очень большая кодовая база на С/С++, помноженная на собственную систему сборки проектов на базе nmake. Для удобства работы программистов была возможность генерировать проекты/решения для Visual Studio 2003/2005. Однако на кодовой базе такого размера студия глючила и тормозила, что несильно облегчало работу. В итоге основной способ работы с исходниками был grep + notepad++ . С учетом развитых возможностей препроцесора поиск интересующих определений иногда становился... очень творческим процессом. Сборка проектов занимала о 10 минут :)

Все это приучило к некоторой дисциплине, так что поднятая тема вызывает некоторое непонимание :) Культурный барьер, так сказать.

← →
@!!ex © (2010-03-10 19:18) [47]

> [35] Kerk © (10.03.10 18:13)
> А не надо просматривать. Надо сразу правильно писать. Благо
> программист - не секретарша, задачи печатать 400 знаков
> в минуту не стоит.

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

P.S.
Вот интересно, что мешает сделать IDE, которая в фоне собирает модули которые программист сейчас НЕ редактирует?
Благо ядер много, и в процессе написания кода - почти полностью бездействуют. Компиляция была бы мгновенной.
Я ради такой фишки купил бы четырехядерник. :(

← →
@!!ex © (2010-03-10 19:20) [48]

> С учетом развитых возможностей препроцесора поиск интересующих
> определений иногда становился... очень творческим процессом.
> Сборка проектов занимала о 10 минут :)

Удобно было?

← →
DVM © (2010-03-10 19:20) [49]

> Вот интересно, что мешает сделать IDE, которая в фоне собирает
> модули которые программист сейчас НЕ редактирует?

Я сижу смотрю на код модуля и думаю. В любое мгновение я могу что то изменить. От этого модуля зависит еще 100 других. Я редактирую его или нет?

← →
@!!ex © (2010-03-10 19:22) [50]

> [36] Alkid © (10.03.10 18:13)
> Ценность юнит тестов в том, что их можно быстро прогнать
> когда угодно. Их основное назначение - быстро обнаружить
> ломающее изменение, проведенное при рефакторинге или модификации
> прогаммы. То, что ты говоришь, никак не заменяет юнит тесты.
> Ты совершенно напрасно помянул их в контексте своей проблемы.

Вот как раз применимо к дельфи заменяет. Быстрее првоести несколько компиляций и запусков, чем писать отдельный юнит тест.

← →
@!!ex © (2010-03-10 19:22) [51]

> [49] DVM © (10.03.10 19:20)
> От этого модуля зависит еще 100 других. Я редактирую его
> или нет?

Если h редактируешь, то зависят только те, кто его использует.
Если cpp то вообще никто не зависит.

← →
@!!ex © (2010-03-10 19:24) [52]

> [49] DVM © (10.03.10 19:20)
> В любое мгновение я могу что то изменить.

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

← →
Игорь Шевченко © (2010-03-10 19:27) [53]

Alkid © (10.03.10 19:11) [46]

> Это очень смелое предположение с твоей стороны :)

Это был вопрос, а не предположение.

Я к чему спрашивал, в свое время приходилось принимать участие. Было это в конце 80-ых, начале 90-ых, соответственно, никаких нахрен Visual Studio, Code Insight-ов и прочих IDE не было. Да и откуда в то время возьмутся IDE на Unix и на VAX/VMS, на PC был Turbo C - максимум удобств по редактированию и компиляции. Но небыстрой.

И ничего, знаете ли, писались проекты, и неплохие и немаленькие :)

← →
Alkid © (2010-03-10 19:28) [54]

> @!!ex © (10.03.10 19:22) [50]

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

И еще, если дельфи отменяет необходимость юнит-тестов, зачем же их пишут для программ на дельфи? Сдаётся мне, что с юнит-тестами ты всё-таки что-то путаешь.

← →
Piter © (2010-03-10 19:30) [55]

Кто б сомневался © (10.03.10 17:52) [33]
Подвинул батон, поставил рамку - запускаю смотрю на реальном - Design Time как то не доверяю..

Точно, точно. Так и бывает )))

← →
Piter © (2010-03-10 19:33) [56]

Kerk © (10.03.10 18:25) [39]
Однажды попадает в руки медленный компилятор и проблемы проявляются. Вредные привычки не стоит культивировать и поощрять.

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

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

Логика, думаю, понятна? Имхо, если нечто позволяет удобно делать что-то, этим надо пользоваться, а не отказываться от этого насильно из-за того, что в другом нечто этого может не быть, а ты блин оказывается уже привык.

← →
Piter © (2010-03-10 19:33) [57]

Собственно, отличнейшая аналогия:

DVM © (10.03.10 18:23) [38]
С тем же успехом можно ратовать за отмену проверки орфографии в ворде.

← →
@!!ex © (2010-03-10 19:34) [58]

> [54] Alkid © (10.03.10 19:28)
> Сколько у тебя времени займет перепроверять все руками?

Зачем все проверять? Только то, что изменилось.
Вероятно я не понимаю смысл юнит тестов, потому что в моей области они почти не применяются.

← →
Alkid © (2010-03-10 19:36) [59]

> Игорь Шевченко © (10.03.10 19:27) [53]
> Это был вопрос, а не предположение.

Ладно, проехали :)

> И ничего, знаете ли, писались проекты, и неплохие и немаленькие :)

И у вас кто-то сокрушался, что нельзя проект за 2 секунды пересобрать?

P.S. К программистам, которые без IDE ничего сделать не могут, я сам отношусь негативно.

← →
Pavia © (2010-03-10 19:40) [60]

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

Насколько помню буильдер с отключенной оптимизацией компилирует ни чуть не дольше Delphi. Только давно это было возможно на старой версии.

← →
Mystic © (2010-03-10 19:41) [61]

> Тут в теме говорят.
> "Две строки написал - компильнул"

А чем плохо? Например, не так давно я написал нечто такое:

var Handles: array[0..1] of THandle; ExitEvent: THandle absolute Handles[0]; MonitorEvent: THandle absolute Handles[1];

скомпилировал, получил ошибку. Значит надо переписать через константы. Заняло пару секунд, или мне надо было читать стандарт?

Кстати, в C++ при работе с многоэтажными шаблонами часто такой возможности не хватает. Ну не могу я вывести, нужен конструктор по умолчанию в классе или нет, проще запустить и проверить...

← →
Anatoly Podgoretsky © (2010-03-10 19:54) [62]

> Kerk (10.03.2010 18:25:39) [39]

Вот тогда и отучится, а пока ни к чему.

--

← →
Anatoly Podgoretsky © (2010-03-10 19:55) [63]

> Игорь Шевченко (10.03.2010 18:25:40) [40]

Этому тридцать лет надо учиться.

--

← →
Anatoly Podgoretsky © (2010-03-10 19:56) [64]

> Alkid (10.03.2010 18:44:42) [42]

Зато в C#/VB.NET отличный Code Insight, лучше Дельфи

--

← →
Anatoly Podgoretsky © (2010-03-10 19:58) [65]

> Alkid (10.03.2010 19:11:46) [46]

Хорошее оно развращает.

--

← →
Anatoly Podgoretsky © (2010-03-10 20:03) [66]

> Alkid (10.03.2010 19:28:54) [54]

А сколько времени займет написание тестов и вопрос о их правильности, Но я ничего не имеют против них или их пользы, скорее наоборот.

--

← →
Anatoly Podgoretsky © (2010-03-10 20:04) [67]

> Piter (10.03.2010 19:30:55) [55]

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

--

← →
Игорь Шевченко © (2010-03-10 20:09) [68]

Alkid © (10.03.10 19:36) [59]

А у нас не пересобирали весь проект целиком. Несколько миллионов строк на тех мощностях собирать по требованию - это нонсенс. Так как проект был модульный, собирали, натурально, по модулям, файлы, которые будут влиять на все модули, написали и протестировали одними из первых, так что одного изменения, которое затронет все, не было никогда. Часть затронет - так часть пересоберется относительно быстро. Тем более, никогда не собиралось под все системы сразу - максимально целевой системой изначально был Unix, под нее собиралось чаще всего, а под PC и VAX никогда все не собиралось - модули собирались, проверялись, возможно с разбросом по времени, но, опять же, основные модули практически не менялись с начала разработки.

Благо ТЗ было достойное.

> @!!ex © (10.03.10 19:34) [58]

Очень рекомендую ознакомиться, действительно хорошая вещь.

> Anatoly Podgoretsky © (10.03.10 20:03) [66]

Безусловно. Выработать высокую культуру разработки с применением юнит-тестов сложно. Я сам еще далеко не освоил это искусство и не стесняюсь по этому поводу спрашивать консультации у старших товарищей.

> Игорь Шевченко © (10.03.10 20:09) [68]

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

И все же, даже удачный опыт разработки больших проектов не означает, что заголовочные файлы - это не зло. :) Время, потраченное на долбание с ними можно было потратить с большей пользой :)

P.S. А что за проект вы делали такой?

> Alkid (10.03.2010 20:20:09) [69]

Я слышал такое мнение, что юнит тесты должны писаться до "юнитов"

--

> Anatoly Podgoretsky © (10.03.10 20:28) [70]

Это один из подходов. Скажем так, ортодоксальная ветвь Test Driven Development.

Alkid © (10.03.10 20:20) [69]

> P.S. А что за проект вы делали такой?

кросс-систему.

> И все же, даже удачный опыт разработки больших проектов
> не означает, что заголовочные файлы - это не зло. :) Время,
> потраченное на долбание с ними можно было потратить с большей
> пользой :)

Да как-то не испытывалось особенного долбания. Может, проектирование было правильное ? :)

> Игорь Шевченко (10.03.2010 20:45:12) [72]

Правильность портит чистоту эксперимента.

← →
Харакири (2010-03-10 21:32) [74]

RAID-0 из 2-х SSD Intel X25-E

> [74] Харакири (10.03.10 21:32)

Что это даст? Компиляция в процессор упирается

> [47] @!!ex © (10.03.10 19:18)

> Вот интересно, что мешает сделать IDE, которая в фоне собирает
> модули которые программист сейчас НЕ редактирует?

такую IDE сделали - Делфи называется ))

> Игорь Шевченко © (10.03.10 20:45) [72]
> Да как-то не испытывалось особенного долбания. Может, проектирование
> было правильное ? :)

Вполне допускаю. У нас там была своя организационная специфика, не способствующая порядку.

← →
GDI+ (2010-03-10 23:25) [78]

> Piter © (10.03.10 16:27) [14]
>
> DVM © (10.03.10 16:11) [11]
> Придется тебе отвыкать от стиля работы в Delphi - 2 строки
> написал - компильнул, 2 строки написал - компильнул.
>
> блин, а я вот тоже так привык к этому стилю... Никогда раньше
> не понимал, нафига в средах есть такое понятие, как "проверка
> синтаксиса", клацнул F9 - оно и синтаксис проверилось и
> все на свете сразу ))

Угу, а потом в большом проекте стиль - один баг поправили, два добавили.

← →
GDI+ (2010-03-10 23:39) [79]

> @!!ex © (10.03.10 14:59)
>
> Нужен компилятор для С++, который максимально быстро компилирует
> сорсы.
> Скорость работы программы и размеры кода значения не имеют.
>
> Это нужно для скорения разработки.
> Релиз мы можем любым компилятором собирать, это значения
> не имеет.
> Спрашиваю здесь, потому что знаю, что почти все здесь имели
> и имеют дело с С++

Visual C++. В настройках проекта полностью отключить оптимизацию.

← →
Харакири (2010-03-11 00:58) [80]

Что это даст? Компиляция в процессор упирается

У тебя от удара головой (или чем ты там стучался?) о компиляцию на лбу остался отпечаток "процессор"? Посмотри внимательно в зеркало, там написано "дисковый ввод-вывод". Не видишь? Стукнись еще пару раз, да покрепче.

На 2-х WD Raptor в RAID-0 проект Delphi в 180К строк на Q6600 компилируется с первого захода 8 сек. После первой компиляции (читай: кеширования) - уже 3 сек. Учитывай, что компилятор не просто читает, но и пишет откомпилированный код во множество файлов, которые потом еще и линкует в большой файл, а на эти процессы кеш уже не так сильно влияет (часто он вообще отключен - надежность чаще важнее скорости). А когда ты подумаешь, сколько мелких файлов приходится читать/писать компилятору из/в разных/е участков/и диска, то поймешь, что SSD со временем доступа в 0,04 мс (сравни с позорными 14-16 мс на твоем нынешнем винте) и скоростью записи за 200 МБ/сек (не думаю, что у твоего нынешнего винта больше 50-60 МБ/сек на запись в среднем) ускоряет процесс в разы, а то и на порядки, особенно в RAID-0. Посчитай количество файлов в твоем проекте, если сможешь - то на сколько кусков на винте фрагментирован каждый файл, потом посчитай, сколько файлов создается/модифицируется при компиляции, просуммируй, перемножь, снова просуммируй, посмотри на полученный результат и удивись. Сначала теоретически. А потом, если жаба не задушит взять для работы пару хороших винтов,- практически.

Самый быстрый C++ компилятор Найти похожие ветки