Class template argument deduction in Rack?

Development
1

Hi,

for what I know, Rack use c++11 as language/version. But I see on many struct within the native code, that’s its using Class template argument deduction (which exist only for c++17):

How that’s possible? I can’t compile my modules using:

template <typename T = float>

It correctly says note: class template argument deduction is only available with ‘-std=c++17’ or ‘-std=gnu++17’.

Some workaround used by @Vortico on compiling? I’d like to use this language feature…

2

Defaulting isn’t deduction is it? You should be able to use tschmidtdtigger as long as you <> with 11 I think.

But many of us just turn on 17 in our plugin. The toolchain supports it with a couple of libc exceptions . Add it to cxx flags before you include plugin.mk and filter it out after.

3

Is that legit? :open_mouth:

4

yes

5

Note that rack requires you to build back to macOS 10.9 (which has been unsupported since 2017) and a few edges of C++17 are implemented in libc rather than headers. So you have to make sure to use the rack std::filesystem and also be a bit careful with optional and variant. .has_value works on optional for instance but some other things like get_if don’t (if i recall).

(If rack moves to 10.13 one day you really just end up with the filesystem gap which ghc::filesystem covers and is already integrated with rack).

6

Rack has it’s own file system wrappers in ::rack::system that should be used instead of libc. The Rack wrappers handle utf8/Unicode correctly on Windows – I’m doubtful that the libc ones do – there are a number of plugins with issues for users with extended characters in their user name because of this.

7

std::filesystem has apis for this which ghc::filesystem (which rack uses) supports properly. in fact you can see that rack::system is implemented using ghc::filesystem!

you just need to do the namespace swap if you are porting code which doesn’t couple rack and uses the C++ standard. Most folks (surge, rack, loads of others) do a namespace fs=std::filesystem somewhere so then can swap it on older macOS and other older libc environments.

1 Like
8

(you are correct about the libc apis of course; but std::filesystem is libc++. And also rack.hpp replaces many of the libc apis with their own version on windows; like the fopen → fopen_u8 in common.hpp so code which includes rack.hpp is even usually safe with the commonest libc apis)

1 Like
9

So why @Vortico doesn’t fix these troubles and just swap to c++17?

10

It can be challenging to keep an ecosystem of developers moving forward, so changing a minimum requirement by default should have a compelling reason, not just a matter of “it would be nice”.

Opting in to 17 is documented in the manual.

1 Like
11

Can you link this to me?

12

the toolchain has supported 17 officially for a while, with the macOS caveats and ghc::filesystem workaround I mentioned.

changing rack core is harder; and upgrading minimum os and libc is harder still.

You can always inspect the docker file for the current toolchain to see what is supported and what versions of what are used.

1 Like
13

my bad - it looks like the manual hasn’t been updated to document this. (or at least, I can’t find it).

1 Like