SingletonPtr: const and alignment #8354
Conversation
Make get() and operators * and -> of SingletonPtr const - they are logically const and thread-safe, despite the construction on first call. This construction is "invisible" to the caller of those methods.
platform/SingletonPtr.h
Outdated
| mutable T *_ptr; | ||
| #if __cplusplus >= 201103L | ||
| // Align data appropriately | ||
| alignas(T) mutable char data[sizeof(T)]; |
There was a problem hiding this comment.
Wrong name, should be _data.
Note that std::aligned_storage<Size, Alignement> may be used but it is actually more verbose and less readable than the current expression: mutable typename std::aligned_storage<sizeof(T), alignof(T)>::type _data; 🤦♂️
There was a problem hiding this comment.
Good spot. Also, I'm aware that this may break anyway when a C++11 switch gets thrown. It fails on ARMC5 which sets __cplusplus high enough, but does not implement alignas
I considered std::aligned_storage, but afaict it may well not work as well - you're only passing it size, not the actual type, so it has presumably has to assume that any type >= 8 bytes might need 8-byte alignment. Whereas alignas(type) can check if there are any uint64_ts or whatever in there.
I do wonder if I'm missing something, because std::aligned_storage just seems pretty redundant when you have alignas. Maybe it came first.
Be more cautious about alignment - align the data within a SingletonPtr to 8 bytes rather than 4. This could increase padding overhead by up to 8 bytes, sadly, but we may need this alignment for correct operation. Conditional check added for C++11 - if in use we can get correct minimal alignment by using alignas(T).
b635c4f to
e7815c6
Compare
|
@pan- Was that the only withholding you had? |
|
Waiting on a review by @ARMmbed/mbed-os-core |
|
/morph build |
Build : SUCCESSBuild number : 3375 Triggering tests/morph test |
Exporter Build : SUCCESSBuild number : 3010 |
Description
constFollow-up from discussion in #8001
Pull request type