Is there a preference for a particular g++ --std= flag choice when developing?
Is --std=c++17 or c++2a acceptable?
Does it matter for VCV Rack? I imagine we can mix and match, controlled by makefiles.
I never thought about this much last time I ever coded in C++ - what is the base standard g++ uses if no --std option specified (seems non obvious how to find out)?
Because Rack needs to support older operating systems/installed C++ libraries, C++11 is the latest that can be used at the moment. (If you want your plugin to be published in the VCV Library. For your private use you can of course do anything, including building Rack itself from source with the language standard and library version you want.)
Kind of how like you would imagine, right? The plugin police aren’t going to come knocking on your door. So as long as your plugins come up in every platform that you distribute them them on theu are fine. You can do anything you want as long as your plugins are ABI compatible with VCV.
Sorry, I guess what I was really asking was what the ramifications would be if using c++17 for a Rack plugin to be released in the Rack plugin library, or specifically why c++11 is required for open source plugins in the library. I thought maybe there might actually be some clear Rack-related test case for whether a compiled plugin had used the correct version of c++ or not.
Using the provided make file is part of the easy way of guaranteeing binary compatibility. As long as you are willing to take on that burden yourself, it’s fine. I don’t personally know of any reason why c++17 would break ABI. 20 seconds of googling stackoverflow tells me it’s fine.
And, of course, your compiler has to understand the VCV header files you will include.
But this is all pretty basic, I’m sure you know all this stuff.