Здравствуйте, _Butch_, Вы писали:
_B_>Здравствуйте, flаt, Вы писали:
F>>Детальнее в статье: http://www.bfilipek.com/2014/12/c-status-at-end-of-2014.html
F>>Image: cpp14conf.png
_B_>Как получается, что GCC, который пишут безработные студенты, поддерживает стандарт лучше, чем MSVC, который пишут хорошо оплачиваемые профессионалы?
Наверно, потому что GCC пишут всё-таки профессионалы, а вот VC -- таки да, безграмотные и нищие индусы за еду.
Здравствуйте, Шахтер, Вы писали:
Ш>Наверно, потому что GCC пишут всё-таки профессионалы, а вот VC -- таки да, безграмотные и нищие индусы за еду.
не думал, что есть люди, которые думают иначе... жизнь такая непредсказуемая
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, _Butch_, Вы писали:
F>>Детальнее в статье: http://www.bfilipek.com/2014/12/c-status-at-end-of-2014.html F>>Image: cpp14conf.png _B_>Как получается, что GCC, который пишут безработные студенты, поддерживает стандарт лучше, чем MSVC, который пишут хорошо оплачиваемые профессионалы?
у этих двух продуктов разные цели. гцц только инструментарий без хорошой иде, но зато кроссплатформенный. мсвс не кроссплатформенный (можно пристроить гцц), но зато есть хорошая иде, неплохой интеллисенс изкаропки и куча няшек в придачу.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>у этих двух продуктов разные цели. гцц только инструментарий без хорошой иде, но зато кроссплатформенный. мсвс не кроссплатформенный (можно пристроить гцц), но зато есть хорошая иде, неплохой интеллисенс изкаропки и куча няшек в придачу.
бестолковая IDE без толкового компилятора — как безрукому балалайка.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, _Butch_, Вы писали:
_B_>Как получается, что GCC, который пишут безработные студенты, поддерживает стандарт лучше, чем MSVC, который пишут хорошо оплачиваемые профессионалы?
Писать можно по разному. Вот например тот же std::async в gcc просто тупо каждый раз заводит новый поток со всеми накладными расходами, а msvc использует пул потоков.
100% поддержка стандарта любой ценой это как раз цель для студентов. А сделать нормальную годную реализацию, чтоб она не тормозила и не принесла в будущем кучу проблем требует времени и денег.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, _Butch_, Вы писали:
F>>>Детальнее в статье: http://www.bfilipek.com/2014/12/c-status-at-end-of-2014.html F>>>Image: cpp14conf.png _B_>>Как получается, что GCC, который пишут безработные студенты, поддерживает стандарт лучше, чем MSVC, который пишут хорошо оплачиваемые профессионалы? V>у этих двух продуктов разные цели. гцц только инструментарий без хорошой иде, но зато кроссплатформенный. мсвс не кроссплатформенный (можно пристроить гцц), но зато есть хорошая иде, неплохой интеллисенс изкаропки и куча няшек в придачу.
Eclipse прекрасно работает с gcc. Как IDE он явно лучше VC. VC имеет смысл использовать только тем, что увяз в Майкрософтовских говнотехнологиях. Всем остальным горячо рекомендую слезть с него, чем раньше -- тем лучше.
Здравствуйте, Шахтер, Вы писали:
Ш>Eclipse прекрасно работает с gcc. Как IDE он явно лучше VC. VC имеет смысл использовать только тем, что увяз в Майкрософтовских говнотехнологиях. Всем остальным горячо рекомендую слезть с него, чем раньше -- тем лучше.
В принципе, обе IDE могут вести кросс-платформенную сборку при должной величине напильника (Студию можно переучить на другой тулчейн, но эклипсовый CDT тоже местами не сахар). Так что, при сборке под Win зависимость тут будет лишь чей рантайм брать: майкрософтовский или MinGW.
Но если Eclipse для Вас как IDE явно совершенней, чем VC, то я не знаю даже, к чему апеллировать. Видимо, это всё вкусовщина, или разные цели преследуем Кто-то ведь и в vim кодит...
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Шахтер, Вы писали:
Ш>>Наверно, потому что GCC пишут всё-таки профессионалы, а вот VC -- таки да, безграмотные и нищие индусы за еду. X>не думал, что есть люди, которые думают иначе... жизнь такая непредсказуемая
Какая разница кто GCC пишет — собирать-то всё равно Никсману
Здравствуйте, _Butch_, Вы писали:
_B_>Как получается, что GCC, который пишут безработные студенты, поддерживает стандарт лучше, чем MSVC, который пишут хорошо оплачиваемые профессионалы?
А Вы представьте другой график: сколько фич новых стандартов реально востребованы в ежедневном девелопменте? Народ в массе ещё к вариадик-темплейтам толком не привык, а гики уже морщатся при виде "partial C++14 compliance".
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Шахтер, Вы писали:
Ш>>Eclipse прекрасно работает с gcc. Как IDE он явно лучше VC. VC имеет смысл использовать только тем, что увяз в Майкрософтовских говнотехнологиях. Всем остальным горячо рекомендую слезть с него, чем раньше -- тем лучше.
MD>В принципе, обе IDE могут вести кросс-платформенную сборку при должной величине напильника (Студию можно переучить на другой тулчейн, но эклипсовый CDT тоже местами не сахар). Так что, при сборке под Win зависимость тут будет лишь чей рантайм брать: майкрософтовский или MinGW.
MD>Но если Eclipse для Вас как IDE явно совершенней, чем VC, то я не знаю даже, к чему апеллировать. Видимо, это всё вкусовщина, или разные цели преследуем Кто-то ведь и в vim кодит...
Начнем с того, что Eclipse нормально разбирает современный С++, чего студия делать не умеет. Уже одного этого достаточно, что бы студию даже не рассматривать в качестве серьёзного соперника.
А насчет вкусовщины, ну извините, если мне редактор Eclipse кажется лучше сделан с точки зрения дизайна и удобства работы, то да, вкусовщина. Работаю я на нем. Каждый день.
Здравствуйте, _Butch_, Вы писали:
_B_>Здравствуйте, flаt, Вы писали:
F>>Детальнее в статье: http://www.bfilipek.com/2014/12/c-status-at-end-of-2014.html
F>>Image: cpp14conf.png
_B_>Как получается, что GCC, который пишут безработные студенты, поддерживает стандарт лучше, чем MSVC, который пишут хорошо оплачиваемые профессионалы?
Помимо процентиков поддержки стандарта есть еще
— Качество реализации (качество генерируемого кода, количество багов в компиляторе)
— Время компиляции (скорость работы компилятора)
— Память, потребляемая компилятором в процессе работы
Если сравнить gcc и MSVC по всем критериям, все будет совсем не так плохо. Сразу выяснится, что gcc дико медленный и часто генерирует код, хуже, чем MSVC.
Пользователям гораздо важнее это, а не 100% на поддержке фич С++
Здравствуйте, tlp, Вы писали:
tlp>Если сравнить gcc и MSVC по всем критериям, все будет совсем не так плохо. Сразу выяснится, что gcc дико медленный и часто генерирует код, хуже, чем MSVC.
После таких громких слов неплохо бы и ссылочку привести, в подтверждение
Здравствуйте, Шахтер, Вы писали:
Ш>Начнем с того, что Eclipse нормально разбирает современный С++, чего студия делать не умеет. Уже одного этого достаточно, что бы студию даже не рассматривать в качестве серьёзного соперника.
Сниппет дайте тогда, пожалуйста. Чтобы Студия его "не разбирала", и Эклипс (точнее, CDT) — "разбирал". Заметьте, я не говорю про "компилировать" — это решается вкручиванием нужного тулчейна в обоих IDE.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, tlp, Вы писали:
tlp>>Если сравнить gcc и MSVC по всем критериям, все будет совсем не так плохо. Сразу выяснится, что gcc дико медленный и часто генерирует код, хуже, чем MSVC.
J>После таких громких слов неплохо бы и ссылочку привести, в подтверждение
Вот компилирую sciter release: sciter64.dll / sciter-osx-64.dylib / sciter-gtk-64.so
на соизмеримых машинах (CPU/SSD) и соизмеримыми настройками.
ты, по всей видимости, пишешь код для того чтоб его компилировать, в то время, как большинство изветных мне кодеров, пишут код чтоб юзать результирующий бинарь.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, tlp, Вы писали:
tlp>>Если сравнить gcc и MSVC по всем критериям, все будет совсем не так плохо. Сразу выяснится, что gcc дико медленный и часто генерирует код, хуже, чем MSVC.
J>После таких громких слов неплохо бы и ссылочку привести, в подтверждение
думается мне, что кроме тебя и c-smile, время компиляции больше никого не интересует, и, я почти уверен, что jazzer просил ссылочку на подтверждение плохой кодогенерации
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, tlp, Вы писали:
X>думается мне, что кроме тебя и c-smile, время компиляции больше никого не интересует,
Думайте дальше.
>и, я почти уверен, что jazzer просил ссылочку на подтверждение плохой кодогенерации
Телепаты на форуме!
Здравствуйте, niXman, Вы писали:
X>думается мне, что кроме тебя и c-smile, время компиляции больше никого не интересует,
Меня интересует...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, c-smile, Вы писали:
CS>Вот компилирую sciter release: sciter64.dll / sciter-osx-64.dylib / sciter-gtk-64.so CS>на соизмеримых машинах (CPU/SSD) и соизмеримыми настройками.
честно говоря, студия "химичит" при компиляции. и уже достаточно давно (как минимум с 2008й). дело в том, что порождение процесса под виндой — дорогая операция и студия использует свой интерфейс, чтобы не порождать cl.exe на каждый *.cpp. отсюда и выигрыш. поэтому как-то неправильно будет сравнивать гцц и мсвц. сравнивай тогда уж гцц и мсвц без их "переходника".
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Erop, Вы писали:
E>Меня интересует...
почему так получается? ты работаешь в отделе тестирования? или дистры какие-то собираешь? откуда надобность постоянно компилить код?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, Vain, Вы писали:
V>честно говоря, студия "химичит" при компиляции. и уже достаточно давно (как минимум с 2008й). дело в том, что порождение процесса под виндой — дорогая операция и студия использует свой интерфейс, чтобы не порождать cl.exe на каждый *.cpp. отсюда и выигрыш. поэтому как-то неправильно будет сравнивать гцц и мсвц. сравнивай тогда уж гцц и мсвц без их "переходника".
там неправильно гораздо больше, а точнее — все.
во-первых — разные ОСи.
во-вторых — разные компиляторы.
в-третьих — разные системные библиотеки+ГУИ.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>почему так получается? ты работаешь в отделе тестирования? или дистры какие-то собираешь? откуда надобность постоянно компилить код?
Ну кодишь, копилишь, запускаешь, пока работает, кодишь компилишь дальше....
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Ну кодишь, копилишь, запускаешь, пока работает, кодишь компилишь дальше....
а отвлекаться на "компилишь — не компилится — фиксишь, запускаешь — бажет — фиксишь — компилишь" — времени не жалко? наверное приличный процент времени уходит на это?
я вот "компилю — не компилится — фикшу — снова компилю, запускаю — тестирую — бажет — фикщу — снова компилю" — по определенным стадиям, если проект в разработке. если проект в стадии этапного тестирования — стратегия немного другая.
дело в том, что, как я заметил по себе(но есть и еще люди, которые работают по такому же принципу), если стадия разработки — то компиляция и тестирование на этой стадии только отвлекает, и суммарно получаются большие затраты времени, плюс "вылет и головы" контекста мыслей необходимых для реализации конкретной задачи. просто подумай, и, возможно захочешь попробовать
по поводу же времени компиляции — зачем же перекомпилировать весь проект? если речь идет о частой компиляции, то, могу предположить, что ты находишься в стадии фиксинга, и, таким образом, врядли фикс затрагивает бОльшую часть проекта. обычно, в компиляции нуждается несколько единиц трансляции. допустим, на компиляцию единици трансляции требуется ~10 сек(должна быть большая единица ), а у нас есть минимум четыре ядра. по своему опыту скажу, что если проект написан не в стиле "main.cpp + все в хидерах", то тут довольно высока вероятность того, что фикс не затронет больше четырех единици трансляции.
но это я сужу по себе, ибо стараюсь по возможности все выносить в '.cpp'.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
V>>честно говоря, студия "химичит" при компиляции. и уже достаточно давно (как минимум с 2008й). дело в том, что порождение процесса под виндой — дорогая операция и студия использует свой интерфейс, чтобы не порождать cl.exe на каждый *.cpp. отсюда и выигрыш. поэтому как-то неправильно будет сравнивать гцц и мсвц. сравнивай тогда уж гцц и мсвц без их "переходника". X>там неправильно гораздо больше, а точнее — все. X>во-первых — разные ОСи. X>во-вторых — разные компиляторы. X>в-третьих — разные системные библиотеки+ГУИ.
но если и так, непонятно почему ты считаешь меньшее время компиляции не достоинством мсвц/недостатком остальных.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, Vain, Вы писали:
V>но если и так, непонятно почему ты считаешь меньшее время компиляции не достоинством мсвц/недостатком остальных.
я не говорил что это не достоинство. я не считаю это хоть сколь-нибудь значимым, и, тем более, я не считаю что кто-нибудь станет выбирать компилятор по наименьшему времени компиляции.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>я не говорил что это не достоинство. я не считаю это хоть сколь-нибудь значимым, и, тем более, я не считаю что кто-нибудь станет выбирать компилятор по наименьшему времени компиляции.
Разрабатывать-то можно используя один компилятор, а собирать результат "для продакшена" (ну и тестирования) другим. При прочих равных, разумеется.
Да, переключение на отладку и компиляцию часто "выбивает из контекста", но имхо, как раз из-за времени компиляции. Было бы это мгновенно (в идеале), не было бы проблем. Опять же, рефакторить (а при этим и интерфейс в хедерах может затрагиваться) удобнее периодически пересобирая и прогоняя тесты.
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, Erop, Вы писали:
E>>Ну кодишь, копилишь, запускаешь, пока работает, кодишь компилишь дальше.... X>а отвлекаться на "компилишь — не компилится — фиксишь, запускаешь — бажет — фиксишь — компилишь" — времени не жалко? наверное приличный процент времени уходит на это? X>я вот "компилю — не компилится — фикшу — снова компилю, запускаю — тестирую — бажет — фикщу — снова компилю" — по определенным стадиям, если проект в разработке. если проект в стадии этапного тестирования — стратегия немного другая.
"Есть разное, Горацио, на свете..."
Скажем бага в event driven code — "если пойти туда, сделать так, подождать, и пойти вот сюда, то будет всё плохо".
Приходится городить цепочки тригерров по ходу чтобы поймать момент. Хорошо если в *.cpp только, а если в *.h — туши свет.
На самом деле линуксоидам надо скинуться и поставить памятник Visual Studio. Много приличных проектов делаются в VS, а потом уже портируются в GCC.
Ибо среды разработки в Linux на "отвяжись". Про debugging я вообще промолчу.
На самом деле если кто-то всерьез захочет сделать из linux платформу то должен озаботится нормальной IDE. MS и Apple это давно поняли.
Особенно MS. Сколько кода было на Visual Basic 4-6 написано... горы. Просто потому что IDE (редактор, менеджер проектов и отладчик) удобная была.
Здравствуйте, tlp, Вы писали:
>>и, я почти уверен, что jazzer просил ссылочку на подтверждение плохой кодогенерации tlp>Телепаты на форуме!
Ну он отчасти прав: твое исходное заявление содержало два утверждения — про скорость (ссылку ты привел) и про кодогенерацию.
ЗЫ У меня тут интерес чисто теоретический, так как я разрабатываю исключительно на линуксе и последний раз с MSVC имел дело в прошлом веке (не считая пары поделок для почившей WinCE|PocketPC).
Здравствуйте, niXman, Вы писали:
X>думается мне, что кроме тебя и c-smile, время компиляции больше никого не интересует, и, я почти уверен, что jazzer просил ссылочку на подтверждение плохой кодогенерации
Мне кажется все в точности наоборот. Скорость компиляции = удобство и скорость разработки. Впрочем, я встречал людей, которым пофиг на скорость было — они в это время могли чаек попить и помедитировать
Здравствуйте, DarkEld3r, Вы писали:
DE>Разрабатывать-то можно используя один компилятор, а собирать результат "для продакшена" (ну и тестирования) другим. При прочих равных, разумеется.
а смысл?
DE>Да, переключение на отладку и компиляцию часто "выбивает из контекста", но имхо, как раз из-за времени компиляции.
не из-за отладки, не?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, c-smile, Вы писали:
CS>На самом деле линуксоидам надо скинуться и поставить памятник Visual Studio.
ты знаешь, я вообще слабо представляю для чего нужна вендус. последний раз я для нее кодил лет 8-9 назад.
а так, использую исключительно для сборок MinGW, ну и в игрушку погамать, иногда... еще, знаю, что некоторые используют MS Office. на этом все...
хз, за что памятник, и за что Visual Studio..
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, DiZSl, Вы писали:
DZS>Мне кажется все в точности наоборот. Скорость компиляции = удобство и скорость разработки.
а вы постоянно компилируете код, после реализации пары-тройки выражений?
DZS>Впрочем, я встречал людей, которым пофиг на скорость было — они в это время могли чаек попить и помедитировать
а мне приходилось работать с людьми, которые по несколько раз в день пересобирали проект находясь в стадии разработки...
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>а смысл?
Скорость, опять же.
X>не из-за отладки, не?
Могу говорить только о личном опыте. Если от написания кода до старта отладки проходит немного времени (и сама проблема не оказывается запутанной), то контекст особо не теряется. Опять же, часто хочется просто прогнать некоторые тесты, чтобы убедиться, что ничего не отломал.
По моему, стиль разработки, в немалой степени, диктуют условия (ну и привычки). Скажем, если у тебя есть РЕПЛ, то проверять отдельные кусочки кода вполне удобно и естественно.
Здравствуйте, niXman, Вы писали:
X>ты знаешь, я вообще слабо представляю для чего нужна вендус. последний раз я для нее кодил лет 8-9 назад.
Не замечаешь подвоха? Понятное дело, что если не попробовать толком, то сложно оценить преимущества. Сейчас использую Qt Creator под маком, если что. Тем не менее "студия" кажется удобнее.
Здравствуйте, DarkEld3r, Вы писали:
DE>Не замечаешь подвоха?
подвоха? — нет. но замечаю объяснение того, что некоторым людям вообще не понятен смысл существования венды.
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DiZSl, Вы писали:
DZS>>Мне кажется все в точности наоборот. Скорость компиляции = удобство и скорость разработки. X>а вы постоянно компилируете код, после реализации пары-тройки выражений?
Когда как, но при интенсивной разработке, такой режим работы — норма
DZS>>Впрочем, я встречал людей, которым пофиг на скорость было — они в это время могли чаек попить и помедитировать X>а мне приходилось работать с людьми, которые по несколько раз в день пересобирали проект находясь в стадии разработки...
Это лишь говорит о том, что вы судите по себе
Здравствуйте, DiZSl, Вы писали:
DZS>Это лишь говорит о том, что вы судите по себе
а это не говорит?: DZS>Когда как, но при интенсивной разработке, такой режим работы — норма
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
X>Здравствуйте, DiZSl, Вы писали:
DZS>>Это лишь говорит о том, что вы судите по себе X>а это не говорит?: DZS>>Когда как, но при интенсивной разработке, такой режим работы — норма
Я сразу же оговорился, что допускаю, что кому-то важно кому-то нет. Вы же писали: >>думается мне, что кроме тебя и c-smile, время компиляции больше никого не интересует
Кроме того, могу сказать, что 15 лет назад, когда я учился в универе абсолютно все работали в таком же режиме —
минута кодинга (как правило этого хватало — компиляция, параллельно обдумывание, далее кодинг — компиляция...
П.С. хотя нашему преподу это очень не нравилось, — "надо сначала спроектировать, написать, потом компилировать" — на практике такой метод в разы более медленный по разработке
Здравствуйте, DiZSl, Вы писали:
DZS>Кроме того, могу сказать, что 15 лет назад, когда я учился в универе абсолютно все работали в таком же режиме — DZS>минута кодинга (как правило этого хватало — компиляция, параллельно обдумывание, далее кодинг — компиляция...
разве это нормально?
есть хоть одна рациональная причина делать это? (ну, кроме, помаяться дурью)
DZS>... на практике такой метод в разы более медленный по разработке
ну вот, снова только слова.
есть хоть какое-то обоснование постоянно компилировать код?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
Здравствуйте, niXman, Вы писали:
DZS>>Кроме того, могу сказать, что 15 лет назад, когда я учился в универе абсолютно все работали в таком же режиме — DZS>>минута кодинга (как правило этого хватало — компиляция, параллельно обдумывание, далее кодинг — компиляция... X>разве это нормально? X>есть хоть одна рациональная причина делать это? (ну, кроме, помаяться дурью)
ну смотри — к примеру есть проект и тесты. Если компиляция и прогон тестов занимает пару секунд — то внес изменения — прогнал, внес — прогнал. Это быстрее, чем поменять 10 мест, а потом выяснять, на каком из них стрельнул тест...
Если компиляция и прогон занимает несколько (десятков) минут — то тут уже надо смотреть
E>>Ну кодишь, копилишь, запускаешь, пока работает, кодишь компилишь дальше.... X>а отвлекаться на "компилишь — не компилится — фиксишь, запускаешь — бажет — фиксишь — компилишь" — времени не жалко? наверное приличный процент времени уходит на это? X>я вот "компилю — не компилится — фикшу — снова компилю, запускаю — тестирую — бажет — фикщу — снова компилю" — по определенным стадиям, если проект в разработке. если проект в стадии этапного тестирования — стратегия немного другая.
X>дело в том, что, как я заметил по себе(но есть и еще люди, которые работают по такому же принципу), если стадия разработки — то компиляция и тестирование на этой стадии только отвлекает, и суммарно получаются большие затраты времени, плюс "вылет и головы" контекста мыслей необходимых для реализации конкретной задачи. просто подумай, и, возможно захочешь попробовать
X>по поводу же времени компиляции — зачем же перекомпилировать весь проект? если речь идет о частой компиляции, то, могу предположить, что ты находишься в стадии фиксинга, и, таким образом, врядли фикс затрагивает бОльшую часть проекта. обычно, в компиляции нуждается несколько единиц трансляции. допустим, на компиляцию единици трансляции требуется ~10 сек(должна быть большая единица ), а у нас есть минимум четыре ядра. по своему опыту скажу, что если проект написан не в стиле "main.cpp + все в хидерах", то тут довольно высока вероятность того, что фикс не затронет больше четырех единици трансляции.
Важно не то, как часто ты отвлекаешься на компиляцию и тесты, а то, сколько времени проходит между созданием баги в коде и ее обнаружением. Если ты поправил где-то код и внес ошибку, но при этом сразу это обнаружил — контекст все еще у тебя в голове и ты можешь быстро и не напрягаясь ее поправить. Если после внесения ошибки ты успел переключиться на другую задачу и, например, отредактировать код в другом файле, а уже потом обнаружил ошибку — исправление ошибки потребует больше времени и больших ментальных усилий. Лично я наиболее продуктивно пишу код на питоне с использованием autonose. Это такая тулза, которая запускает тесты тогда, когда ты сохраняешь исходник. Я открывал редактор на одном мониторе а консоль с autonose на другом и сразу видел что что-то сломалось и мог это быстро исправить. Правда чтобы это работало нужен хороший coverage. С плюсами не остается ничего другого, кроме как часто компилировать и запускать тесты.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, tlp, Вы писали:
tlp>>Если сравнить gcc и MSVC по всем критериям, все будет совсем не так плохо. Сразу выяснится, что gcc дико медленный и часто генерирует код, хуже, чем MSVC.
J>После таких громких слов неплохо бы и ссылочку привести, в подтверждение
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) Мне кажется, это что-то говорит о качестве оптимизации и написания std у микрософта — он отлично соптимизировал явно не оптимальный код.
Скорость компиляции имеет значения когда компилишь что-то большое типа qt, boost, etc. Есть разница, компилишь ты что-то сутки или 6 часов.)
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.)
какая версия MSVC, какая архитектура?
пачка бумаги А4 стОит 2000 р, в ней 500 листов. получается, лист обычной бумаги стОит дороже имперского рубля =)
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) X>какая версия MSVC, какая архитектура?
Мне кажется, Вы слишком эмоционално реагируете на сравнение разных компиляторов, у всех есть свои плюсы и минусы, компилятор без плюсов перестал бы существовать очень быстро, несмотря на любую поддержку любой корпорации.) Оптимизация, насколько я знаю, традиционно считалась сильной стороной микрософтовского компилятора, именно за это ему прощают ограниченную поддержку стандарта.
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) Мне кажется, это что-то говорит о качестве оптимизации и написания std у микрософта — он отлично соптимизировал явно не оптимальный код.
Стоп-стоп. А вариант скомпилированный gcc ты на своём компьютере запускал? Иначе мне не понятно, почему из двух версий, что оптимизатор msvc хороший или плохой, так однозначно выбирается первая. Может выравнивание времени работы функций говорит как раз об обратном — оптимизатор msvc настолько плох, что сумел испортить даже уже оптимизированную функцию А похожесть времён просто объясняется, что процессор у nixman медленнее, а у тебя быстрее.
Ну то есть я допускаю, что на этом коде один из компилятором может выдавать результат лучше другого, но нельзя решить какой из них лучше, если запустить на одной машине gcc, а на другой непохожей машине msvc, и потом сравнивать времена работы.
А также не могу не заметить, что приведённый тест неоднозначен (а соответственно плох в разрешении споров) ещё и по следующей причине: в нём замеряется время обработки строки из трёх (!) символов в цикле из десяти миллионов итераций. Что это означает? А то, что (если STL не использует SSO) огромное число времени код занимается не столько обработкой строк, сколько прыжками в crt и обратно для выделения и разрушения буфера под эту крошечную строку. То есть в этом тесте не только приведённый код меряется, но ещё и скорость работы crt на машине. А crt, например, вообще может быть всё равно каким компилятором собрана программа — сам crt собран давно и на него не влияют ни настройки оптимизации, ни выбор компилятора. Это такой же случайный фактор как и частота работы процессора.
В общем, если хотите сравнивать скорость работы программ, то сравнивайте правильно: на одной машине, в одном окружении, с одной версией crt, либо тестируйте код, который от crt зависит минимально (а не вызывает malloc на обработку каждых трёх символов). А сейчас — это не сравнение компиляторов.
У Вас нет ощущения, что Вы до столба докапываетесь?) Если посмотреть на код, то кажется довольно вероятным, что компилятор именно мой код соптимизировал, а не ухудшил код nixman'а, рантайм — это часть компилятора, и я не хотел сравнивать компиляторы, я просто поделился недавно случившимся со мной случаем, желающие могут провести полноценное исследование и поделиться результатами с нами.)
nixman сравнивает скорость выполнения разных кусков кода, у него на гсс скорость куска jahr в 3 раза меньше, чем nixman. Я попробовал запустить этот код в vc2013 — скорость jahr получилась почти такая же, как и nixman,в полтора раза больше, а не в три, как в гсс.) Мне кажется, это что-то говорит о качестве оптимизации и написания std у микрософта — он отлично соптимизировал явно не оптимальный код.
или nixman стал вдвое медленнее в vc2013
(они прознали, что он собирает gcc, и добавили его в черный список )
Имхо, в этом тесте гораздо большее значение имеет качество std, чем оптимизатора.
Я вот никак не могу добиться от gcc std той же скорости, которую я имел с stlport.
J>Скорость компиляции имеет значения когда компилишь что-то большое типа qt, boost, etc. Есть разница, компилишь ты что-то сутки или 6 часов.)
Это ты не мне писал, наверное
Здравствуйте, fdn721, Вы писали:
F>Писать можно по разному. Вот например тот же std::async в gcc просто тупо каждый раз заводит новый поток со всеми накладными расходами, а msvc использует пул потоков. F>100% поддержка стандарта любой ценой это как раз цель для студентов. А сделать нормальную годную реализацию, чтоб она не тормозила и не принесла в будущем кучу проблем требует времени и денег.
Интересно, в VS 2015 исправили эпичный std::call_once, который использовал единственный глобальный мьютекс на все приложение? В 2013 еще так.
Кто-то ведь и в vim кодит...
)
