"'auto' not allowed in lambda parameter column"

zeyus

I'm trying to integrate a library for realtime capture of 3D tracking data over the network...I'm starting with the most simple implementation using their library (https://github.com/qualisys/qualisys_cpp_sdk), it seems a little heavy, but maybe later I can trim it down to just the required code.

Anyway during compilation, I'm getting:

'auto' not allowed in lambda parameter column: 92, line: 6046
'auto' not allowed in lambda parameter column: 92, line: 6059
In file /usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/bits/predefined_ops.h: no matching function for call to object of type '(lambda at /root/Bela/projects/2022-09-06_sonification/qsdk/RTProtocol.cpp:6046:82)' column: 16, line: 241
In file /usr/bin/../lib/gcc/arm-linux-gnueabihf/6.3.0/../../../../include/c++/6.3.0/bits/predefined_ops.h: no matching function for call to object of type '(lambda at /root/Bela/projects/2022-09-06_sonification/qsdk/RTProtocol.cpp:6059:82)' column: 16, line: 241

The source code is here: https://github.com/qualisys/qualisys_cpp_sdk/blob/master/RTProtocol.cpp#L6046

And my current render.cpp (WIP) is here:

I'm not new to software, dev, dependency hells and all that, but C++ isn't something I've spent a lot of time with, apart from fixing some obvious bugs and a hello world or two 🙂

Is there something obvious I'm missing?

Edit: Obviously the current render is just an initial setup to test connectivity, but I'm not sure how best to capture the streaming data (and buffering if required) while respecting the realtime render function.

Maybe it will help to outline the entire conecept. I'll do it in text here then upload a little flow diagram in a few minutes.

We want to capture two objects tracked from an experiment, and we can get realtime positional data out from them... those two objects' movements will be sonified to provide auditory feedback to participants. The in parameters (velocity, object "sync" etc) and output params (amplitude, pitch, tempo) are TBD but we will likely try a few options for the experimental pilot to see what works well and is intuitive.

Edit 2: first draft flow diagram

realtime_sonification

Edit 3: just wanted to mention that I did look up some info first and saw that a) BELA operates in C++ 14 standard (https://learn.bela.io/using-bela/languages/c-plus-plus/#c-and-bela), and b) C++14 is required for generic lambdas (https://stackoverflow.com/questions/48653124/why-is-auto-not-allowed-in-lambda-parameter)

giuliomoro

zeyus BELA operates in C++ 14 standard (https://learn.bela.io/using-bela/languages/c-plus-plus/#c-and-bela),

hmmm ... that page is misleading/wrong: c++14 is fully supported by the compiler on Bela, but projects are by default built with c++11. To enable c++14, add the following to the Make parameters text box in the IDE: CPPFLAGS=-std=c++14

zeyus

giuliomoro add the following to the Make parameters text box in the IDE: CPPFLAGS=-std=c++14

Amazing, that got it compiling, now to the next step, thank you!!

Ward

giuliomoro is there a specific reason why c++14 (or an even newer c++ standard) is not enabled by default?

giuliomoro

Ward is there a specific reason why

not really ... we don't seem to need any of the most recent stuff for the core code, so that's what we have been using so far and keep using.

Ward (or an even newer c++ standard)

v0.3 images ship with clang-3.9 which has only partial support for c++-17, so that would be the most recent option available across the code base. If one is running the v0.5 images, they'd have a much more recent toolchain.

I suspect that once/if v0.5 images become officially released, we could increase the default standard for the user code, but would probably keep the core code's standard to something that can still run OK on older images (i.e.: no more recent than c++14).