Optionally runtime properties

Question

I’m looking for information on a pattern that I have used recently. The basic idea is that there is a type with a property that can either be compile-time (template parameter) or runtime (member). std::span is a good example of this pattern. Here is an example of the pattern in its purest form:

// sentinel value
constexpr int runtime = -1;

// compile-time version
template <int Property = runtime>
struct Type {
  static constexpr int getProp() {
    return Property;
  }
};

// runtime version
template <>
struct Type<runtime> {
  int getProp() const {
    return property;
  }
private:
  int property;
};

template <typename T>
int square(T obj) {
  // does a multiply if T is Type<runtime>
  // otherwise returns a constant
  return obj.getProp() * obj.getProp();
}

You usually end up with two very similar classes so I typically hoist common code up into a base class using the CRTP idiom.

• Does this pattern have a name?
• If there isn’t a good name, how should I describe it? (The title of the question is my best attempt)
• Has someone written about this pattern somewhere?
• When should I avoid using this pattern?

Answer 1

OK, I'll be only referring to 'When should I avoid using this pattern?':

I tend to say 'always':

1. There's a sentinel value (in given case -1) – what if you need it at compile time? Then you'd still have to use the runtime variant.
2. Any two of Type<n> with differing values for n are different, independent types. So if you intended to use them together in a container – bad luck. But if you cannot, then what's use case for?

So instead of specialising one special (sentinel) value, I'd go with two totally unrelated classes:

template <int Property>
struct CompileTimeType
{
    static constexpr int getProp() { return Property; }
};
struct RunTimeType
{
    int getProp() const { return property; }
private:
    int property;
};

Be aware that as is now, you'd have to use both differently anyway:

CompileTimeType<whatEver>::getProp();
RuntimeType rtt;
rtt.getProp();

All no problem if you know in advance what type you have. Want to use them in template functions? Well, one time, you need an instance, the other time not. Hmm... – Still want to have an instance for compile time variant as well? Then you can make the function non-static.

If you want to combine arbitrary combinations of comtile and run time instances in a container, you'd need a common base class anyway (even for different compile time instanciations, not considering the run time variant...). Then you'd be forced to have non-static functions in all variants. But the virtual function call you introduce this way will consume up all advantages you gained previously by template usage, so you could as well stay with the runtime variant only then and likely are even better off...