Added type_id() & type_size() methods to the cetl::unbounded_variant. #verification #docs #sonar

[serges147]

No description provided.

[pavel-kirienko]

After the special case is removed it should be good to go

The base branch was changed.

[thirtytwobits]

These lambdas may fail on systems with no heap and a deficient small-value-optimization in std::function. Please use function pointers to avoid this.

[serges147]

I don't think so, they are just pure (implicitly generated) static functions, they don't capture anything (neither any of outside vars nor this), only Tp type information - so no allocation. sizeof of them is 1 (should kinda be zero but as you know even empty struct sizeof is 1). And the fact that I can just assign them to a simple pointer to function (see value_const_converter_ declaration below) proves it - as soon as add anything to the capture list such assignments won't compile anymore.

Here is sizeof of this lambda:

        using Xxx = decltype([](const void* const storage, const cetl::type_id& dst_type_id) {
            CETL_DEBUG_ASSERT(nullptr != storage, "");
            const auto        ptr     = static_cast<const Tp*>(storage);
            const void* const dst_ptr = ptr->_cast_(dst_type_id);
            return std::make_pair(dst_ptr, cetl::type_id_value<Tp>);
        });
        static_assert(sizeof(Xxx) == 1);

[serges147]

In addition, although I could technically make explicit template static member functions for convertors, I'm reluctant todo so b/c:

1. There will be 4 of them (see two mutually exclusive versions of make_converters).
2. They all will be out of make_converters context.
3. make_converters is the only supposed entity to reference them; and of course nobody is allowed to call them directly (only indirectly via value_[mut|const]_convertor_ function pointers). So, in some sense I believe am doing proper isolation here without introducing any indeterministic behavior (including memory allocations).
4. We also have other function pointer members initialized with lambdas in a similar manner (and isolation!), like value_destroyer_, value_copier_ and value_mover_.
5. Debugging is not affected - breakpoints or stepping into such lambdas perfectly works.

[serges147]

Furthermore, I scanned AUTOSAR14 spec, and found no lambda rule against my implementation. The only remotely applicable rule is the following:

Rule A5-1-6 (advisory, implementation, automated)
Return type of a non-void return type lambda expression should be
explicitly specified.

I can fix it.

[serges147]

done - see commit

[pavel-kirienko]

To back up what Sergei said:

[sonarqubecloud]

Quality Gate failed

Failed conditions
22.8% Coverage on New Code (required ≥ 90%)

See analysis details on SonarCloud

[thirtytwobits]

Looks good. Thanks.