C++: Associative map containers with compile-time lookup
1–10 of 45 posts
Re: C++: Associative map containers with compile-time lookup
#2I can see how `semi::map` could be useful, but `semi::static_map` just seems to be an alternate syntax for global variables.
Re: C++: Associative map containers with compile-time lookup
#3I can see how `semi::map` could be useful, but `semi::static_map` just seems to be an alternate syntax for global variables.
But somehow slower! "In fact, when using semi::static_map and looking up a value with C++ literal as a key, then the value lookup is nearly as efficient as looking up a global variable."
Re: C++: Associative map containers with compile-time lookup
#4CppCon has super interesting content. That comes from a person who has written maybe two dozen lines of C++ code, mostly just hello world. E.g. this talk by Matt Godbolt or anything by Chadler Carruth.
Re: C++: Associative map containers with compile-time lookup
#5I 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 where a function might take either a compile-time or run-time key. I'm thinking a Font API with a `getFont` method, for example. The way you use the method is the same regardless if you are using a compile-time key or not.
2) `semi::static_map` also gives you control over the lifetime of the objects. For example, it's easy to delete all the values in the map at once. Again, this is not straight-forward to do with a bunch of globals.
3) the keys are also values themselves and it's straight-forward to evaluate them at run-time. Printing the name of a global variable, for example, requires all sorts of hackery.
4) you do not need to know all your keys in advance. Simply using getFont with a unique constexpr key will create a new global variable.
Edit: added point (4)
Re: C++: Associative map containers with compile-time lookup
#6I can see how `semi::map` could be useful, but `semi::static_map` just seems to be an alternate syntax for global variables.
[deleted]
Re: C++: Associative map containers with compile-time lookup
#7I can see how `semi::map` could be useful, but `semi::static_map` just seems to be an alternate syntax for global variables.
But somehow slower! "In fact, when using semi::static_map and looking up a value with C++ literal as a key, then the value lookup is nearly as efficient as looking up a global variable."
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.
Re: C++: Associative map containers with compile-time lookup
#8are there fundamental differences with https://github.com/serge-sans-paille/frozen ?
Re: C++: Associative map containers with compile-time lookup
#9Earlier quoted context omitted.
But somehow slower! "In fact, when using semi::static_map and looking up a value with C++ literal as a key, then the value lookup is nearly as efficient as looking up a global variable."
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 variable, so your code might end up doing fewer GOT lookups.
The last paragraph was just arcana though. You should be passing -fvisibility=hidden and explicitly exporting from your DSO only the symbols you might legitimately expect some other DSO to use, obviating the issue.
Re: C++: Associative map containers with compile-time lookup
#10are there fundamental differences with https://github.com/serge-sans-paille/frozen ?
The map is not frozen.