LINUX.ORG.RU

Ответ на: комментарий от KennyMinigun

Ну и хорошего мало. Просто вот это вот смутило:

Ищу пруфлинки

Мне в rss прилетело и ни чего искать не надо.

mandala ★★★★★
()
Ответ на: комментарий от BceM_IIpuBeT

Да, одна из главных вкусностей. По крайней мере до меня.

zamazan4ik ★★
()

Какой же угребищный UI у этого вашего фейсбука.

Im_not_a_robot ★★★★★
()
Ответ на: комментарий от Crocodoom

Добавлены дополнительные математические функции, включая эллиптические интегралы и функции Бесселя

Даже неожиданно.

grem ★★★★★
()
Ответ на: комментарий от KennyMinigun

Да. Вон clang 5 релизнулся, там даже корутины завезли.

zamazan4ik ★★
()
Ответ на: комментарий от zamazan4ik

Есть подозрение, что модули и концепты картину сильно не изменят.

К тому же модули, если они будут недостаточно хорошо дружить с макросами, могут оказаться мертворожденными и не будут применяться в более-менее сложных, больших и кроссплатформенных проектах :(

eao197 ★★★★★
()
Ответ на: комментарий от zamazan4ik

по крайней мере быстро

Не надо быстро... :)

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

BRE ★★
()
Ответ на: комментарий от eao197

Концепты призваны убрать тонны enable_if, это полезно.

Модули - я верю в них. Ускорение компиляции и много других вещей.

Моё мнение, что это поможет языку стать лучше.

zamazan4ik ★★
()
Ответ на: комментарий от zamazan4ik

Моё мнение, что это поможет языку стать лучше.

Поможет. Речь о том, что принципиально картину не изменит. Вот rvalue references, move semantic, lambda, variadic templates картину изменили принципиально. По поводу концептов все не так однозначно.

Модули - я верю в них. Ускорение компиляции и много других вещей.

А есть предпосылки к заметному ускорению? Как-то на reddit-е были сообщения о том, что народ пробовал использовать VC++ с поддержкой модулей на более-менее реальных кодовых базах и особого выигрыша не было.

Вот если модули совместят с чем-то вроде Cargo/Maven/RubyGems/Cabal, тогда да, тогда ситуация может поменяться принципиально.

eao197 ★★★★★
()
Последнее исправление: eao197 (всего исправлений: 1)

я чот проспал новости про стандарт. Модули не завезли? По старинке дрочить на инклуды в 2017?

anonymous
()
Ответ на: комментарий от eao197

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

zamazan4ik ★★
()
Ответ на: комментарий от zamazan4ik

Со временем мы добьёмся более высокой скорости компиляции.

Интересно, за счет чего?

Вот, скажем, при использовании Catch легко обнаружить, что фаза лексического и синтаксического анализа проходит очень быстро. Т.е. даже обработка кучи #include на современной технике — это не проблема. А вот дальше компилятор замирает достаточно надолго. Тут уже нет никакого парсинга, только раскручивание шаблонов и оптимизация.

Чем здесь смогут помочь модули?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

Тем, что инклуды компилируются в каждом cpp файле. И precompiled headers не всегда спасают. Модули же компилируются ровно один раз. То есть у нас сложность падает от O(N*M) до O(N+M), где n и m - количество единиц трансляции и инклудов/модулей соответственно.

zamazan4ik ★★
()
Ответ на: комментарий от zamazan4ik

Всё равно это просто формальность. Уже можно юзать спокойно C++17, если компилятор позволяет

Лол :-) Ну заинклюдь спокойно <filesystem> без «experimental» в последнем GCC 7.2, сказочник :-)

anonymous
()
Ответ на: комментарий от zamazan4ik

Тем, что инклуды компилируются в каждом cpp файле.

Так я же вам пример привел. Catch для unit-тестов. В exe-шник компилируется, как правило, всего один cpp-файл. Так вот .cpp-файл может компилироваться 3-4-5 и более секунд. При этом фаза обработки include-ов занимает не более секунды (это видно, если где-то в unit-тесте или в своих заголовочных файлах допускаешь ошибку). Все остальное время — это инстанциирование шаблонов и оптимизация кода.

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

eao197 ★★★★★
()
Ответ на: комментарий от anonymous

Прочитать про «компилятор позволяет» не судьба. У меня на компе gcc 6.3. надо проверить на clang 5, который вчера релизнулся.

zamazan4ik ★★
()
Ответ на: комментарий от zamazan4ik

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

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

Языку поможет стать лучше поддержка метаклассов :-) Правда, в Лиспе они были уже лет 25 как, но и в цепепе скоро появятся :-) Вот это будет уже немного более интересно :-) Надо только подождать несколько лет, и надеяться на великих гуру цепепе, чтобы они сделали метапрограммирование в цепепе не таким ущербным, как сейчас :-)

anonymous
()

Ну вот, буквально на прошлой неделе пришла с амазона книжка Мейерса про 11/14, а тут уже и 17 выполз. ~_~

yoghurt ★★★★★
()
Ответ на: комментарий от zamazan4ik

Так вроде бы есть только одна реализация в VC++, которая соответствует тем предложениям по модулям, которые двигает MS (т.е. без поддержки макросов). Деталей реализации не знаю, но вроде как там в результате трансляции модуля какой-то промежуточный файл получается, который затем используется при компиляции всех последующих модулей, импортирующих данный модуль.

eao197 ★★★★★
()
Ответ на: комментарий от Crocodoom

нет. фортран был (и до сих пор есть) шустрый, как понос. а плюсы становятся всё жирнее и тормознее. тенденция нехорошая. тащат всякую каку в стандарт.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Harald

да там ничего полезного особо и нет. пожалуй, единственное, что в 11 плюсах было прямо реально полезное - это variadic templates. остальное - чисто синтаксический сахар и нафиг не нужные мелкие перделки.

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

а плюсы становятся всё жирнее и тормознее. тенденция нехорошая. тащат всякую каку в стандарт.

Сейчас тебе будут рассказывать пургу, что это «насущная необходимость, обусловленная требованиями к сложности современного программного обеспечения» :-) И что без этого никак :-) Правда, о том, что для разных прикладных областей имеется десяток других, более высокоуровневых и подходящих языков, упомянуть забудут (разве что скажут, что все они отстой и тормоза) :-) Лол :-)

anonymous
()
Ответ на: комментарий от zamazan4ik

Модули - я верю в них. Ускорение компиляции и много других вещей.

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от anonymous

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от Iron_Bug

остальное - чисто синтаксический сахар и нафиг не нужные мелкие перделки.

А как же теперь без смарт-поинтеров и auto? :-) Как без лябмд? :-) Как теперь писать без move или forward? :-) А без SFINAE кто теперь уже обходится? :-) Нет, сейчас всё стало намного проще :-)

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.