g++ standard choice

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.)

If you want to be in the plugin manager, you MUST use a makefile that pull in VCV’s plugin make file. That file defines all this stuff:

# Include the VCV Rack plugin Makefile framework
include $(RACK_DIR)/plugin.mk
1 Like

So, I realised the default standard can be found in ‘info g++’. It’s gnu++14.

I can’t see C++11 specified anywhere in the source. So doesn’t that mean Rack is building to C++14?

Re plugins, plugin.mk does not set --std flags.

look more closely ;-). Ok, I’ll tell you. plugins.mk includes compile.mk. compile mk says CXXFLAGS += -std=c++11

1 Like

Thanks! It’s too early in the morning here! :slight_smile:

Question answered.

1 Like

How is this enforced in the case of closed-source plugins?

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.

Or was that a rhetorical question?

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.

I’m learning. Thanks for the insight, sincerely.

np. you will find lots of helpful people here. even if some of us are a little grumpy sometimes :wink:

1 Like

Grumpy Squinky. :heart:

hey - that’s my rap name!

1 Like