ValueDescriptionByValue with new API

[mf01]

How can I retrieve a signals ValueDescription with the nbew API?
Formally I use sig.ValueDescriptionByValue(value)

[xR3b0rn]

The new API encourages the use of STL algorithms. I.e. in your specific case, you can do it that way:

auto beg = sig.ValueEncodingDescriptions().begin();
auto end = sig.ValueEncodingDescritpions().end();
auto iter = std::find_if(beg, end, [value](const IValueEncodingDescription& ved) { return vec.value() ==  value; });
if (iter != end)
{
  const std::string& value_description = iter->Description();
}

[mf01]

Thank you for your fast answer. The sample code works. But I propose to implement the old ValueDescriptionByValue(value) as convenient way to access the description. This would reduce the boiler plate code for the library user.

While using this sample code another issue occures:

auto value = sig.Decode(buffer); // Decode() return a  raw_t which is a uint64_t
auto beg = sig.ValueEncodingDescriptions().begin();
auto end = sig.ValueEncodingDescritpions().end();
auto iter = std::find_if(beg, end, [value](const IValueEncodingDescription& ved) { return vec.value() ==  value; }); // IValueEncodingDescription::Value() return an int64_t instead of raw_t or uint64_t. 
if (iter != end)
{
  const std::string& value_description = iter->Description();
}

This code has a comparison with different signness. Is there a reason for the different types?

[xR3b0rn]

I consider to add such functions (ValueDescriptionByValue(value)) in future versions of dbcppp, however at the moment, you have to stick with the std::find_if-solution. To reduce the boiler plate in your code, you may write small helper functions or lambda-expressions.

Since the raw_t is unuseable without the information about the signedness of the value type behind raw_t, the return type of Decode is randomly choosen. The type information is then hidden in the RawToPhys- function. However, if you use RawToPhys on a value you later want to use in conjunction with a ValueEncodingDescription, you will end up in comparing a double using ==, what is never a good idea. So it has to be done the way you do it.

Hence you indeed found a flaw in the library. The workaround for this is to reinterpret_cast the raw_t value to the correct type:

auto value = sig.Decode(buffer); // Decode() return a  raw_t which is a uint64_t
auto beg = sig.ValueEncodingDescriptions().begin();
auto end = sig.ValueEncodingDescritpions().end();
auto iter = std::find_if(beg, end, [value](const IValueEncodingDescription& ved) { return vec.value() ==  reinterpret_cast<const int64_t&>(value); });
if (iter != end)
{
  const std::string& value_description = iter->Description();
}

In future releases, dbcppp should provide a function which hides the reinterpret_cast.