PoolEntry: Allowing new std::initializer_list in constructor #71

New Issue

muellerr · 2020-05-08T14:30:20+02:00

muellerr commented

2020-05-08 14:30:20 +02:00

The new std::initializer_list is very useful
for initializations of variable length data like
found in the global datapool. It's the perfect addition for
the global datapool.

An additional constructor would allow using
0 initialization in the global pool like shown:

/* FSFW */
poolMap->emplace(datapool::INTERNAL_ERROR_STORE_FULL, new PoolEntry<uint32_t>({0},1));
poolMap->emplace(datapool::INTERNAL_ERROR_MISSED_LIVE_TM, new PoolEntry<uint32_t>({0},1));
poolMap->emplace(datapool::INTERNAL_ERROR_FULL_MSG_QUEUES, new PoolEntry<uint32_t>({0},1));
        
/* TEST */
poolMap->emplace(datapool::TEST_BOOLEAN, new PoolEntry<bool>({0},1));
poolMap->emplace(datapool::TEST_UINT8, new PoolEntry<uint8_t>({0},1));
poolMap->emplace(datapool::TEST_UINT16, new PoolEntry<uint16_t>({0},1));
poolMap->emplace(datapool::TEST_UINT32, new PoolEntry<uint32_t>({0},1));
poolMap->emplace(datapool::TEST_FLOAT_VECTOR, new PoolEntry<float>({0, 0},2));

I also added boolean as a possible pool entry.
Problem is: if someone tries to make a boolean datapool entry
(which can very likely happen), there are weird errors that don't really
tell where the mistake is coming from. In my opinion, enforcing the non-usage of booleans should be policy-based.

The new std::initializer_list is very useful for initializations of variable length data like found in the global datapool. It's the perfect addition for the global datapool. An additional constructor would allow using 0 initialization in the global pool like shown: ```cpp /* FSFW */ poolMap->emplace(datapool::INTERNAL_ERROR_STORE_FULL, new PoolEntry<uint32_t>({0},1)); poolMap->emplace(datapool::INTERNAL_ERROR_MISSED_LIVE_TM, new PoolEntry<uint32_t>({0},1)); poolMap->emplace(datapool::INTERNAL_ERROR_FULL_MSG_QUEUES, new PoolEntry<uint32_t>({0},1)); /* TEST */ poolMap->emplace(datapool::TEST_BOOLEAN, new PoolEntry<bool>({0},1)); poolMap->emplace(datapool::TEST_UINT8, new PoolEntry<uint8_t>({0},1)); poolMap->emplace(datapool::TEST_UINT16, new PoolEntry<uint16_t>({0},1)); poolMap->emplace(datapool::TEST_UINT32, new PoolEntry<uint32_t>({0},1)); poolMap->emplace(datapool::TEST_FLOAT_VECTOR, new PoolEntry<float>({0, 0},2)); ``` I also added boolean as a possible pool entry. Problem is: if someone tries to make a boolean datapool entry (which can very likely happen), there are weird errors that don't really tell where the mistake is coming from. In my opinion, enforcing the non-usage of booleans should be policy-based.

muellerr referenced a pull request that will close this issue

2020-05-08 14:39:14 +02:00

new initializer list ctor #72

muellerr added the

feature

label 2020-05-08 14:41:34 +02:00

muellerr changed title from ~~PoolEntry: Allowing new std::initialize_list in constructor~~ to PoolEntry: Allowing new std::initializer_list in constructor

2020-05-08 14:42:10 +02:00

gaisser commented

2020-05-11 16:17:54 +02:00

The issue with boolean Pool Entries was part of the old implementation as well. I have to check how we get the compiler to tell us the error before the linker will throw a more difficult-to-understand error at us. But a linker error is still better than a run-time error.