Возможна ли в C++ compile-time интроспекция?

получить доступ к его структуре

Что конкретно нужно?

Вот пример сериализации через экспериментальную рефлексию https://compiler-explorer.com/z/PfM7dTWxr

если речь про рефлексию то ее пока нет в плюсах, надо пользоваться библиотеками вроде boost hana. Что есть - можно например выбирать перегрузки в зависимости, есть ли у класса какое-то поле.

void foo(auto a) requires requires { a.bar; } {
    std::cout << "has bar field\n";
}

void foo(auto a) {
    std::cout << "no bar field\n";
}

Ну скажем, мне передается экземпляр типа Object (что за тип - неизвестно, просто передался), надо определить в compile time, что же это за тип, какие у него методы, ну и иметь возможность их дергать. Короче как в java.reflection.

что же это за тип, какие у него методы, ну и иметь возможность их дергать

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

Если известна сигнатура метода, наличие которого нужно проверить в переданном типе, то это можно сделать через шаблоны. А если есть c++20, то можно через концепты. Просто так получить список методов не выйдет.

Можно но криво. И для каждого такого типа придётся руками инициировать сбор метаинформации. Да и со списками в компайл-тайм работать такое себе…

КМК у Вас постановка странная. Оно точно надо? Если да то зачем, можно сценарий использования? В рантайм это выглядит нормально, а вот в компайл-тайм…

Ну скажем, мне передается экземпляр типа Object (что за тип - неизвестно, просто передался), надо определить в compile time, что же это за тип, какие у него методы, ну и иметь возможность их дергать

Если объект передаётся в run time, то в compile time о нём ещё неизвестно. Максимум, что можно сделать - некую диспетчеризацию: вычитать откуда-то признак типа и, в случае успешного распознавания, скастовать объект к заранее объявленному конкретному типу с методами и т.д.

Короче говоря, не готов.

Спасибо.

Java reflection, по-твоему, в compile-time происходит?

К чему ты не готов? К принятию реальности? Или как это понимать?

Мои велосипеды

BGA__INSPECT_TYPE https://github.com/bga/_cpp/blob/master/include/!cpp/common.h#L150

static_print https://github.com/bga/_cpp/blob/master/include/!cpp/common.h#L506

static_assert_eq/neq/lt/gt/lte/gte…/test https://github.com/bga/_cpp/blob/master/include/!cpp/common.h#L284

static_assert_type_eq/neq https://github.com/bga/_cpp/blob/master/include/!cpp/common.h#L321

это какой-то набег орды кочевников-питонистов на земли плюсовиков.

это какой-то набег орды кочевников-питонистов на земли плюсовиков.

Вот распиарили сиплюсплюс, получите, распишитесь)

Все плюсовики когда-то через это желание проходят. Кратко: нет. Варианты:

1. Описывать структуры на другом языке, генерировать по ним плюсовый код (аки protobuf и компания);
2. Описывать структуры хитрыми макросами, которые используют «лямбда-макрос» внутри. Это путь boost::hana и подобных;
3. Страдать, писать кучу boilerplate руками или макросами vim. Создаёт видимость бурной деятельности и много строчек однотипного кода;
4. Молиться, когда стандартизируют reflection, его нормально реализуют компиляторы, и новый стандарт разрешат использовать в проекте;
5. Написать плагин для gcc/clang, как это сделали в https://www.codesynthesis.com/products/odb/
6. Не использовать C++ там, где такая необходимость возникает. Написать биндинги к какому-нибудь питону, и заниматься интроспекцией уже там.

6. Явно не подходит, у питона так себе компилтайм)

до исполнения программы?

Написать биндинги к какому-нибудь питону, и заниматься интроспекцией уже там.

UPD. Блин, MOPKOBKA опередил. :)

А вообще, см. https://www.youtube.com/watch?v=yuIOGfcOH0k

Мелкие детали с тех пор поменялись (например, matcher-ы теперь имеют lowercase имена), но в целом до сих пор годится как starting point.

Тебе наверно нужна связка if constexpr и requires из C++23.

template<class T> 
void fill(T& container, std::size_t size) { 
    if constexpr (requires {container.reserve(size); }) { 
        container.reserve(size); 
    }

    for (std::size_t i = 0; i < size; i++) {
        container.push_back(i);
    }
}

пример

стандартными средствами языка нет и вероятно никогда не будет.

по сути эта задача даже не сопоставима с constexpr new() — поскольку, что бы компилятору сделать предположения о том, какой тип на самом деле имеет эта сущность — надо сперва ее получить в реальности в исполняемом коде — а она может прийти извне или из другого юнита трансляции...

другими словами — построить статический вариант кода на основе различия поставляемого «неизвестного» типа сущности невозможно — можно лишь создать ветви обработки для рантайма.