Take std::string_view instead of const std::string&
See #105.
Add constructor and setter overloads that take T&& parameters
E.g. if you've already got a std::string that you can move into the constructor then it's better to do that than to implicitly create a std::string_view and then to create a std::string from that view.
This impacts:
- The
ConditionalMetadata constructor
- The
File constructor
- The
Filename constructor
- The
Group constructor
- The
Location constructor
- The
MessageContent constructor
- The
Message constructor
- The
PluginCleaningData constructor
- The
PluginMetadata constructor
- The
Tag constructor
- The
Vertex constructor
PluginMetadata::SetGroup()
PluginMetadata::SetLoadAfterFiles()
PluginMetadata::SetRequirements()
PluginMetadata::SetIncompatibilities()
PluginMetadata::SetMessages()
PluginMetadata::SetTags()
PluginMetadata::SetDirtyInfo()
PluginMetadata::SetCleanInfo()
PluginMetadata::SetLocations()
I'm not sure if doing this would be worth it in practice: I don't think it would make a difference for libloot-rs, so it's a question of if LOOT would benefit. I don't think adding these overloads would be a breaking change, so they could be added any time.
Accept const std::vector<std::string_view>& in addition to const std::vector<std::string>&
This impacts:
GameInterface::SortPlugins()
GameInterface::SetLoadOrder()
- The
Group constructor
The existing functions shouldn't be replaced, because if you've already got a std::vector<std::string> then you want to avoid having to create a new std::vector from that, but if you've already got a std::vector<std::string_view> then it would be good to also avoid having to create a new std::vector from that.
Again, I don't know if this is worth it, and adding the overloads wouldn't be a breaking change.
Take
std::string_viewinstead ofconst std::string&See #105.
Add constructor and setter overloads that take
T&¶metersE.g. if you've already got a
std::stringthat you can move into the constructor then it's better to do that than to implicitly create astd::string_viewand then to create astd::stringfrom that view.This impacts:
ConditionalMetadataconstructorFileconstructorFilenameconstructorGroupconstructorLocationconstructorMessageContentconstructorMessageconstructorPluginCleaningDataconstructorPluginMetadataconstructorTagconstructorVertexconstructorPluginMetadata::SetGroup()PluginMetadata::SetLoadAfterFiles()PluginMetadata::SetRequirements()PluginMetadata::SetIncompatibilities()PluginMetadata::SetMessages()PluginMetadata::SetTags()PluginMetadata::SetDirtyInfo()PluginMetadata::SetCleanInfo()PluginMetadata::SetLocations()I'm not sure if doing this would be worth it in practice: I don't think it would make a difference for libloot-rs, so it's a question of if LOOT would benefit. I don't think adding these overloads would be a breaking change, so they could be added any time.
Accept
const std::vector<std::string_view>&in addition toconst std::vector<std::string>&This impacts:
GameInterface::SortPlugins()GameInterface::SetLoadOrder()GroupconstructorThe existing functions shouldn't be replaced, because if you've already got a
std::vector<std::string>then you want to avoid having to create a newstd::vectorfrom that, but if you've already got astd::vector<std::string_view>then it would be good to also avoid having to create a newstd::vectorfrom that.Again, I don't know if this is worth it, and adding the overloads wouldn't be a breaking change.