hogliux

Long-time happy Wise business customer here (since before the name change). While generally great, their KYC flow needs serious attention. Received four document request emails simultaneously, mostly identical but with different links. In one flow, after uploading invoices, I couldn't upload other requested documents. The multiple, distinct forms asking for the same info were confusing. Got verified eventually, but the process was buggy and didn't inspire confidence. If anyone from Wise is reading this, please fix your KYC!

IMHO SOUL is a game changer in audio just like OpenGL/Direct3D/etc. was a game changer in the graphics world.

Think of all of the graphics technologies that were enabled by OpenGL/Direct3D/... and consider the equivalent for sound/music.

The trend is clearly going into the direction of application-specific processors and a lot of hardware already has dedicated DSP chips for audio. It is high time that a standard language is proposed to access them in a unified way just like OpenGL did.

Full disclosure: I worked with Jules and Cesare at ROLI/JUCE where Jules was my mentor and colleague. If anyone can pull this off, it’s them.

Hmmm, I'm not sure I understand. You can't really mark `static static_map<>::Value& get()` constexpr because it returns a value which is only known at run-time - again the value is a run-time value, only the lookup (where in memory) is at compile-time. This has nothing to do with inlining.

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.

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

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.

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.

Yup. The frozen map cannot be updated once it is initialized:

<<Once initialized, the containers cannot be updated, and in exchange, lookups are faster. And initialization is free when constexpr is used :-).>>

Thanks, I'll have a look at this!

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.

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)