вышла новая версия cmake 4.2.0
https://discourse.cmake.org/t/cmake-4-2-0-available-for-download/15333
с исправлением для модулей что бы можно было использовать
import std;

The “CMAKE_CXX_STDLIB_MODULES_JSON” variable was added to set the
path to the “import std” metadata file for the standard library
rather than using the compiler to discover its location.

проблема была в том что зоопарк линукс пакетов
собирали gcc по разному
и файл метаданных необходимый для подключения import std
был в разных локациях линукс фс


так же проблемы была при использовании
clang под виндовс с msvc stl
поскольку для clang была поддержка только кланговского stl
и он не находил файл метаданных с msvc stl

проверил, это не пофиксили
upd
оказывается проблема более глобальная
у каждого компиля свой формат json метаданных
и если clang/gcc еще кое как сходятся
то у msvc свой
поэтому cmake разрабы играются со своим парсером и пытаются стандартизировать формат метаданных
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11422
https://github.com/ecostd/rfcs/pull/3
upd2
пофиксил для cmake 4.2.0 что бы работал clang под виндовс c import std;


следующая версия cmake 4.3.0 зарелизится не ранее февраля 2026

Здравствуйте, Великий Мессия, Вы писали:

ВМ>поэтому придется пока что пользоваться прямым указанием файла метаданных через переменную cmake

Модули не нужны

Здравствуйте, Marty, Вы писали:

M>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>поэтому придется пока что пользоваться прямым указанием файла метаданных через переменную cmake

M>Модули не нужны

сказал тот кто не может перейти со своего любимого С++17

в то время как народ во всю осваивает С++23
и пробует уже С++26

Здравствуйте, Великий Мессия, Вы писали:

ВМ>в то время как народ во всю осваивает С++23

Интересно, и что там такого кардинально нового можно осваивать?

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>в то время как народ во всю осваивает С++23

S>Интересно, и что там такого кардинально нового можно осваивать?

для меня как минимум
std::expected этот правда внешней реализацией можно и для С++17 подключить
std::bit_cast
std::format — не хочу тянуть внешнюю зависимость

а вообще что бы осваивать новое
начинается с переключения стандарта в компиляторе
но марти и этого боится

Здравствуйте, Великий Мессия, Вы писали:

ВМ>std::expected этот правда внешней реализацией можно и для С++17 подключить

OK

ВМ>std::bit_cast

OK

ВМ>std::format — не хочу тянуть внешнюю зависимость

std::format -- это C++20.

В общем, после C++20 в С++23 изучать особо-то и нечего. Там больше нововведений в стандартной библиотеке.

ВМ>а вообще что бы осваивать новое
ВМ>начинается с переключения стандарта в компиляторе

Изучать новое можно и на пет-проектах, а для продакшена и C++17 может оказаться "слишком новым"

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>std::expected этот правда внешней реализацией можно и для С++17 подключить

S>OK

ВМ>>std::bit_cast

S>OK

ВМ>>std::format — не хочу тянуть внешнюю зависимость

S>std::format -- это C++20.

спутал, да format C++20 std::print С++23

S>В общем, после C++20 в С++23 изучать особо-то и нечего. Там больше нововведений в стандартной библиотеке.

изучение != освоение(использование)

ВМ>>а вообще что бы осваивать новое
ВМ>>начинается с переключения стандарта в компиляторе

S>Изучать новое можно и на пет-проектах, а для продакшена и C++17 может оказаться "слишком новым"

помнится кланг в С++17 собирается
так же Qt6 тоже С++17 требует

Здравствуйте, Великий Мессия, Вы писали:

ВМ>спутал, да format C++20 std::print С++23

Странно что не был назван deducing this. Вот это, реально, одно из важнейших нововведений в современный C++.
Сделанное, по традиции, через жопу. Но все-таки кардинальное решение для неприятной проблемы.

Здравствуйте, so5team, Вы писали:

S>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>спутал, да format C++20 std::print С++23

S>Странно что не был назван deducing this. Вот это, реально, одно из важнейших нововведений в современный C++.
S>Сделанное, по традиции, через жопу. Но все-таки кардинальное решение для неприятной проблемы.

я его как в басне "обезьяна и очки"
примерял примерял
но так применения и не нашел

лучше бы патерн матчинг завезли

Здравствуйте, Великий Мессия, Вы писали:

ВМ>я его как в басне "обезьяна и очки"
ВМ>примерял примерял
ВМ>но так применения и не нашел

применение в том, что this теперь можно передавать по значению

template <typename T>
struct Range {
    T start;
    T end;

    bool contains(this const Range self, const T value) noexcept {
        return value >= self.start && value <= self.end;
    }
};

Никаких брожений по памяти. Всё разложится по регистрам и выполнится максимально быстро.

Ну и примеры заморочек с rvalue и lvalue ссылками можно поискать в инете. Но это действительно надо очень редко.

Здравствуйте, sergii.p, Вы писали:

SP>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>я его как в басне "обезьяна и очки"
ВМ>>примерял примерял
ВМ>>но так применения и не нашел

SP>применение в том, что this теперь можно передавать по значению
SP>

SP>template <typename T>
SP>struct Range {
SP>    T start;
SP>    T end;

SP>    bool contains(this const Range self, const T value) noexcept {
SP>        return value >= self.start && value <= self.end;
SP>    }
SP>};
SP>

SP>Никаких брожений по памяти. Всё разложится по регистрам и выполнится максимально быстро.

это что то новое про регистры
this или аргумент оно одинаково идет через регистр если это допустим x64

SP>Ну и примеры заморочек с rvalue и lvalue ссылками можно поискать в инете. Но это действительно надо очень редко.

я это и имел ввиду
это разве что разрабам либов

Здравствуйте, Великий Мессия, Вы писали:

SP>>Ну и примеры заморочек с rvalue и lvalue ссылками можно поискать в инете. Но это действительно надо очень редко.

ВМ>я это и имел ввиду
ВМ>это разве что разрабам либов

Да, нам это нужно

Здравствуйте, Великий Мессия, Вы писали:

ВМ>this или аргумент оно одинаково идет через регистр если это допустим x64
так в случае this в регистре будет лежать адрес, по которому надо дополнительно пойти и вытащить сами данные. А если передавать по значению, start и end сразу улетят в регистры.

Здравствуйте, Великий Мессия, Вы писали:

ВМ>я его как в басне "обезьяна и очки"
ВМ>примерял примерял
ВМ>но так применения и не нашел

Ты прикалываешься, что ли?

так:

class A
{
public:
    template<typename T> auto&& get_foo(this T&& _) { return std::forward<T>(_).foo; }
    template<typename T> auto&& get_bar(this T&& _) { return std::forward<T>(_).bar; }
    template<typename T> auto&& get_baz(this T&& _) { return std::forward<T>(_).baz; }
    template<typename T> auto&& get_etc(this T&& _) { return std::forward<T>(_).etc; }

private:
    Foo foo;
    Bar bar;
    Baz baz;
    Etc etc;
};

или так:

class A
{
public:
    Foo& get_foo() & { return foo; }
    Foo&& get_foo() && { return std::move(foo); }
    const Foo& get_foo() const & { return foo; }

    Bar& get_bar() & { return bar; }
    Bar&& get_bar() && { return std::move(bar); }
    const Bar& get_bar() const & { return bar; }

    Baz& get_baz() & { return baz; }
    Baz&& get_baz() && { return std::move(baz); }
    const Baz& get_baz() const & { return baz; }

    Etc& get_etc() & { return etc; }
    Etc&& get_etc() && { return std::move(etc); }
    const Etc& get_etc() const & { return etc; }

private:
    Foo foo;
    Bar bar;
    Baz baz;
    Etc etc;
};

Что, совсем пользы не видишь?

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>я его как в басне "обезьяна и очки"
ВМ>>примерял примерял
ВМ>>но так применения и не нашел

R>Ты прикалываешься, что ли?

R>так:

R>

R>class A
R>{
R>public:
R>    template<typename T> auto&& get_foo(this T&& _) { return std::forward<T>(_).foo; }
R>    template<typename T> auto&& get_bar(this T&& _) { return std::forward<T>(_).bar; }
R>    template<typename T> auto&& get_baz(this T&& _) { return std::forward<T>(_).baz; }
R>    template<typename T> auto&& get_etc(this T&& _) { return std::forward<T>(_).etc; }

R>private:
R>    Foo foo;
R>    Bar bar;
R>    Baz baz;
R>    Etc etc;
R>};
R>

R>или так:

R>

R>class A
R>{
R>public:
R>    Foo& get_foo() & { return foo; }
R>    Foo&& get_foo() && { return std::move(foo); }
R>    const Foo& get_foo() const & { return foo; }

R>    Bar& get_bar() & { return bar; }
R>    Bar&& get_bar() && { return std::move(bar); }
R>    const Bar& get_bar() const & { return bar; }

R>    Baz& get_baz() & { return baz; }
R>    Baz&& get_baz() && { return std::move(baz); }
R>    const Baz& get_baz() const & { return baz; }

R>    Etc& get_etc() & { return etc; }
R>    Etc&& get_etc() && { return std::move(etc); }
R>    const Etc& get_etc() const & { return etc; }

R>private:
R>    Foo foo;
R>    Bar bar;
R>    Baz baz;
R>    Etc etc;
R>};
R>

R>Что, совсем пользы не видишь?

вижу и что?

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

Здравствуйте, sergii.p, Вы писали:

SP>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>this или аргумент оно одинаково идет через регистр если это допустим x64
SP>так в случае this в регистре будет лежать адрес, по которому надо дополнительно пойти и вытащить сами данные. А если передавать по значению, start и end сразу улетят в регистры.

нужно искать и смотреть примеры
я не вижу причины почему во втором случае компилятор сразу должен вытянуть данные
по сравнению с первым
на ассемблере это будет одно и тоже
разница лишь в регистрах
в пером допустим как правило this в ecx поскольку вызов thiscall
во втором допустим не fastcall при котором опять же первым будет в ecx
а какой нибудь другой stdcall при котором первый аргумент будет в edx
разницы не вижу

либо у компилятора ну очень уж сильно связаны руки по оптимизации this с первом случае

Здравствуйте, Великий Мессия, Вы писали:

ВМ>зоопарк таких аксессоров нужен только разрабам либ
ВМ>мне негде такое тулить
ВМ>у меня нет классов которые бы мне нужно было использовать в таких вариациях

А можно быть разрабом С++, но не быть разрабом либ?

А ты разраб чего, если не секрет?

Здравствуйте, rg45, Вы писали:

R>Здравствуйте, Великий Мессия, Вы писали:

ВМ>>зоопарк таких аксессоров нужен только разрабам либ
ВМ>>мне негде такое тулить
ВМ>>у меня нет классов которые бы мне нужно было использовать в таких вариациях

R>А можно быть разрабом С++, но не быть разрабом либ?

имелось ввиду что
у меня нет мелких классов для которой нужны были бы разные варианты аксессоров
по примеру string, где я бы ее по разному юзал для левой ссылки или умирающей правой
все классы большие и аллоцируются через new/make_unique/make_shared

R>А ты разраб чего, если не секрет?

готовых приложений

Здравствуйте, Великий Мессия, Вы писали:

ВМ>у меня нет мелких классов для которой нужны были бы разные варианты аксессоров

Ну аксессоры были взяты только в качестве примера. Общий смысл в том, что раньше число способов передать this в функцию-член было сильно ограничено по сравнению с обычными параметрами, что иногда вынуждало писать лишние перегрузки там, где можно было бы обойтись одной версией. А теперь это ограничение снято и this можно передать хоть по значению, хоть через perfect forwarding reference, как и обычные параметры.

Здравствуйте, Великий Мессия, Вы писали:

R>>А ты разраб чего, если не секрет?

ВМ>готовых приложений

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