This looks really cool. Why add a different type static_map instead of using a constexpr declaration?
C++: Associative map containers with compile-time lookup
31–40 of 45 posts
Re: C++: Associative map containers with compile-time lookup
#32This looks really cool. Why add a different type static_map instead of using a constexpr declaration?
Because with a constexpr declaration everything will be constexpr, i.e. you couldn't modify the values at run-time.
The idea here is that finding the storage of the value is done at compile-time, but the values themselves are run-time values.
Re: C++: Associative map containers with compile-time lookup
#33CppCon 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. https://www.youtube.com/watch?v=bSkpMdDe4g4
Anything from Chandlery on C++ performance is worth gold.
Re: C++: Associative map containers with compile-time lookup
#34just tried C++ after some time and was set back by:
* no []= operator in custom maps
* no enum printing
* no backtrace
* other random desasters
At least they don't work without jumping through some hoops in all of your code. So for me c++ is about as fixable/appealing as Fortran.
https://stackoverflow.com/questions/3342726/c-print-out-enum...
https://stackoverflow.com/questions/691719/c-display-stack-t...
https://stackoverflow.com/questions/3581981/overloading-the-...
Re: C++: Associative map containers with compile-time lookup
#35This 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++.
You can write your own in D though.
Re: C++: Associative map containers with compile-time lookup
#36This 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++.
You can write your own in D though.
I don't know how to yet. And if this is possible, is it also possible to fix standard assoc arrays?
Re: C++: Associative map containers with compile-time lookup
#37Earlier quoted context omitted.
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.
If you don't like pointlessly repeating occurrences of identifiers, you should hardly be favoring C++.
class foo {
public:
foo();
~foo();
};
foo::foo() { }
foo::~foo() { }
Oh, but C++ can eliminate redundancy in this one cool case I'm thinking of!
Re: C++: Associative map containers with compile-time lookup
#38I can see how `semi::map` could be useful, but `semi::static_map` just seems to be an alternate syntax for global variables.
True, but I think this could really be useful for cases similar to google flags (https://github.com/gflags/gflags) wherein each file in a library adds to the global configuration. Then your main can more easy parse out these options to be shared across the entire codebase.
Re: C++: Associative map containers with compile-time lookup
#39Earlier quoted context omitted.
You can write your own in D though.
I don't know how to yet. And if this is possible, is it also possible to fix standard assoc arrays?
> is it also possible to fix standard assoc arrays?
AFAIK, yes, it's just that nobody has done that yet.
The D runtime was written before there were templates, and it shows.
Re: C++: Associative map containers with compile-time lookup
#40This looks really cool. Why add a different type static_map instead of using a constexpr declaration?
Because with a constexpr declaration everything will be constexpr, i.e. you couldn't modify the values at run-time. The idea here is that finding the storage of the value is done at compile-time, but the values themselves are run-time values.
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.