Every single (Frame)SvgItem would creates its own Units instance which in turn would create a property map for icon sizes and lots of other stuff. Avoid this.
Details
- Reviewers
davidedmundson markg - Group Reviewers
Plasma - Commits
- R242:56773014e157: Introduce Units singleton
I no longer get a tonne of Units objects created
Diff Detail
- Repository
- R242 Plasma Framework (Library)
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
src/declarativeimports/core/units.cpp | ||
---|---|---|
61 | Remove this line if you go for the comment i made below. | |
97–103 | I think you need to do more, or rather less. Units &Units::self() { static Units units; return units; } And done. It gives you a thread safe singleton (which your current version isn't). Also, why use "self" as getter for a singleton? I think "instance" or "getInstance" is the most used name for this, but i might be wrong here. | |
src/declarativeimports/core/units.h | ||
122 | Add documentation please. | |
185–186 | If this were pre C++11, you'd be done :) Units(Units const&) = delete; // Copy construct Units(Units&&) = delete; // Move construct Units& operator=(Units const&) = delete; // Copy assign Units& operator=(Units &&) = delete; // Move assign I'd drop the Q_DISABLE_COPY and go for the above "= delete" lines, but that's up for you to decide. You have to add them for move semantics anyway (Q_DISABLE_COPY does not do that for you). | |
200 | Remove this line if you go for the comment i made below. |
I was actually thinking about using the "proper" singleton way but didn't want it to be inconsistent with everywhere else. But, yeah, I'll do that.