Map out CNamePool and several related types#177
Map out CNamePool and several related types#177googleben wants to merge 8 commits intowopss:masterfrom
Conversation
wopss
left a comment
wopss
left a comment
There was a problem hiding this comment.
Thanks! I requested a few changes to the code.
Still missing one requested change, relating to the flexible array in `CNamePoolNodeInner`
|
Fixed most of what was requested, just awaiting guidance on the flexible array. Sorry about the formatting, my hook was messed up somehow, should be fixed now. |
Still missing one requested change, relating to the flexible array in `CNamePoolNodeInner`
Of note: - The flexible array `CNamePoolNodeInner::str` is now represented by a placeholder `char[1]` instead of an unsized array and can be accessed via `CNamePoolNodeInner::GetString()` - Both `CNamePoolNode` and `CNamePoolNodeInner` are now packed to an alignment of 4, matching their behavior in the game
include/RED4ext/CNamePool.hpp
Outdated
| /// @brief The corresponding string for #cname | ||
| /// This is a flexible array in the game, but because flexible arrays are a nonstandard extension, we use this | ||
| /// placeholder field plus #GetString() instead | ||
| const char str[1]; // 14 |
There was a problem hiding this comment.
Unsure what warning this produced that got mentioned in #177 (comment) but you should be able tk disable specific clang warnings per file or line with a comment, i find this hiding the meaning and just overall confusing. I would be for reverting this to older version where it was simply [] and adding comment to disable the failing clang check.
There was a problem hiding this comment.
That was a compiler error saying that this is not in the standard. I wouldn't like to disable a warning for this, even a line one, because if I'm correct both forms are not even standard behavior even in C (where this comes from).
At least this form doesn't throw a warning, even if it is undefined behavior. But if you guys decide to revert it, that's fine by me, I proposed to use this version because I'm more used it.
- CNamePoolNode is now private and moved to CNamePoolAllocator::CNamePoolNodeAllocWrapper - CNamePoolNodeInner is now CNamePoolNode - The API should hopefully be as const as possible
|
Oops, forgot to implement two functions and my build didn't fail because I wasn't building examples. Both problems now fixed 👍 |
include/RED4ext/CNamePool.hpp
Outdated
| // only the game should create this struct | ||
| CNamePoolHashmap() = delete; | ||
| // this is a singleton, so no move or copy should be allowed | ||
| CNamePoolHashmap(CNamePoolHashmap const&) = delete; |
There was a problem hiding this comment.
Use west const when possible, that seems to be the style in majority of the repo. Can see this few times.
There was a problem hiding this comment.
This should be fixed but you may want to double check.
include/RED4ext/CNamePool.hpp
Outdated
| typedef const CNamePoolNode* const value_type; | ||
| typedef std::ptrdiff_t difference_type; | ||
| typedef const CNamePoolNode* const* const pointer; | ||
| typedef const CNamePoolNode* const& reference; |
There was a problem hiding this comment.
Unsure it is really beneficial to restrict the pointers themselves to const, mainly when you dont do it everywhere. Also would probably avoid making references to pointers unless it is required, as it makes one extra indirection.
Maybe it is required for this to function properly, unsure. But seems a bit of a waste.
Could be simplified to const CNamePoolNode* m_reference
There was a problem hiding this comment.
Hm I actually see now that it seems to be the case for the above also, maybe I dont understand something about the iterators correctly overall.
There was a problem hiding this comment.
I was following what the STL specifies (as I understand it, this is way you're supposed to implement iterators, where in the past you would've extended std::iterator with all these as type arguments, which means reference needs to actually be a reference to some type). But I think I can remove a layer of indirection here now with some of the API changes - I'll look into it.
There was a problem hiding this comment.
The const pointers were meant to act as a signal that pointer arithmetic shouldn't be performed on them. I'll leave the decision on whether to change it up to y'all of course, but that's my reasoning.
4 participants
Fills out CNamePool and all its internal types (that I could figure out). There's still a bit left un-reversed but I think this covers anything you'd want to do that couldn't already be done with the existing static methods. I went ahead and tried to add Doxygen-style docs to pretty much everything cause who doesn't love documentation?