template <typename... Ts>
template <size_t... S0>
void DeluxeTuple<Ts...>::dump(std::ostream &OS, Seq<S0...>) const noexcept {
  STATIC_ASSERT(sizeof...(S0) == sizeof...(Ts), "inconsistent type arguments");
  OS << "{";
  (OS << ... << (" " + std::to_string(std::get<S0>(*this))));
  OS << " }";
}

Will this also work if the type of S0 is already std::string??

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8636, @btutzer wrote:

This commit introduces some doxygen warnings during the build:
[...]

I have no problem building documentation with doxygen 1.8.13. Maybe you use an older version?

The errors themselfes look like a doxygen bug: any documentation is written for a function declaration and so I do not understand how it would not match any declaration.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8688, @ewillegger wrote:

void DeluxeTuple<Ts...>::dump(std::ostream &OS, Seq<S0...>) const noexcept {

Will this also work if the type of S0 is already std::string??

Thanks; std::to_string is indeed not defined for std::string itself.
Fixed in R20:a37df9760aa6.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8796, @juhasz wrote:

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8636, @btutzer wrote:

This commit introduces some doxygen warnings during the build:
[...]

I have no problem building documentation with doxygen 1.8.13. Maybe you use an older version?

Unfortunately, I had to wipe my computer clean as after updating libstdc++ from debian experimental to be able to build ROSA I was unable to boot.
I am now using clang-6 from the backports repo, which builds rosa fine, but breaks my build with this particular branch, due to 'std::is_same_v' missing.
I searched around and found no fix for that other than installing libstdc++ from testing, and I am not doing that again... Is there a way to work around std::is_same_v? If not, please tell me what distribution you are using so I can set up a virtual machine, but I would like to avoid that very much.

I am wondering if I am the only one having issues with this. Are all others working on MSVS?

Also, I am not a fan of using bleeding-edge features that are incompatible with commonly used compilers / libstd versions. This should at least be mentioned in the build-requirements.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8834, @btutzer wrote:

Unfortunately, I had to wipe my computer clean as after updating libstdc++ from debian experimental to be able to build ROSA I was unable to boot.
I am now using clang-6 from the backports repo, which builds rosa fine, but breaks my build with this particular branch, due to 'std::is_same_v' missing.
I searched around and found no fix for that other than installing libstdc++ from testing, and I am not doing that again... Is there a way to work around std::is_same_v? If not, please tell me what distribution you are using so I can set up a virtual machine, but I would like to avoid that very much.

Oh, please do not install anything from experimental or unstable or testing just to build anything...

I am using Ubuntu on Windows 10, release Ubuntu 18.04.2 LTS. But what is important is C++17, which has (partial) support in Clang for quite some time (https://clang.llvm.org/cxx_status.html#cxx17), most features has been done in Clang 4.

RoSA should compile with Clang 4, I think the necessary features are implemented by that version. We can adjust the build scripts to recognize Clang 4 and use the proper flag to activate C++17 mode. (Note: You can use Clang in C++17 mode with the -std=c++17 option (use -std=c++1z in Clang 4 and earlier).)

As for the C++ standard library, my system has version 7.4.0 of GNU Standard C++ Library v3. I can see that Debian stable currently has version 6.3.0, but I could not find any easily-searchable documentation to check what are the differences between those two versions.

Regarding std::is_same_v, it is quite simple to not use this C++17 feature of the standard library: all std::vvv_v<VVV> in C++17 is simply std::vvv<VVV>::value with an older feature std::vvv . Similarly, std::ttt_t<TTT> in C++17 is simply typename std::ttt<TTT>::type with an older feature std::ttt.

I am wondering if I am the only one having issues with this. Are all others working on MSVS?

I have no idea what others do, but no one complained to me so far.

Also, I am not a fan of using bleeding-edge features that are incompatible with commonly used compilers / libstd versions. This should at least be mentioned in the build-requirements.

This is a standard C++ 17 feature, which is mentioned in the build-requirements.

I am not against to lock ourselfes to some minimal LLVM and libstdc++ versions (so enforcing some partial implementation of C++17).

I would of course not enforce exact versions by build scripts, but it would be everyone's responsibility to make their code build with the designated minimal versions of build tools and libraries.

I think that should be discussed as a separate issue.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8834, @btutzer wrote:

'std::is_same_v' missing.

Replaced with std::is_same in R20:06e9cd4317c1.

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8845, @juhasz wrote:

Replaced with std::is_same in R20:06e9cd4317c1.

Thanks!
I still can't build though.

/home/benedikt/repos/SoC_Rosa_port/include/rosa/deluxe/DeluxeSensor.hpp:518:12: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
  return [ this, MF ](void) noexcept {
           ^
/home/benedikt/repos/SoC_Rosa_port/include/rosa/deluxe/DeluxeSensor.hpp:580:11: note: in instantiation of function template specialization 'rosa::deluxe::DeluxeSensor::triggerHandlerFromProcessingFunction<>'
      requested here
      MFP(triggerHandlerFromProcessingFunction(std::move(MF),
          ^
/home/benedikt/repos/SoC_Rosa_port/include/rosa/deluxe/DeluxeSystem.hpp:217:20: note: in instantiation of function template specialization 'rosa::deluxe::DeluxeSensor::DeluxeSensor<rosa::deluxe::DeluxeTuple<>,
      rosa::deluxe::DeluxeTuple<int>, void>' requested here
        return new DeluxeSensor(atoms::SensorKind, Id, Name, S, std::move(MF),
                   ^
/home/benedikt/repos/SoC_Rosa_port/include/rosa/deluxe/DeluxeContext.hpp:597:27: note: in instantiation of function template specialization 'rosa::deluxe::DeluxeSystem::createSensor<rosa::deluxe::DeluxeTuple<>,
      rosa::deluxe::DeluxeTuple<int> >' requested here
  AgentHandle H = System->createSensor(Name, std::move(MF), std::move(F));
                          ^
/home/benedikt/repos/SoC_Rosa_port/include/rosa/deluxe/DeluxeContext.hpp:610:12: note: in instantiation of function template specialization
      'rosa::deluxe::DeluxeContext::createSensorImpl<rosa::deluxe::DeluxeTuple<>, rosa::deluxe::DeluxeTuple<int>, std::enable_if<true, void> >' requested here
    return createSensorImpl(
           ^
/home/benedikt/repos/SoC_Rosa_port/apps/sa-ews1/sa-ews1.cpp:110:29: note: in instantiation of function template specialization 'rosa::deluxe::DeluxeContext::createSensor<int, void>' requested here
  AgentHandle HRSensor = C->createSensor<int32_t>("HR Sensor");
                            ^
1 error generated.

I have no experience with using Lambdas in C++ so unfortunately I have no idea what you are doing here. Could you help me out?

In R20:fb3a26551f892bad0f33e42fbb10bec8a978fc88#8922, @btutzer wrote:

I still can't build though.

I've seen this kind of problem with Clang 6 in another project... Warning suppressed in R20:04dbc622e75c.