Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: add SKSEPluginLoad macro and getters for plugin name etc. #24

Merged
merged 4 commits into from
Sep 9, 2023

Conversation

ThirdEyeSqueegee
Copy link
Member

No description provided.

@gottyduke
Copy link
Contributor

First, this is not "add", what you proposed it "replace" and it will break all existing plugins with current plugin API.
Second, you can't just copy them over, the plugin version struct is different. Your proposed version doesn't work.

@gottyduke
Copy link
Contributor

Last to add: there's no SFSEPlugin_Query in SFSE.
Like I stated in #21 comments: please acutally test the code locally before trying to merge into upstream.

@ThirdEyeSqueegee ThirdEyeSqueegee changed the title feat: add SKSEPluginLoad macro and PluginDeclaration struct from CLibNG feat: add SKSEPluginLoad macro and getters for plugin name etc. Sep 9, 2023
@gottyduke
Copy link
Contributor

What's the point of these getters? All of its members are public, and those exact information is also set by the plugin author oneself. Why would they need to use a getter to retrieve something that's supposed to be set-once-for-all, by themselves?

In current CLib plugin structure, the SFSEPlugin_Version is exported in main.cpp, meaning only that exact TU is able to access SFSEPlugin_Version instance.

At the end, even if a getter is useful or even required, a std::string_view among the char buffer is more suitable than std::string for avoiding unnecessary copy.

@ThirdEyeSqueegee
Copy link
Member Author

While the getters may not be strictly necessary they're definitely in "can't hurt" territory; fixed the return type so there's no unnecessary copies

@gottyduke
Copy link
Contributor

Ok, if you think the getters are good addition, consider adding proper [[nodiscard]] and const modifier for them, should any author ever uses the getter, they would not accidentally change them. Fool proof.

@ThirdEyeSqueegee
Copy link
Member Author

Good call, done!

@gottyduke gottyduke merged commit 3df4cc8 into main Sep 9, 2023
3 checks passed
@ThirdEyeSqueegee ThirdEyeSqueegee deleted the feature/macros branch September 9, 2023 18:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants