-
Notifications
You must be signed in to change notification settings - Fork 731
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
Add string view support (only impl, no tests) #627
Conversation
Define PUGI_ENABLE_STRING_VIEW to add string_view overloads when supported by the C++ standard
src/pugixml.cpp
Outdated
@@ -5441,6 +5441,13 @@ namespace pugi | |||
return impl::strcpy_insitu(_attr->name, _attr->header, impl::xml_memory_page_name_allocated_mask, rhs, size); | |||
} | |||
|
|||
#ifdef PUGI_HAS_STRING_VIEW | |||
PUGI_IMPL_FN bool xml_attribute::set_name(const string_view_t rhs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here and elsewhere const
should not be used for arguments as they are passed by value
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is my usual style (as much const
as possible), although I would use east const.
I don't have any problems with changing this, but out of curiosity, could you elaborate on your rationale?
The fact that they are passed by value is orthogonal to the fact that the value is not changed.
And because it is not changed it can be made const
and IMHO consequently should be made const
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally do not subscribe to the "what could be made const should be" when that doesn't affect the interface; in this case, the caller behavior does not change based on whether the argument is const or not. I am aware of the argument that it can help prevent mistakes but I have not seen these happen much in practice so I view this as syntactic noise. You're welcome to disagree of course, but for consistency this const
should be removed: pugixml doesn't have a single function with a const parameter that is passed by value, and the only uses of const locals are that where the value is a compile-time const (when this code was written this seemed to enhance readability, whether this is true or not is subjective).
src/pugixml.hpp
Outdated
@@ -122,6 +122,26 @@ | |||
# endif | |||
#endif | |||
|
|||
// Detect if C++ standard supports 'string_view' (2017 or higher) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would propose simplifying this to enabling internal PUGI_HAS_STRING_VIEW define if PUGIXML_STRING_VIEW
define (note the PUGIXML
prefix; PUGI_
prefix is for internal macros, PUGIXML_
prefix is for user facing configuration) is enabled, and dropping the _SUPPORTED
macro as it does not seem to be useful.
Separately, PUGI_HAS_STRING_VIEW
should be undef'd at the end of the header.
PUGIXML_STRING_VIEW
should be added, commented out, in pugiconfig.hpp
. We can note there that the macro will become unnecessary with future versions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A question regarding consistency: PUGI_HAS_STRING_VIEW
seems to be the only macro using PUGI
prefix in the header. All others use PUGIXML
, e.g., PUGIXML_HAS_MOVE
or PUGIXML_HAS_LONG_LONG
which are auto-detected as well. PUGI
-macros can only be found in the cpp.
So shouldn't it be PUGIXML_HAS_STRING_VIEW
then?
Probably for the same reason it would be the only macro that is actually undefined in the header. (there is no #undef
to be found) So I cannot orient on anything. Should I always #undef
it even if I didn't defined it? (not that there is a #ifndef PUGI_HAS_STRING_VIEW
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apologies, I've misled you about the prefix; I forgot the conventions :) Indeed, it should be prefixed with PUGIXML_
and no undef is necessary. I mixed this up with the .cpp
file where the prefix is PUGI_IMPL_
and the macros are undef'd to not pollute the namespace in header-only mode.
This is a good isolated starting point (modulo tests and adding the define to GitHub Actions / AppVeyor config). I think it's fine to delegate to existing overloads when they are available; these details could be changed later if need be (perhaps for debug performance, although using string_view necessitates function calls in debug builds anyhow). |
This allows to conveniently opt-in to support for std::string_view
No longer define PUGI_STRING_VIEW_SUPPORTED and replace PUGI_ENABLE_STRING_VIEW with PUGIXML_STRING_VIEW
It is C++20 and likely needs <version> to be conditionally included to be defined
Regarding "adding the define to GitHub Actions / AppVeyor config", this seems to be the next step, before adding unit tests. For gcc/clang my approach seems to work, for Windows I'm not so sure: (and I can't test locally)
The warning is not new, but now it also includes |
For all of them, this should be an expansion of the existing matrix (just need to add this to defines). |
But wouldn't adding |
If you want that combination I think it can be added by adding |
You're probably right, WCHAR_MODE is not really that different when it comes to the string_view changes. |
Hi, it looks like this PR has gotten stuck. I took a stab at adapting all of the tests that were added for the char*+size versions of the functions to also test string_view, updating the cmake files, and updating the workflow files to add coverage. I am new to making open source contributions, I didn't realize that making a draft pr in my fork would add a message to this thread, sorry for the noise. Let me know if I can help in some way, like by merging any testing / cmake / build.yml changes into brandl's fork for inclusion in this PR. |
Hi @dantargz, you mentioned this PR in the description of your PR, that's what caused "the noise". |
thanks, I opened a PR against the main repo here: #633 |
Merged as #633, thanks! |
Productive implementation should be complete (restricted to the functions you mentioned for a first PR) but there are no tests yet.
So this is intentionally only a draft to get quick review on the implementation. Despite the limited scope there are still many choices and you might want those differently. Examples are:
string_view_t
via a type alias since we already know this is supported or usetypedef
to stay consistent withchar_t
etc.?I will add tests soon and then publish the PR.