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

← →
@!!ex © (2010-03-10 14:59) [0]

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

← →
Правильный$Вася (2010-03-10 15:01) [1]

intel ?

← →
crux (2010-03-10 15:06) [2]

Ишь чего захотели. Это вам не Delphi. Если уж такой адский проект, то структурировать файлы для уменьшения вероятности правок на файл и правильно использовать precompiled headers пробовали?

← →
Anatoly Podgoretsky © (2010-03-10 15:07) [3]

быстрый и C++ - это фантастика
Спрашивать надо наименее медленный

← →
@!!ex © (2010-03-10 15:17) [4]

> [2] crux (10.03.10 15:06)
> Если уж такой адский проект, то структурировать файлы для
> уменьшения вероятности правок на файл и правильно использовать
> precompiled headers пробовали?

Проект не адский, компилируетяся несколько секунд. Это долго.
Линкуется тоже не быстро.

> [3] Anatoly Podgoretsky © (10.03.10 15:07)

Ну да. Это и имел ввиду. :)

← →
crux (2010-03-10 15:19) [5]

@!!ex © (10.03.10 15:17) [4]

С жиру беситесь.

← →
@!!ex © (2010-03-10 15:29) [6]

> [5] crux (10.03.10 15:19)

Не вам судить

← →
crux (2010-03-10 15:32) [7]

@!!ex © (10.03.10 15:29) [6]

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

← →
@!!ex © (2010-03-10 15:45) [8]

> [7] crux (10.03.10 15:32)

http://ashemyakin.ru/qt-pch/
8 секунд сейчас. Ужасно медленно. Хотя бы в два раза сократить...

← →
Anatoly Podgoretsky © (2010-03-10 15:52) [9]

> crux (10.03.10 15:32) [7]

Так к нему еще и напильник нужен?

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

precompiled headers наше все

← →
DVM © (2010-03-10 16:11) [11]

> @!!ex © (10.03.10 15:45) [8]

Придется тебе отвыкать от стиля работы в Delphi - 2 строки написал - компильнул, 2 строки написал - компильнул.

← →
@!!ex © (2010-03-10 16:21) [12]

> [10] Игорь Шевченко © (10.03.10 16:10)

это да, но они не спасают.

> [11] DVM © (10.03.10 16:11)

А жаль. :(
Многих ошибок удается избежать при таком стиле...

← →
KSergey © (2010-03-10 16:26) [13]

> @!!ex © (10.03.10 16:21) [12]
> Многих ошибок удается избежать при таком стиле...

неправда

← →
Piter © (2010-03-10 16:27) [14]

DVM © (10.03.10 16:11) [11]
Придется тебе отвыкать от стиля работы в Delphi - 2 строки написал - компильнул, 2 строки написал - компильнул.

блин, а я вот тоже так привык к этому стилю... Никогда раньше не понимал, нафига в средах есть такое понятие, как "проверка синтаксиса", клацнул F9 - оно и синтаксис проверилось и все на свете сразу ))

Вот думаю - это вообще хорошо или плохо такая привычка? Понятное дело, что это плохая привычка для языков с "медленной" компиляцией, а вообще в целом?

Фактически, это сводится к тестированию правильности написания кода. С одной стороны, чем раньше замечена ошибка - тем лучше. С другой стороны, не слишком ли избыточно время проверки "каждые 2 строки" при том, что грамотный программер пишет зачастую безошибочно куда большее число строк.

← →
KSergey © (2010-03-10 16:28) [15]

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

← →
Piter © (2010-03-10 16:28) [16]

@!!ex, извини... По ходу твой вопрос скоро все позабудут ))

← →
KSergey © (2010-03-10 16:29) [17]

> KSergey © (10.03.10 16:28) [15]
> самые дорогие все равно только через пол-года эксплуатации
> всплывают, и от количества компиляций точно не зависят.

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

Так что не туда копаем, считаю.

← →
Sergey Masloff (2010-03-10 16:35) [18]

@!!ex © (10.03.10 16:21) [12]
>Многих ошибок удается избежать при таком стиле...
Да ну, дело привычки...

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

> [18] Sergey Masloff (10.03.10 16:35)

Когда я могу почти каждую строку протестировать - unit тесты становятся не нужны.
А на С++ полюбому придется юнит тесты писать, иначе будут проблемы.

← →
crux (2010-03-10 16:44) [20]

@!!ex © (10.03.10 15:45) [8]

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

← →
Anatoly Podgoretsky © (2010-03-10 16:45) [21]

> DVM (10.03.2010 16:11:11) [11]

Какое две строки, букву исправил - откомпилировал

← →
Anatoly Podgoretsky © (2010-03-10 16:48) [22]

> KSergey (10.03.2010 16:29:17) [17]

У нас нет времени на отладку, проще писать сразу правильно.

← →
Имяозер (2010-03-10 16:55) [23]

Юнит-тесты не для того пишутся.

← →
TUser © (2010-03-10 16:57) [24]

> @!!ex © (10.03.10 15:45) [8]
>
> > [7] crux (10.03.10 15:32)
>
> http://ashemyakin.ru/qt-pch/
> 8 секунд сейчас. Ужасно медленно. Хотя бы в два раза сократить...

Ну у тебя и проблемы ... :)

По поводу ошибок. Я как-то для себя обнаружил, что если набирать текст программы в ФАРе, то ошибок будет меньше. Потому что становишься более внимательным. Ctrl+Space только не хвататет, но привыкнуть можно. А мелкие опечатки можно исправить в среде после того, как набрал строчек 200 кода.

← →
DVM © (2010-03-10 17:03) [25]

> TUser © (10.03.10 16:57) [24]

> что если набирать текст программы в ФАРе, то ошибок будет
> меньше

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

← →
Alkid © (2010-03-10 17:07) [26]

> @!!ex © (10.03.10 16:38) [19]
> Когда я могу почти каждую строку протестировать - unit тесты
> становятся не нужны. А на С++ полюбому придется юнит тесты писать, иначе будут проблемы.

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

← →
@!!ex © (2010-03-10 17:31) [27]

> [26] Alkid © (10.03.10 17:07)

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

Я протестирую очень просто: выполню роль юнит теста, прогнав тестирование кода сразу.

← →
Kerk © (2010-03-10 17:37) [28]

Макконнел пишет, что перекомпиляция для проверки правильности кода признак того, что программист не в полной мере понимает чего написал.

← →
Имяозер (2010-03-10 17:45) [29]

В первую очередь юнит-тесты нужны при правке кода (рефакторинг, исправление ошибок), чтобы проверить, что ничего не сломалось где-то.

← →
Игорь Шевченко © (2010-03-10 17:49) [30]

Kerk © (10.03.10 17:37) [28]

Он про Delphi не пишет. К Delphi это не относится.

← →
KSergey © (2010-03-10 17:50) [31]

> @!!ex © (10.03.10 17:31) [27]
> Я протестирую очень просто: выполню роль юнит теста, прогнав
> тестирование кода сразу.

Научи?

← →
KSergey © (2010-03-10 17:51) [32]

> Игорь Шевченко © (10.03.10 17:49) [30]
> Он про Delphi не пишет. К Delphi это не относится.

Почему? ожно чуть развернутее написать.

← →
Кто б сомневался © (2010-03-10 17:52) [33]

> DVM © (10.03.10 16:11) [11]
>
>
> > @!!ex © (10.03.10 15:45) [8]
>
> Придется тебе отвыкать от стиля работы в Delphi - 2 строки
> написал - компильнул, 2 строки написал - компильнул.

Причем даже при проектировании формы так делаю. Подвинул батон, поставил рамку - запускаю смотрю на реальном - Design Time как то не доверяю..

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

KSergey © (10.03.10 17:51) [32]

У delphi быстрый компилятор. У всего остального, про что пишет МакКоннел, компилятор медленнее. Я не считаю, что просматривать вручую код программы на предмет ошибок есть хоть чего-то стоящая трата времени.

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

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

А не надо просматривать. Надо сразу правильно писать. Благо программист - не секретарша, задачи печатать 400 знаков в минуту не стоит.

← →
Alkid © (2010-03-10 18:13) [36]

> @!!ex © (10.03.10 17:31) [27]

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

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

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

← →
Kerk © (2010-03-10 18:14) [37]

И речь ведь не о компиляции вообще, ибо ее не избежать, а о компиляции раз в минуту.

← →
DVM © (2010-03-10 18:23) [38]

> а о компиляции раз в минуту.

Какая разница, раз в минуту, раз в 10 секунд, она ж все равно выполняется пару секунд. Ничего плохого в этом нет. Кому нравится - пусть компилирует. Вреда от этого нет.

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

С тем же успехом можно ратовать за отмену проверки орфографии в ворде.

← →
Kerk © (2010-03-10 18:25) [39]

> DVM © (10.03.10 18:23) [38]
>
> > а о компиляции раз в минуту.
>
> Какая разница, раз в минуту, раз в 10 секунд, она ж все
> равно выполняется пару секунд. Ничего плохого в этом нет.
> Кому нравится - пусть компилирует. Вреда от этого нет.

Ну как нет? Однажды попадает в руки медленный компилятор и проблемы проявляются. Вредные привычки не стоит культивировать и поощрять.

← →
Игорь Шевченко © (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 никогда все не собиралось - модули собирались, проверялись, возможно с разбросом по времени, но, опять же, основные модули практически не менялись с начала разработки.

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

← →
Alkid © (2010-03-10 20:20) [69]

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

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

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

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

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

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

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

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

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

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

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

--

← →
Alkid © (2010-03-10 20:32) [71]

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

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

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

Alkid © (10.03.10 20:20) [69]

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

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

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

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

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

> Игорь Шевченко (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. Посчитай количество файлов в твоем проекте, если сможешь - то на сколько кусков на винте фрагментирован каждый файл, потом посчитай, сколько файлов создается/модифицируется при компиляции, просуммируй, перемножь, снова просуммируй, посмотри на полученный результат и удивись. Сначала теоретически. А потом, если жаба не задушит взять для работы пару хороших винтов,- практически.

> DVM © (10.03.10 17:03) [25]
>
>
> > TUser © (10.03.10 16:57) [24]
>
>
> > что если набирать текст программы в ФАРе, то ошибок будет
> > меньше
>
> Про производительность сего труда умолчим. С подсказками
> оно много быстрее, а если еще CnPack стоит так вообще небо
> и земля.
>

Может я какой-то неправильный, но обычно на воспоминания о том, как называется метод из N стандартно используемых и набор на клавиатуре его названия ухудит примерно 0,1% времени. Остальное - думаю, как и чего написать. Что такое CnPack не знаю, правда.

> Может я какой-то неправильный, но обычно на воспоминания
> о том, как называется метод из N стандартно используемых

Значение N не озвучено. Имхо.

> [80] Харакири (11.03.10 00:58)

ПОставил RAM Disk, перенес на него все проекты. Скорость компиляции изменилась с 8 до 7 секунд. Не взлетело.

> Харакири (11.03.2010 00:58:20) [80]

Требование RAID-0 говорит о том, что там не все чисто с чтением и временем доступа.

> TUser © (11.03.10 01:09) [81]

> Может я какой-то неправильный, но обычно на воспоминания
> о том, как называется метод из N стандартно используемых
> и набор на клавиатуре его названия ухудит примерно 0,1%
> времени

Если методов не 3 штуки, а сотни и написаны они год назад и не тобой, то вряд ли все будет столь радужно. CnPack в том числе это и расширенные подсказки при наборе кода, может подсказывать имена констант, функций-не методов, закрывает begin-end сам, улучшенная подсветка, выделение блоков верт линиями, там много всего. С ним создание кода идет намного шустрее.

> улучшенная подсветка

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

эх, везет же людям.
Раз кнопку, прифигачил к ней код (видимо быстро, раз 2 сек - критичное время) - и тут же проверил.
Тут, блин, дня два минимум колбасишь, чтобы реакцию от кнопки получить осмысленную... даже 5..10 минут компиляции - уже фигня, как раз кофей испил, до этого руки заняты.

> Alkid © (11.03.10 13:29) [88]
> > KSergey © (11.03.10 13:22) [87]
> Что и на чем ты пишешь?

quik ru
почти на всем здесь обсуждаемом :)

> [87] KSergey © (11.03.10 13:22)

Я периодически упоминаю здесь эту ссылку, но все же упомяну еще раз:
http://www.youtube.com/watch?v=lQuG9ZWBGrs

Благодаря подходу две строчки-компиляция - программа не падает в AV ВООБЩЕ никогда. И все что прога делает она делает именно так, как от нее ждут.

@!!ex © (11.03.10 14:02) [90]

> Я периодически упоминаю здесь эту ссылку, но все же упомяну
> еще раз:
> http://www.youtube.com/watch?v=lQuG9ZWBGrs

А орфографический словарь в числе друзей не входит ?

> [91] Игорь Шевченко © (11.03.10 14:19)

Мне надо чтобы работало хорошо. :)
А по русскому языку у меня 3 было, есть и будет есть.

> @!!ex © (11.03.10 14:02) [90]
> Благодаря подходу две строчки-компиляция - программа не падает в AV ВООБЩЕ никогда.

Похвастаться этим не могу.
Придется, видимо, уйти в монастырь, тут ты меня уделал по полной, признаю.

> @!!ex (11.03.2010 14:02:30) [90]

Как все просто - пиши по две строчки и запускай и имеем безглючную программу.

> @!!ex © (11.03.10 14:02) [90]
> Благодаря подходу две строчки-компиляция - программа не
> падает в AV ВООБЩЕ никогда.

А какая тут связь вообще?

> [93] KSergey © (11.03.10 14:31)

На самом деле я слукваил. AV легко добиться если подсунуть ей файл с кривым содержанием. ;) Также как делали с прогой для тестов.

> [95] Kerk © (11.03.10 14:59)
> А какая тут связь вообще?

Тщательное тестирование - панацея от всех бед.

> @!!ex © (11.03.10 15:22) [96]
> Тщательное тестирование - панацея от всех бед.

Какая связь между компиляцией и тестированием?

> [97] Kerk © (11.03.10 15:25)

За то время пока компилируется С++ проект я успеваю три раза откомпилировать и проверить работоспособность под Дельфи. Я думал связь очевидна.
Подход: много написать, а потом за раз оттестировать работает хуже.

> @!!ex © (11.03.10 15:22) [96]
> На самом деле я слукваил. AV легко добиться если подсунуть
> ей файл с кривым содержанием.

ну вот тебе и здрасьте
ладно, тогда не пойду в монастырь

так если мне не подсовывать кривой ini-файл и не посылать кривых транзакций - так и я тоже не свалюсь ни в жисть.

> [99] KSergey © (11.03.10 15:31)

Ок. Будем считать что здесь все пишут прямой и красивый код.
А тот быдло софт, что весь в утечках памяти и в AV через час после запуска при отсутсвии активности, пишет кто-то другой, кто на это ресурсе не расскзывает о том, как нужно писать программы.

> @!!ex (11.03.2010 15:22:36) [96]

Так ты же предлагаешь заменить тщательное, частым - ведь это не одно и тоже.

MSVC++ с полностью отключенными оптимизациями + Precompiled Headers + Ram Disk дает вполне себе хороший результат. Порядка секунды. Проблемы уже в линковку упираются.

а как ram disk создаешь?

Super Speed Ram Disk
+
Allway Sync для периодического сбрасывания кода на энергонезависимый носитель

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