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

это можно было бы и внутри компилятора разруливать, кэшированием, к примеру

Уже разруливают: http://www.zapcc.com/

не умеешь - или не лезь, или учись.

Читая такие вещи возникает непреодолимое желание сказать подобным лыцарям в сияющих доспехах: «Сударь, засуньте свой частный опыт, каким бы большим и суровым вы его не считали, себе в жопу и не пытайтесь его натягивать на всю индустрию».

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

Зачем ездить на машинах, если у всех куча опыта с лошадьми и вообще, в машинах нету необходимости - и на лошади все успевают?

Почитала бы обсуждение комитета по теме, что ли.

ccache ускоряет последующие компиляции одного и того же кода, это не то

Тогда и data race это лишь полезный тул. Фактически же, зависимость от порядка инклудов это и есть классическая гонка данных.

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

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

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

ты с коня то слезь, прежде чем наставления автолюбителям выписывать

да и посрать на них, если честно.

А почему бы не посрать на того, кто не трудится начинать в своем тексте предложения с прописной буквы? Вы демонстрируете, что на русском языке пишете абы как. И пытаетесь утверждать, что освоили C++? С чего бы вдруг? Только из-за того, что вы о себе, таком великом и ужасном, рассказываете на LOR-е?

Уже несколько раз вам об этом говорил, повторю еще раз: отучитесь говорить за всех. Вы обходитесь каким-то подмножеством C++ в какой-то узкой нише. Вот и обходитесь.

После C++03 язык развился очень и очень сильно. Писать на нем сейчас гораздо проще, чем 10 лет назад. Поэтому пускай развивается. И если модули способны сделать C++ еще удобнее, то пусть будут.

о себе, таком великом и ужасном

Это она, корректности ради.

После C++03 язык развился очень и очень сильно. Писать на нем сейчас гораздо проще, чем 10 лет назад.

и это плохо, набежали неосиляторы )

Неосиляторы с него массово сбежали на Java еще до выхода C++03. Остатки неосиляторов убежали потом на C#.

Если сейчас и есть приток новых людей в C++, то он еще не такой большой, имхо.

Так что речь, скорее, идет о тех отщепенцах, которые 20 лет пишут на C++ и при этом хотят расширять и углублять старый-добрый «C with classes» :)

Аналогии такие аналогии

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

Вот такую чушь ты несешь, тетя. Но ты продолжай, нам всем очень интересен твой опыт промышленного программирования.

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

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

Есть нормы языка, на которые вы позволяете себе плевать с высокой колокольни. В любом языке программирования так же есть свои нормы. Однако, если вы так поступаете с нормами русского языка, то как можно быть уверенными, что вы не нарушаете нормы, например, в C++?

не люблю излишества и бантики.

В связи с этим интересно, добавленные в C++11 и C++14 фичи вы считаете излишествами и бантиками?

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

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

Да у этого механизма вагон проблем и лес из костылей для их обхода, а плюшек не так уж и много. Хотя, как по мне, то самое лучшее, что могли бы сейчас в плюсы включить, так это пользовательские атрибуты и compile-time рефлексию. Короче говоря всё, чтобы можно было Qt moc реализовать средствами самого языка.

«а у меня слишком долго компилится» - это пустое

Ага, конечно.

Поменьше пафоса про опыт. Ну и хорошо, что в комитете сидят люди с не настолько заплесневелыми мозгами.

Ну что меня особенно удивляет - при чём тут «развивают язык в угоду школоте»? Что конкретно станет хуже от этих изменений? Ведь все только выиграют. Откуда возьмётся несовместимость?

модули будут ещё больше поощрять говнокод

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

без модулей возможно писать всё, что возможно вообще писать.

Как и без кучи других фич языка. Но почему-то отказываться от них не хочется.

Ну и откуда ты берёшь то, что у тебя заберут «старые добрые» инклюды? Нравится - продолжай использовать.

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

и это плохо, набежали неосиляторы )

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

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

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

А ещё тем насколько сложно разработчиков найти.

если не использовать всяку каку, которую уже натащили для неосиляторов

И ты, разумеется, расскажешь что именно из новых фич и насколько замедляют язык. Начни с модулей.

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

насчёт разработчиков - на плюсах их много и не требуется.

Ну-ну. У меня несколько другая статистика.

но памфлеты писать не люблю.

Оно и видно.

не того уровня софт

И какого же рода софт, по вашему мнению, разрабатывается на C++? Ну или должен был бы разрабатываться в идеальном мире?

ну а всякую шелупонь десктопную

Современные браузеры вроде Firefox и Chrome, а так же текстовые процессоры вроде MS Word-а или OpenOffice — это шелупонь, где не нужна ни производительность, ни надежность?

я не буду писать про новые фичи, которые недостаточно эффективны

Ну хотя бы названия можно перечислить? В C++11/14 не так уж и много кардинально новых фич добавилось: variadic templates, rvalue references, lambdas, noexcept... Это все плохо?

В качестве оффтопика: ты уверен, что отвечал именно Iron_Bug?

Упс... Приношу всем свои извинения. Вопрос адресовался Iron_Bug :(

Это баг ЛОР. Не первый раз замечаю такое.

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

он минималистичен
C++
минималистичен

Ты обкурился? C++? Минималистичен? Это C минималистичен, а C++ - это сбежавший из Припяти мутант-годзилла, больной элефантиазом трёхглавый монстр с шестью ногами и двумя хвостами, это несмешной и жуткий вариант котопса IRL.

излишества и бантики
правописание

Да пиши уж даниллицей тогда, без пробелов, чего уж там, кто хочет - разберется.

что вы не нарушаете нормы, например, в C++?

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

не того уровня софт

Что правда, то правда - только истинные крестоносцы могут написать therac25-like софт.

всякую шелупонь десктопную, где не надо ни скорости, ни надёжности

Эк ты Natural Language Processing обозвал, где в основном ява юзается, за редкими исключениями.

Однако, если вы так поступаете с нормами русского языка, то как можно быть уверенными, что вы не нарушаете нормы, например, в C++?

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

Что правда, то правда - только истинные крестоносцы могут написать therac25-like софт.

неправда, это на любом языке можно :)

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

Ну так а где альтернативы на других языках/технологиях? Нету их :) А Mozilla, OpenOffice и Chrome такие некрасивые внутри вовсе не от того, что их неосиляторы пишут. Большие задачи, большие реализации. В таких условиях красоты внутри быть не может. Такова жизнь. Причем вне зависимости от языка. Просто есть языки, которые дают разработчикам некоторую подушку безопасности, но заставляют за это платить потреблением ресурсов.

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

Вот это поворот! Т.е. сначала были жалобы, что в новые версии плюсов тянут что ни попадя. А теперь оказывается, что новые фичи на уровне компилятора — это не есть плохо.

но школота их точно не знает и не использует. я не представляю себе школоту, ликующую при виде variadic templates.

А зачем ей ликовать? Новички просто берут и пишут в одну строку perferct-forwarding в купе с move semantic. И им не нужно знать, каких трудов это стоило в прошлом и как приходилось долбаться без variadic templates.

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

«Имя, сестра, имя!» (с)

Из нового пока довелось столкнуться с не шибко быстрой работой std::regex. У вас к чему претензии есть? Хотя бы на уровне названий классов?

В отличии от С++

Да ладно, там половина «стандарта» - undefined behavior.

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

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

Ну это уже проблемы реализации, к тому же, вполне вероятно, что тестилось все только на libstdc++. Тут вот ворчат на итераторы, что они оказались непригодными для бесконечных последовательностей. Это уже посерьезнее проблема.

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

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

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

Ну ё-моё, детский сад, младшая ясельная группа.

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

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

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

Феерично. Это как говорить о том, что ООП (в виде одиночного наследования) вполне существует в C. Практически всего можно достичь путем агрегирования структур и указателей на функции.

Только вот если сравнить объем писанины даже для простых случаев реализации наследников в C и C++, то сразу становится понятно, в каком языке ООП есть, а в каком нет. И насколько это влияет на то, как программируют на конкретном языке.

Так же и с лямбдами. Тот ужас, который нужно было вручную городить на std::unary_function/binary_function, не идет ни в какое сравнение с поддержанными на уровне языка лямбдами в C++11/14. И соответственно, применимость, частота использования и последствия, которые из этого проистекают, так же сильно разные.

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

А как там с вероятностью появления модулей в новом стандарте? Я, как типичный школохипстер (растом же интересуется. наркоман еще, наверное), очень был бы им рад.

Пролистал тему. От сообщений Iron_Bug у меня в голове что-то громко лопнуло. Хоспади, надеюсь что людей, которые не считают заголовочные файлы диким уродским костылем, мало.

А как там с вероятностью появления модулей в новом стандарте?

AFAIK, пока минимальная.

https://botondballo.wordpress.com/2015/06/05/trip-report-c-standards-meeting-...

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

Вот здесь подробнее про разные подходы к организации модулей: http://developerblog.redhat.com/2015/06/10/lenexa-c-meeting-report-core-langu...

Хм, печально как-то. Спасибо за ссылки.