х64 тулзу хочу натравить на код под арм, код под арм не пользуется /usr/include и рассчитывает на системные хедеры несколько другого вида (насколько я могу судить)

я же не понимаю, как она у тебя сделана

да, это именно "Расскажите мне, фиксят ли модули мои проблемы". Как мне кажется, есть две группы людей - программисты, которые пишут код, и комитетчики, которые пишут стандарт. И эти группы не очень-то пересекаются. Вот тут Струструп пишет Consider examples of what I am thinking of void f(int x #ifdef FOO , double d #endif ); and [...] Yes, I have seen such, and worse, in real code. Naturally, some of you would quite reasonably say, “so don’t do that!” but a tool builder must build for the worst case. The mere possibility of such horrors [...] (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0955r0.pdf) но то что он называет ужасом - это обыденность, мы такое каждый день пишем, ибо как еще можно писать кросс-платформенный код, или делать отключаемые фичи. Так вот коллеги из стандарта, как мне кажется, должны в первую очередь адресовать проблемы программистов, а не гнаться за чувством прекрасного. Это же относится и к рефлексии. Мы годами пишем всякие MOCK_METHOD0(Func, void()); и вот нам сейчас обещают рефлексию в стандарте в 2027 году, в продовых компиляторах - в 2030 году. Да люди на пенсию выйдут к кому времени, или язык поменяют.

А как вы живёте без макросов в статических/динамических библиотеках? "Как одну и ту же динамическую библиотеку запускать с ассертами, и без ассертов если NDEBUG задефайнен, ведь макросы не влияют на скомпилированный уже код?"</sarcasm> Другими словами: если у вас в руках молоток, это еще не значит что всё вокруг становится гвоздями. Инструмент "модули" специально создавался так, чтобы макросы не влияли на скомпилированный модуль. Если сделать чтобы макросы влияли на собранные модули, то вы протеряеете большую часть производительности от их использования. Нужны макросы которые влияют на модули? Делайте так // my_library.h #ifdef NDEBUG import MyLibraryRelease; #else import MyLibraryDebug; #endif Нужны макросы, экспортируемые из модулей? Делайте так: // my_library.h import MyLibrary; #define MY_LIBRARY_FOO #define MY_LIBRARY_BAR Приёмы можно совмещать

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

...ну или так https://stackoverflow.com/questions/2988779/gcc-how-to-ignore-standard-include-paths

А как вы живёте без макросов в статических/динамических библиотеках? "Как одну и ту же динамическую библиотеку запускать с ассертами, и без ассертов если NDEBUG задефайнен, ведь макросы не влияют на скомпилированный уже код?"</sarcasm> Другими словами: если у вас в руках молоток, это еще не значит что всё вокруг становится гвоздями. Инструмент "модули" специально создавался так, чтобы макросы не влияли на скомпилированный модуль. Если сделать чтобы макросы влияли на собранные модули, то вы протеряеете большую часть производительности от их использования. Нужны макросы которые влияют на модули? Делайте так // my_library.h #ifdef NDEBUG import MyLibraryRelease; #else import MyLibraryDebug; #endif Нужны макросы, экспортируемые из модулей? Делайте так: // my_library.h import MyLibrary; #define MY_LIBRARY_FOO #define MY_LIBRARY_BAR Приёмы можно совмещать

Разве кто-то говорил о влиянии макросов на импортируемые модули? а-ля #define X 1 / #include "foo.h"? так это и сейчас не работает, т.к. этот X не попадет в foo.cpp, и вообще это нарушение ODR. Да, нужны макросы, экспортируемые из модулей. Нет, заворачивать все импорты в заголовочные файлы - это плохая идея. Кстати, пропозал разрешает два раза импортировать один модуль? import M; import M; ?

Он усложняет код. Часто есть ситуация, когда в инклуде объявляется макрос, и в этом же инклуде и используется. // foo.h struct X {}; #define Y ... X ... struct Z { ... Y ... };с модулями надо будет написать // foo_macros_internal.h #define Y ... X ... // foo.ixx #include "foo_macros_internal.h" struct X {}; struct Z { ... Y ... }; // foo.h import foo; #include "foo_macros_internal.h"

Разве кто-то говорил о влиянии макросов на импортируемые модули? а-ля #define X 1 / #include "foo.h"? так это и сейчас не работает, т.к. этот X не попадет в foo.cpp, и вообще это нарушение ODR. Да, нужны макросы, экспортируемые из модулей. Нет, заворачивать все импорты в заголовочные файлы - это плохая идея. Кстати, пропозал разрешает два раза импортировать один модуль? import M; import M; ?

Ваш пример был как раз из секции про влияние макросов на импортируемые модули

Он усложняет код. Часто есть ситуация, когда в инклуде объявляется макрос, и в этом же инклуде и используется. // foo.h struct X {}; #define Y ... X ... struct Z { ... Y ... };с модулями надо будет написать // foo_macros_internal.h #define Y ... X ... // foo.ixx #include "foo_macros_internal.h" struct X {}; struct Z { ... Y ... }; // foo.h import foo; #include "foo_macros_internal.h"

сколько можно наркоманить и применять решения 30-40 летней давности

Он усложняет код. Часто есть ситуация, когда в инклуде объявляется макрос, и в этом же инклуде и используется. // foo.h struct X {}; #define Y ... X ... struct Z { ... Y ... };с модулями надо будет написать // foo_macros_internal.h #define Y ... X ... // foo.ixx #include "foo_macros_internal.h" struct X {}; struct Z { ... Y ... }; // foo.h import foo; #include "foo_macros_internal.h"

Давайте посмотрим на проблему с другой стороны. У вас есть библиотека, которая в данный момент работает. Она header only. Допустим эта библиотеки помещается в хедере variant.hpp и экспортирует макрос BOOST_VARIANT_ENUM_PARAMS Вы хотите перенести эту библиотеку на модули, но 1) вам нужно экспортировать макросы 2) вам нужно заботиться о пользователях, у которых модулей ещё нет 3) вам нужно сделать так, чтобы пользовательский код автоматом подцеплял модули, если они доступны пункт 2) 3) решается только через добавление #ifdef HAS_MODULES import Variant; #else #include <variant.ipp> #endif в variant.hpp Пункт 1) решается через вынесение макроса в отдельный header: #include <variant_macro.hpp> #ifdef HAS_MODULES import Variant; #else #include <variant.ipp> #endif итого: все ваши пользователи довольны. Код им менять не надо, всё работает из коробки и использует макросы. Модули которые экспортируют макросы вам не нужны

Без макросни бывает сложненько)

Без макросни бывает сложненько)

какой, например? 😊

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

какой, например? 😊

Мне крайне больно делать без макросни рефлексию, к сожалению.

А ты жди нормальной рефлексии.

Давайте посмотрим на проблему с другой стороны. У вас есть библиотека, которая в данный момент работает. Она header only. Допустим эта библиотеки помещается в хедере variant.hpp и экспортирует макрос BOOST_VARIANT_ENUM_PARAMS Вы хотите перенести эту библиотеку на модули, но 1) вам нужно экспортировать макросы 2) вам нужно заботиться о пользователях, у которых модулей ещё нет 3) вам нужно сделать так, чтобы пользовательский код автоматом подцеплял модули, если они доступны пункт 2) 3) решается только через добавление #ifdef HAS_MODULES import Variant; #else #include <variant.ipp> #endif в variant.hpp Пункт 1) решается через вынесение макроса в отдельный header: #include <variant_macro.hpp> #ifdef HAS_MODULES import Variant; #else #include <variant.ipp> #endif итого: все ваши пользователи довольны. Код им менять не надо, всё работает из коробки и использует макросы. Модули которые экспортируют макросы вам не нужны

Подскажите, я правильно понимаю, что если "3.7.4.1.2 ... The pointer returned [речь про allocation functions, фактически операторы new] shall be suitably aligned so that it can be converted to a pointer of any complete object type with a fundamental alignment requirement" и "3.11.2 A fundamental alignment is represented by an alignment less than or equal to the greatest alignment sup- ported by the implementation in all contexts, which is equal to alignof(std::max_align_t)" то это значит, что выражение "new char[1000]" возвращает значение с выравниванием alignof(std::max_align_t) ?

А давайте посмотрим на ситуацию когда у нас в зависимостях 200+ библиотек, все разных авторов, некоторые зависят друг от друга, и кажется что HAS_MODULES уже не катит, т.к. кто-то умеет макросы, а кто-то нет. Коллеги из блумберга об этом и писали. Вынесение макросов в отдельный хедер - это костыль. Завтра модуль начнет экспортировать макрос, и все import надо будет менять на #include. > Но тогда возникает резонный вопрос: почему в столь прогрессивном пректе используются макросы? Серьезно? Ты же сам пишешь на С++, и спрашиваешь зачем макросы? Это такое двоемыслие (doublethink) чтоли? > Так зачем тащить легаси в супер пупер новую фичу зачем нужна супер новая фича, если она оторвана от реальности и не решает задачи промышленности? модули определенно решают задачи проектов уровня hello world, но в простых проектах всё настолько просто, что там и модули-то не нужны. А в больших проектах будут и макросы, и условная компиляция, и сложные зависимости - там как раз модули пригодились бы, но увы

Я спрашиваю, зачем экспортируемые макросы

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

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

контракты?

И что мешает сокращающие макросы типа assert писать отдельными файлами?

то, что это костыль, который усложняет код.

вам лишний инклуд код усложняет?

А давайте посмотрим на ситуацию когда у нас в зависимостях 200+ библиотек, все разных авторов, некоторые зависят друг от друга, и кажется что HAS_MODULES уже не катит, т.к. кто-то умеет макросы, а кто-то нет. Коллеги из блумберга об этом и писали. Вынесение макросов в отдельный хедер - это костыль. Завтра модуль начнет экспортировать макрос, и все import надо будет менять на #include. > Но тогда возникает резонный вопрос: почему в столь прогрессивном пректе используются макросы? Серьезно? Ты же сам пишешь на С++, и спрашиваешь зачем макросы? Это такое двоемыслие (doublethink) чтоли? > Так зачем тащить легаси в супер пупер новую фичу зачем нужна супер новая фича, если она оторвана от реальности и не решает задачи промышленности? модули определенно решают задачи проектов уровня hello world, но в простых проектах всё настолько просто, что там и модули-то не нужны. А в больших проектах будут и макросы, и условная компиляция, и сложные зависимости - там как раз модули пригодились бы, но увы

@zamazan4ik @berkus и прочие шарящие - можно кланг-тулзам как-то скормить путь до системных библиотек, используемых при кросс-компиляции? чтобы при парсинге #include <arpa/inet.h> тулза кушала хедер не из /usr/include а из ~/arm/cross/include

Можно, -I

ну как я понял у человека это не сработало

> модуль начнет экспортировать макрос Не начнёт. Модули макросы не экспортируют. разработчики модуля (а значит нового, поддерживаемого проекта) будут вынуждены обходиться без макросов > зачем нужна супер новая фича, если она оторвана от реальности и не решает задачи промышленности Внезапно промышленности, в долгосрочной перспективе, нужна быстрая компиляция кода. Макросы мешают быстрой компиляции кода. Желание некоторых компаний ускорить компиляцию всех своих 100Гб неподдерживаемого кода не прикладывая усилий вполне понятно. Но это желание противоречит интересам других компаний, желающих компилировать еще быстрее. А ещё вы учитывайте, что порой люди в комитете представляют именно интересы компании. Их мнение может отличаться от мнения компаний, но сделать они ничего не могут.

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

ближайший пример, есть некий инклуд который реализует min/max а в коде ты хочешь исползовать std::min/std::max компилер сругается и скажет что ты делаешь что-то не то

Сраный windows.h!! (╯°□°）╯︵ ┻━┻

Так это, можно два раза импортировать один и тот же модуль?

Так это, можно два раза импортировать один и тот же модуль?