Monomorphize c++ class over cartesian product of types

Question

Suppose that we have a templated class P with three templated arguments A,B, and C (i.e., P<A,B,C>). Is it possible to monomorphize this class in the source file (not header) over the Cartesian product of three lists of types (Given [A1,A2,A2], [B1,B2,B3], and [C1,C2,C3], I'd like to have P<Ai,Bj,Ck> for i,j,k in [1,2,3] in the object file)? While I think it's not unreasonable to write down all of the monomorphisms I need, it quickly explodes. I understand that it's probably best to move the templated functions to the header file and call it a day, but suppose that those functions are big and take a while to compile, and thus moving it to a header file is not an option because the cost of recompiling them during development is too much.

It would be great if the solution compiles with gcc<13 (for compatibility with nvcc).

Additional questions: Can we do the same thing but with a predicate function on the types?

I thought about the following solution, but upon inspection with nm, it shows that the functions are local (marked with t instead of T). using SEQ_FOR_EACH also seems feasible, but I would like to (if possible) avoid macros and boost. Ideally, I'd like the classes to be available at the top scope, not inside a nested class (perhaps attainable by creating the classes inside another class)

// main.cpp
#include <iostream>
#include "lib.hpp"

using namespace H;
int main(){
  P<A1,B2,C3> p;
  std::cout << p.f(2) << std::endl;
}

// lib.hpp
#include <variant>
#include <stdexcept>

namespace H {
template<typename A, typename B, typename C>
struct P {
  size_t f(size_t x) {
    return A::value * B::value * C::value * x;
  }
};

struct A1 { static constexpr size_t value = 1; };
struct A2 { static constexpr size_t value = 2; };
struct A3 { static constexpr size_t value = 3; };

struct B1 { static constexpr size_t value = 1; };
struct B2 { static constexpr size_t value = 2; };
struct B3 { static constexpr size_t value = 3; };

struct C1 { static constexpr size_t value = 1; };
struct C2 { static constexpr size_t value = 2; };
struct C3 { static constexpr size_t value = 3; };

using Av = std::variant<A1, A2, A3>;
using Bv = std::variant<B1, B2, B3>;
using Cv = std::variant<C1, C2, C3>;
}

// lib.cpp
#include "lib.hpp"

namespace H {
Av make_variantA(size_t x) {
  if (x == 1) {
    return A1();
  } else if (x == 2) {
    return A2();
  } else if (x == 3) {
    return A3();
  } else {
    throw std::runtime_error("x = " + std::to_string(x) + " is not valid");
  }
}

Bv make_variantB(size_t x) {
  if (x == 1) {
    return B1();
  } else if (x == 2) {
    return B2();
  } else if (x == 3) {
    return B3();
  } else {
    throw std::runtime_error("x = " + std::to_string(x) + " is not valid");
  }
}

Cv make_variantC(size_t x) {
  if (x == 1) {
    return C1();
  } else if (x == 2) {
    return C2();
  } else if (x == 3) {
    return C3();
  } else {
    throw std::runtime_error("x = " + std::to_string(x) + " is not valid");
  }
}

void P_mono(size_t a, size_t b, size_t c) {
  std::visit([&]<typename A>(A) -> size_t {
    return std::visit([&]<typename B>(B) -> size_t {
      return std::visit([&]<typename C>(C) -> size_t {
        P<A, B, C> p;
        return 1;
      }, make_variantC(c));
    }, make_variantB(b));
  }, make_variantA(a));
}

}

cmake_minimum_required(VERSION 3.27)
project(stack_mono)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_FLAGS
        "${CMAKE_CXX_FLAGS} -I .. -Wall -mcmodel=medium -march=native -Wextra -Wno-register -fPIC -Wfatal-errors")
set(CMAKE_CXX_FLAGS
        "${CMAKE_CXX_FLAGS} -fno-omit-frame-pointer ")

add_library(lib lib.cpp)
add_executable(stack_mono main.cpp)
target_link_libraries(stack_mono lib)

The example seems to work, but will it always work or am I at the mercy of the compiler to decide wether the function is available everwhere?

Answer 1

You are implicitly instantiating the type. Implicit instantiations are a bit like an inline function: the compiler eliminates duplicates at link time.

What happens after link time to symbols is a subject outside the c++ standard.

In practice, even your implicit instantiation can be as-if compiled away, as unused implicit instantiations don't have side effects in a non-pathological prpgram (like, maybe some stateful metaprogramming can detect it, but stateful metaprogramming is considered harmful).

I suspect what you want is an explicit template instantiation so other object files don't need to see the definition. There is no way outside of macros or code generation to export a computed list of template instantiations.

https://en.cppreference.com/w/cpp/language/class_template covers explicit template instantiations.

At this point you are really fighting nvcc.

You could create a function that takes N integers and returns a variant over the cartesian product. That function, if kept around, sort of implies that the classes all exist in some sense.

To do that I'd start with an index:

template<std:;size_t n>
using index_t=std::integral_constant<std:;size_t, n>;

next define a variant of indexes from 0 to n-1 (call it a venum<n> = std::variant<index_t<0>,…,index_t>` - doing this is an exercise left to the reader); that in turn lets you make a factory that goes from a runtime index to a compile time index:

constexpr venum<sizeof...(Is)> r[]={
  index_v<Is>...
};
return r[i];

We can now use template metaprogramming to write your variant makers, producing variants over a pack of types (I would wrap the types in struct tag_t<T>{}; so we don't have to care about their properties in generic code).

Having type lists like

template<class...>struct types_t{}; also helps make this more generic: we can write generic cartesian type product code

using cart_result=cartesian_t<
  types_t<A1,A2,A3>,
  types_t<B1,B2>,
  types_3<c1,C2,C3>
>;

producing a types_t<types_t<A1,B1,C1>,…,types_t<A3,B2,C3>>.

And similarly, a type applier (fmap) that takes a types bundle of types and a template, and makes a types bundle of template instances. Then another applier that takes a types bundle and a template, and applies the types to the template.

The result is

std::variant<P<…>,…,P<…>> getP(int a, int b, int c);

with the return calue and body of the function generated from a cartesian product of the list of list of types you write once.

As the getP function can be exported.from your object file, eliminating the P classes even though they are merely implicitly instantiated seems difficult.

Please note: the use of ... is literal C++ three dots, while … is figurative fill in the blanks. Many details skipped because typing them on a smartphone is hard, and I suspect the OP (and anyone else doing exponential template code generation) can fill in the blanks with a bit of effort: I have used these techniques in other answers here, I can dredge thdm up if needed.

Be careful: compilers tend to explode when you ask them to generate exponential amounts of code from templates. Few people think of the O notation of their exported template symbol length as a core programming barrier, but it is here.