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…
C++: Associative map containers with compile-time lookup
11–20 of 45 posts
Re: C++: Associative map containers with compile-time lookup
#12Re: C++: Associative map containers with compile-time lookup
#13Re: C++: Associative map containers with compile-time lookup
#14C++ is getting more and more like Lisp.
Re: C++: Associative map containers with compile-time lookup
#15C++ is getting more and more like Lisp.
Re: C++: Associative map containers with compile-time lookup
#16Re: C++: Associative map containers with compile-time lookup
#17Re: C++: Associative map containers with compile-time lookup
#18Re: C++: Associative map containers with compile-time lookup
#19I 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…
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
#20Earlier 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",…
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.