Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

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

#21

Post by jstimpfle »

quotemstr wrote: post #9
hogliux wrote: 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…

Look at the approach from my other comment. Requires only 1 symbol.

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

#22

Post by hogliux »

jstimpfle wrote: post #21
quotemstr wrote: post #9

Earlier quoted context omitted.

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…

Look at the approach from my other comment. Requires only 1 symbol.

Both your approach and the `semi::static_map` will generate the same type of load instruction. In both cases, the compiler knows the offset of the values in memory at compile-time. The number of symbols is not really important here.

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

#24

Post by IshKebab »

jstimpfle wrote: post #19
hogliux wrote: 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",…

C++ doesn't support designated initialisers.

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

#25

Post by stochastic_monk »

nemoniac wrote: post #13

C++ is getting more and more like Lisp.

The functional programming concepts which have made it into C++1[147] have made programming in C++ much easier, more concise, and quite fast. I think they’re among the better recent additions to the language. Lambdas, for_each, transform, and accumulate all see regular use in my code.

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

#27

Post by jordigh »

This is a sore point for me in D. Assoc arrays in D don't work at compile time. It's a really longstanding issue:

https://issues.dlang.org/show_bug.cgi?id=1578

It's a real shame because I prefer just about everything else about metaprogramming and compile-time evaluation in D over C++.

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

#29

Post by hogliux »

sriram_sun wrote: post #28

#define ID(x) []() constexpr { return x; } Interesting! Macro substitutions can expand to anything of course. I hadn't really considered adding lambda functions to that list.

I'm looking forward to C++-20 when this is not needed anymore :-) - it will support string literals as non-type template parameters.
Post reply on HN