Bug #5468
closedWt4 places short ItemDataRole enums in Wt namespace
0%
Description
The preview version of Wt4, github 3.3.6-17-gfd7099d7 places a number of identifiers in the Wt namespace that might conflict with those used by applications employing "using namespace Wt". These identifiers include User, Edit and Display. Assuming that this is not an intentional change, an attached patch temporarily places the ItemDataRole enums into a nested namespace (to facilitate testing). There are additional notes on patch.
As a note, if an application based on the Wt Auth samples incorporates: "typedef Wt::Auth::Dbo::AuthInfo AuthInfo;" in the Wt namespace along with the ItemDataRole enum (from WModelIndex.h), the g 6 compiler simply reports the issue as "error: template argument 1 is invalid".
Feedback on Wt4: Other than the reports filed, I had no serious issues porting a 5000 line app from Wt 3.6 to Wt4 preview. I've only done preliminary testing with the app, but so far it looks reasonably solid. Wt4 brings some very nice improvements!
Files
Updated by Roel Standaert over 7 years ago
- Status changed from New to InProgress
Updated by Roel Standaert over 7 years ago
The downside of turning it into an enum class was that it's supposed to be extensible.
The most straightforward option was keeping "int role" everywhere it was used, and doing it this way, with an enum in a namespace. The int is needed because it is possible to extend it to more roles. That's why we can't just turn it into an enum class. Turning it into an int would require a static_cast, which just makes it awkward to use.
There appears to be another way, though. We can turn the kind of ugly "int role" into "ItemDataRole role" by making ItemDataRole a class instead. Because all of the operations would be constexpr, it should be just as efficient as an int, anyway. I've been doing that today, and while it took more effort to write the ItemDataRole class, the end result seems to work pretty neatly when it comes to using it.
Updated by Bruce Toll over 7 years ago
That sounds like a very good solution. I look forward to trying it out. Happy New Year!
Updated by Roel Standaert over 7 years ago
- Status changed from InProgress to Resolved
- Assignee set to Roel Standaert
I've pushed the class as it is right now to GitHub. Happy New Year!
Updated by Roel Standaert over 6 years ago
- Status changed from Resolved to Closed