Кто-то уже пользуется модулями?

ааа, зачем они это в мой С++ тащат

ааа, зачем они это в мой С++ тащат

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

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

Что-то ничего не упоминается тут

http://clang.llvm.org/cxx_status.html

костыли-костылики

Бог цой, они переизобретают QtQuick/QML.

Осталось им Js всторить.

Был опыт, потратил немало времени на добавление модулей в крупный проект только чтобы отказаться от этой затеи в итоге. Там слишком много условий для того, чтобы модули работали «правильно». Т.е. для простых (в смысле организации заголовков) вещей оно работать будет, но шаг в лево шаг в право и начинаются: снесите кеш руками, модуль A использует time_t объявленное в модуле B (тут A и B модули проекта, которые заглатывают лишние типы), там что-то конфликтует, там циклические зависимости с цепочкой длиной в 5 модулей поэтому идите лесом, ошибки при компиляции там ещё мозговыносящие (указывают не туда), даже хоже было когда что-то было outdated но вроде работало, а после удаление кеша переставало (наоборот аналогично)...

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

В C++17 модули вроде под сомнением, в таком виде оно действительно только хуже сделает, надо совершенствовать подход.

Какой QtQuick/QML/js ? Там парсер — урезанный парсер C99.

Когда пробовал?

или системой сборки

ccache всякие есть же

По ссылке много букв, прочитал только начало.

Как они борятся с использованием макросов из header'ов в коде (например, #define LDAP_VERSION3 3 из ldap.h), и что они делают с шаблонами?

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

Макросы извне модулей игнорируются кроме тех, которые в специальном белом списке да и те берутся только из командной строки (т.е. #define перед #include полностью игнорируются). В итоге легко получить модуль для одних параметров, а приложение для других. Но из модулей макросы могут экспортироваться. Хотя внутренние правила их согласования там непростые.

С шаблонами проблем нет. Но может тут путаница с тем, что такое эти «модули», они всего лишь сериализованный AST набора заголовков и они не предназначены для распространения чего-то вроде пакетов. Модули создаются локально и не покидают систему так как намертво завязаны на версию компилятора (и конкретные опции компиляции). По факту это кеш для фронтенда.

Не всем нужна кросс-компиляторная совместимость

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

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

А вот реализация... Когда будет в стандарте и в gcc - можно будет попробовать. А на ковыряние какой-то неведомой clang-специфической фигни времени жалко. Возможно, что в стандарт оно попадёт (если попадёт) в сильно изменённом виде.

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

они переизобретают QtQuick/QML

Скорее Java, Objective-C или Python.

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

Чтобы кошмарный ад по типу

#ifndef BLAHBLAH_INCLUDED
#define BLAHBLAH_INCLUDED

...
#endif

На человеческий import (ну или какие там кейворды будут) заменить?

а меня он совсем не беспокоит :)

Чтобы кошмарный ад по типу

это спокойно заменяется на:

#pragma once

Во всех популярных компиляторах.

Которая не стандартизирована ещё. Нет планов включить это в стандарт?

Она поддерживается всеми компиляторами. Это стандарт де-факто.

Не всеми.

Just use D.

кстати, кто из мейнстрима не умеет?

https://en.wikipedia.org/wiki/Oracle_Solaris_Studio

Которая не стандартизирована ещё

ещё

И не будет, ибо pragma.

Эммм, у меня mingw64 всё компиляет. Или я не понял о чем этот тред? Извините, пьян, потом исправлюсь.

Oracle Solaris Studio

Нафейхоа? Нафейхоа компилятор под платформы, под которые есть gcc, intel и компания?

Oracle Solaris Studio

Нафейхоа? Нафейхоа компилятор под платформы, под которые есть gcc, intel и компания?

Для SPARC есть Intel? O_o

Есть gcc. Не достаточно?

Нет. Так же, как для x86 недостаточно только GCC.

Так же, как для x86 недостаточно только GCC.

И что в icc (или другом) такого, чего дает OSS на ненужном SPARC? Убероптимизации, которые на этой платформе нафиг никому не упали?

Так же, как для x86 недостаточно только GCC.

И что в icc (или другом) такого, чего дает OSS на ненужном SPARC? Убероптимизации

Да.

которые на этой платформе нафиг никому не упали?

okay.jpg

Такое впечатление, что это чуть ли не единственный компилятор, который не умеет (пока?) pragma once: https://en.wikipedia.org/wiki/Pragma_once#Portability

На stackoverflow еще нашлось упоминание некого PGI. Если это часть PGI Workstation, то это может быть еще более редким зверем, чем Oracle CC.

Нет, а серьезно - они нужны*?

*нужны - это когда профит от продукта способен покрыть затраты на его разработку.

Т.е. много ли тех, кому они на спарке нужны? Да, самому ораклу внутренне нужны. А остальным? Много ли кто занимается числодроблением и подобными вещами на спарке? Ынтерпрайзу проценты скорости обычно до лампочки.

В моих ТЗ было такое условие.

кросскомпиляторная совместимость - самое главное. остальное - свистелки и перделки. имхо, ненужно. и ваще попахивает до-диезом.

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

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

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

поэтому они не вписываются в эту концепцию и не нужны.

Давайте не будем говорить за всех, хорошо?

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

То есть, если вдруг макросы засунут в модули, и получить к ним доступ можно будет через namespace, будет хуже? Сейчас макросы и сопутствующие проблемы порядка инклудов — это головная боль. То, что ты называешь гибкостью, всего лишь workaround вокруг этой содомии.

plus one

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

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

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

Тебе надо было раньше шевелиться, хипсторы уже релизнули С++11, процесс пошел.

Да все проще - плюсы сами по себе - треш, угар и не нужны, например.

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

Может дело не в хисторах, а в том, что кто-то слишком консервативен и отстал от прогресса?