Add * operator to SingletonPtr #8001
Conversation
Sometimes you want don't want to directly call a method on your
SingletonPtr-wrapped object, but you want to pass it to something
else.
For example
SingletonPtr<PlatformMutex> mutex;
mutex->lock();
is fine, but what about
SingletonPtr<PlatformMutex> mutex;
ScopedLock<PlatformMutex> lock(*mutex.get());
Add an overload for operator* to make this more elegant:
SingletonPtr<PlatformMutex> mutex;
ScopedLock<PlatformMutex> lock(*mutex);
This addition is consistent with standard C++ classes such as
`unique_ptr` and `shared_ptr`, which likewise have
get, operator-> and operator*.
|
@pan-, wouldn't we have both const and non-const overloads? |
|
@geky Not really, it is the type of the template parameter that determines the constness of the inner object. Consider the following code: struct foo {
int* p;
};
void update(const foo& f) {
f.p[0] = 1; // no compilation error
f.p= NULL; // compilation error
}If you look at unique_ptr, the same reasoning is applied to |
|
Oh I see! yep you're right, we should add that at some point |
|
I did consider making the methods We could make the methods Can anyone point to corresponding analogues in another standard APIs? Only thing that sprang to mind for me was "can C++14 Another thing that I've noticed is a potential alignment problem - shouldn't |
|
@kjbracey-arm : Instead of using uint64_t to get alignment (and a few bytes of overhead for increased _data size), couldn't the compiler do that by |
|
I don't believe you can use the align directives to align structure members, only top-level objects. And even the SingletonPtr itself is not necessarily a top-level object - can be embedded in a structure. Even if you could persuade it, I bet there's no toolchain support or optimisation for packing "X-aligned object with non-X-multiple size". All normal C objects must have size a multiple of alignment (so you can make arrays of them). Which in this case is unfortunate, as it will force 32 bits of padding cos the only other thing in the structure is that 32 bit pointer. Hmm, having just argued that, I realise that we could maybe do something if we could find out or deduce the alignment of T. Eg if |
|
Hmm, if we were using C++11, Not actually sure what the state of |
I've done that in the past (1, 2). I'm pretty sure that's not the kind of code we want in the OS.
I suggest we wait for language upgrade and use the maximum alignement for now as there is very few of these objects present in the codebase.
The The caller of get don't know and don't care whether or not the initialisation happen behind the scene; that's an implementation detail. |
Eeep! Let's just
Yes, but they're naturally const, really changing nothing. Here we do have a "first called, so constructed" bit of state, and that lazy initialisation is part of the overall API. But then, as you say, the caller of |
|
IAR 8.2, ARMC 5.06, GCC 6.3 all seem to digest output: |
|
/morph build |
Build : SUCCESSBuild number : 3221 Triggering tests/morph test |
Test : SUCCESSBuild number : 3024 |
|
/morph export-build |
Exporter Build : FAILUREBuild number : 2810 |
|
uvision failure - retry: |
Exporter Build : ABORTEDBuild number : 2815 |
|
/morph export-build |
Exporter Build : FAILUREBuild number : 2877 |
|
/morph export-build |
Exporter Build : SUCCESSBuild number : 2886 |
Description
Sometimes you want don't want to directly call a method on your
SingletonPtr-wrapped object, but you want to pass it to something else.For example
is fine, but what about
Add an overload for
operator*to make this more elegant:This addition is consistent with standard C++ classes such as
unique_ptrandshared_ptr, which likewise haveget,operator->andoperator*.Pull request type
Change originally proposed and discussed as part of #7924, now separated out.