Address several warnings emitted during compilation - #41
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## develop #41 +/- ##
===========================================
+ Coverage 86.92% 86.94% +0.01%
===========================================
Files 188 188
Lines 15116 15116
Branches 1366 1363 -3
===========================================
+ Hits 13140 13142 +2
+ Misses 1976 1974 -2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| long icol[nrows] = {1111, 2222, 3333, 4444, 5555, 6666, 7777, 8888, 9999, 0}; | ||
| long bcol[nrows] = {1101, 2202, 3303, 4404, 5505, 6606, 7707, 8808, 9909, 0}; | ||
| char scol[nrows][3 * sizeof(double)] = {0}; | ||
| char scol[nrows][3 * sizeof(double)]{}; |
There was a problem hiding this comment.
These are not the same.
= {} should zero-initialise the memory. Please check if that makes a difference in this case. And if so, you need to provide a mechanism to do the zeroing.
There was a problem hiding this comment.
They behave identical with c++11 and later.
Both are aggregate initialization. = {0} is actually ={{0}} due to brace elision and initializes scol[0][0] to 0. Then copy list initialization is used for the remaining elements, which are value initialized.
char[3][4]{} is also an aggregate initialization with an empty init-list, so the same rule as above is applied for all elements:
Otherwise, if the initializer list has no elements, the object is value-initialized.
See also:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf
11.6.1 / 11-12 pag2 226/227
11.6.4 / 3.10 page 234
| #include "eckit/log/Log.h" | ||
| #include "eckit/thread/ThreadSingleton.h" | ||
| #include "eckit/utils/StringTools.h" | ||
| #include "eckit/utils/Literals.h" |
There was a problem hiding this comment.
This definitely requires a bump to the minimum version of eckit, in the CMakeLists.txt.
4938249 to
631b7ff
Compare
631b7ff to
cf4e20f
Compare
| std::vector<size_t> lastDecoded(ncols, 0); | ||
| double decodeBuffer[maxDoublesDecode]; | ||
|
|
||
| std::vector<double> decodeBufferVec(maxDoublesDecode); |
There was a problem hiding this comment.
Is this really a change we want to make. This shifts having the decode buffer from being on the stack to in the heap.
|
|
||
| long missing_integers[nrows]; | ||
| cycle_longs(missing_integers, nrows, integer_pool, integer_pool_size); | ||
| std::vector<long> missing_integers(nrows); |
There was a problem hiding this comment.
No particular objection to this, but is there a reason to make this change?
3 participants
📖 Documentation 📖
https://sites.ecmwf.int/docs/dev-section/odc/pull-requests/PR-41