Live data from Hacker News

C++: Associative map containers with compile-time lookup

github.com

11–20 of 45 posts

Re: C++: Associative map containers with compile-time lookup

#11
post #7

Earlier quoted context omitted.

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 t…

Not exactly as fast. Without -Bsymbolic, a global variabile with global symbol visibility gets its own GOT entry, meaning access to your global goes through an indirection table that supports ELF symbol interposition. (Which, IMHO, was a bad idea, but you can't unbreak an egg.) With a data structure like this (or with a conventional "struct globals"), there's one symbol at the ELF level to look up instead of one per…

Thanks, I'll have a look at this!

Re: C++: Associative map containers with compile-time lookup

#16
post #14

C++ is getting more and more like Lisp.

A secret cabal of Lisp programmers took over the C++ steering committee.

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

Re: C++: Associative map containers with compile-time lookup

#19
post #5
post #2

I can see how `semi::map` could be useful, but `semi::static_map` just seems to be an alternate syntax for global variables.

Yes, in a way you are right: the compiler really does boil it down to global variables. However, `semi::static_map` gives you some additional features, which may be useful for a lot of situations 1) `semi::static_map` gives you the optional run-time look-up with the same API (`semi::static_map::get`). Looking up a global variable with a runtime key isn't straight-forward. This makes it particularly nice to use an API…

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.

Re: C++: Associative map containers with compile-time lookup

#20
post #5

Earlier quoted context omitted.

Yes, in a way you are right: the compiler really does boil it down to global variables. However, `semi::static_map` gives you some additional features, which may be useful for a lot of situations 1) `semi::static_map` gives you the optional run-time look-up with the same API (`semi::static_map::get`). Looking up a global variable with a runtime key isn't straight-forward. This makes it particularly nice to use an API…

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",…

Yes, that's a nice approach. However, this approach requires you to list all your keys in advance (in the enum).

The `semi::static_map` does not require this.This is especially useful if you are writing library code: imagine you are programming a `getFont` method - you don't know with which constexpr keys your method will be called, so there is no way for you to list all these keys in an enum.

Post reply on HN