C++: Associative map containers with compile-time lookup (opens in new tab)

Thanks! And just today, compile time regular expressions

https://www.youtube.com/watch?v=QM3W36COnE4

I don't know how to yet. And if this is possible, is it also possible to fix standard assoc arrays?

Re: 3), here's a clean and technically humble way that I typically use.

    enum {
        KEY_FOO,
        KEY_BAR,
        KEY_BLAH,
        NUM_KEYS,
    };

    struct KeyInfo {
        const char *name;
        int info1;
        float info2;
    };

    const static struct KeyInfo keyInfo[NUM_KEYS] = {
    #define MAKE(x, y, z) [x] = { #x, y, z }
        MAKE( KEY_FOO,   1,   1.0 ),
        MAKE( KEY_BAR,   7,   3.5 ),
        MAKE( KEY_BLAH, 42, 127.2 ),
    #undef MAKE
    };

    void print_key(int key)
    {
        printf("%d's name is %s\n", key, keyInfo[key].name);
    }

It's both low-tech and maintainable. It compiles super quick. If one doesn't like that one has to type KEY_FOO twice (in the enum and in the array definition), one can use X-macros or code generation. But personally I don't care.

Thanks for this clarification! I agree it can be useful.

Yes with the optional run-time lookup there is an extra two machine instructions (a cmp and jne) needed to check if this is the first time accessing the value. It is exactly as fast as a global variable if you don't need the optional run-time lookup.

As stated in the talk, the main use case for a map like this is to cache objects which are expensive to load/compute (again something like `getFont` comes to mind). In these use-cases you would likely also need a check like this anyway: a global pointer object which you need to check if it's a nullptr or not before using it.

Is their goal to keep adding more and more angle brackets until one day C++ is completely homoiconic?

Yes, because they desire speed.

Yup. The frozen map cannot be updated once it is initialized:

<<Once initialized, the containers cannot be updated, and in exchange, lookups are faster. And initialization is free when constexpr is used :-).>>

Thanks, I wasn't very clear but now I see the problem. The C++ invocation syntax (basically the difference between expressions and statements inherited from Algol) makes it impossible to call if you want to update it at runtime.

You could declare `static static_map<>::Value& get()` constexpr. (Actually you wouldn't need to; I think you could simply declare `semi::map<>::get()` to be constexpr) and I believe it would allow calling to look up a value to inlined at compile time.

However using it as an lvalue isn't possible with current c++ syntax. As a long time Lisp programmer this limitation continually trips me up.

Sorry about the backquotes; I know that HN doesn't use MD but it was the simplest way to denote code inline.