Add C++ plugin support and example class random-choice-generator()

[alltilla]

This PR adds support for creating C++ plugins

Internal API breaking changes

• lib/templates: Public field LogTemplate::template has been renamed to LogTemplate::template_str.
• lib/logmsg: Public field LogMessage::protected has been renamed to LogMessage::write_protected.

C++ helper headers: compat/cpp-start.h and compat/cpp-end.h

Starting your C++ header with #include "compat/cpp-start.h" and ending it with #include "compat/cpp-end.h" helps you with two things:

• You will be able to include C headers.
• C files will be able to include your C++ header.

Limitations

• Obviously you can only write code in your C++ header which is syntactically correct in a C code, so you cannot define classes, etc. Do these in either your .cpp file or in a separate .hpp file, which does not get included in your C code.
• As we are not preparing each C header to be includable in C++ code, but we are trying to include them with these helpers on the call site, we cannot be sure that any additional C header include will work. This adds a level of uncertainty to developing a plugin in C++.

If you find a C header that cannot be imported to C++ with these helpers, please try to fix those headers first. If it is not possible, extend this file with a workaround so others do not run into that issue again.

C++ plugin best practices

• Minimize the C++ code in your plugin, if you can write and build/link something as C code, do so, for example boilerplates: parser.{c,h} and plugin.c. This minimizes the chance of including an incompatible C header.
• Build/link the C++ code as C++ separately and link to that from your C lib. Adding -lstdc++ to LIBADD is neccessary in this case as it is automatically added while linking the C++ object itself, but not when linking to the C++ object from a C lib.
• In your C++ code it is not possible to derive from a C class in the usual C way by adding a super field and filling its free_fn, because we do our own reference counting and freeing logic and we cannot rely on the casting trick of struct packing. You can create a struct in the usual C inheritance way and have a pointer to your C++ class in it and you can store a pointer to this struct in your C++ class as super, so you can access its fields. You can set the necessary virtual functions with wrapper functions of your real C++ functions in the ctor of the C style "class" == struct.

You can see an example usage of the C++ plugin support at: modules/examples/sources/random-choice-generator.

Build

By default C++ plugins are built if a C++ compiler is available. It is possible to disable it manually:

• autotools: ../configure --disable-cpp
• cmake: cmake -DENABLE_CPP=Off ..

On MacOS, the C++ support is disabled. See: #4484 (comment)

Example plugin: random-choice-generator()

It is added to demonstrate the C++ plugin support.

It chooses a random value from the values set in choices() and generates a message from it.

Minimal config:

source s_random_choice {
  random-choice-generator(choices("foo" "bar" "baz"));
};

Signed-off-by: Attila Szakacs attila.szakacs@axoflow.com

[kira-syslogng]

Build FAILURE

[bazsi]

Maybe we could derive this from the source driver directly.

Maybe we would have an issue with the destructor side (as we need to be able to free this from the c side as the ref count gets to zero).

[alltilla]

I came to the conclusion that there would be problems on both ctor and dtor side if we derived directly, but it was a busy day, so I will think this through again tomorrow.

[MrAnno]

g++ and gcc pack structs differently.
I haven't checked the standard yet, but inheriting a C struct from C++ is not straight-forward as far as I remember.

Virtual functions will be a problem too (especially the destructor).

[alltilla]

macOS tries to include the VERSION file in the root dir:

In file included from modules/examples/sources/random-choice-generator/random-choice-generator.cpp:23:
In file included from /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/string:532:
In file included from /Applications/Xcode_14.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/v1/string_view:199:
./version:1:1: error: expected unqualified-id
4.2.0

The only solution I have seen is to rename the VERSION file to VERSION.txt. I don't want to do that, as there are a lot of scripts in different repos, which depend on the VERSION file. I disabled the C++ support on macOS by default.

[kira-syslogng]

Build FAILURE

[MrAnno]

LGTM so far, exciting 👍

[alltilla]

• Rebased to master.
• Added comments to compat/cpp-start.h and compat/cpp-end.h.
• Added newsfiles.

[alltilla]

Added cmake support.

New commits:

• nvtable,serialize: fix signed comparison warnings
• cmake: add ENABLE_CPP option
• cmake: do not enable some warnings for C++ if not available

Changes were amended to random-choice-generator: add C++ example class:

• added a cast in the usleep() call
• completed CMakeLists.txt