import?
который мало где работает...
Нуу, это уже другая проблема))
Спасибо, посмотрю примеры
я бы не стал советовать в чате для новичков суперновую фичу, которая почти не поддерживается
А что с ним не так
только ты особо слюни не распускай, нормальный компилятор поддерживающий такую штуку трудно найти (msvc нормальным не считаю)
Тупая система. Ради одного метода он подключает весь хедер со всеми class def и прочим.
Буду иметь ввиду
Пропиши прототип вручную :)
все споры по с++ би лайк
Ну а что делать то ещё, альтернатив нет. Модули альтернативой не считаю, т.к. их пока нигде нет
Переведи
modules
C++20?
Однако ж. Это Вы с позиции кого заявляете? Видимо, не пользователя, поскольку ему-то как раз написать два слова труда не составит. Сможете со стороны разработчика языка предоставить сколь-нибудь объективную критику системы подключаемых заголовков?
Дублирование кода в ней есть
Делай хедеры меньше, группируй пространства имен
Это какого-такого кода дублирование в ней есть? Не того ли, случайно, который объясняет компилятору, что делать с тем или иным идентификатором? Компилятор, напоминаю, работает в пределах одной единицы трансляции (.cpp-файла, если традиционно). Можно ли считать такой код дублированием, в таком случае?
Потому что аргументированно спорить по дизайну языка не каждый можеь
это щас правда просят аргументы того, что копипаста кода вместо нормальной системы подключения внешнего кода это норм?
Дублирование объявлений функций. Дублирование исходного кода я имею в виду
как мне не экспортировать макрос?)
Еще раз задам свой вопрос: Где здесь копипаста кода?
Я говорю не про то, как #include обрабатывается, только про написание кода
Не ликайте его из хедера, очевидно. #undef.
а мне в цпп он типо не нужен?
Так это Вам виднее, нужен он Вам в нем или нет. Если нужен - то зачем задаваться вопросом о том, как его "не экспортировать"?
то что это макрос для конкретного класса, я не хочу чтобы его кто-то еще видел. Что мне делать?
void f(); // <-- void f() { // <-- }
Что означает "макрос для конкретного класса"?
макрос который используется в одном классе
Пожалуйста, Вы вольны определить подпрограмму inline-овой прямо в хедере, если беспокоитесь о том, чтобы не писать прототипы. В остальном - подключаемое объявление описывает компилятору семантику идентификатора, как я уже говорил выше.
Это как так? Пример можете привести? Макросы - препроцессор. У них нет областей видимости вообще.
#ifdef __cxx17 #define ENABLE_CONSTEXPR constexpr #else #define ENABLE_CONSTEXPR #endif class Foo { ENABLE_CONSTEXPR void kek(); }
оно все равно std либу линкуед
так я и говор. что не хочу чтобы мои внутренние макросы вылезали в интерфейс, и система инклюдов вообще нифига предложить не может чтобы эту проблему решить
забей на єто и прийми как должное тебя єто не будет волновать
Возвращаюсь к своему вопросу: что Вам мешает в конце Вашего хедера (как я понимаю?) прописать #undef ENABLE_CONSTEXPR?
то что этот хедер инклюдится в цпп где мне нужен этот макрос
Мы с Вами кругами ходим. Вы выносите макросы в самостоятельный заголовок. Подключаете его там, где они нужны. И не подключаете там, где не нужны. Если макросы нужны только в пределах заголовка - уничтожайте их определение через соответствующую препроцессорную директиву.
Я пишу библиотеку, почему юзер видит ENABLE_CONSTEXPR который он не должен использовать? Еще раз, я не могу написать андеф, потому-что он мне нужен в цпп
... В каком .cpp он Вам нужен? В .cpp с определением? Там этот макрос будет доступен. Предоставлять ли его в .cpp пользователя - Ваше решение.
как это он будет доступен если в конце хедера написан #undef
Опережу Ваши дальнейшие вопросы: /* enable_constexpr */ #define ENABLE_CONSTEXPR /* disable_constexpr */ #undef ENABLE_CONSTEXPR /* lib_header.hpp */ #include <enable_constexpr> /* declarations */ #include <disable_constexpr> /* lib_cpp.cpp */ #include <lib_header.hpp> #include <enable_constexpr> /* definitions */ /* user_cpp.cpp */ #include <lib_header.hpp> Есть проблемы?
есть, теперь мне нужно дважды инклюдить все хедеры с нужными макросами
1. Вы можете собрать их в нужные Вам группы. 2. Инклуды в конце файла "выглядят всрато", потому что Вы слишком ригидно на них смотрите. 3. Дублирования кода никакого нет. Препроцессор недекларативен. Вы управляете его внутренним состоянием директивами.
ну как нет дублирования, в примере выше два инклюда enable_constexpr
Инлайн всего подряд замедляет сборку
Дублирования кода никакого нет. Препроцессор недекларативен. Вы управляете его внутренним состоянием директивами.
Абсолютно верно, речь шла о конкретной проблеме.
Если они определены в хедере, они там имплицитно inline вроде как.
Решение проблемы созданием другой такой же серьезной проблемы это дичь
И именно поэтому я лишь упомянул такую возможность, но не остановился на ней, не так ли?
Обсуждают сегодня