#6874 closed Feature Requests (fixed)
Path should have a size() member function
Reported by: | Owned by: | Beman Dawes | |
---|---|---|---|
Milestone: | To Be Determined | Component: | filesystem |
Version: | Boost 1.49.0 | Severity: | Problem |
Keywords: | path size | Cc: |
Description
It would be convenient for filesystem::path to provide a size() member function, especially for circumstances that require interface with legacy windows apps and functions.
Consider the traditional windows path buffer:
wchar_t legacy [_MAX_PATH];
and a boost path:
boost::filesystem::path path = L"<...>";
In order to ensure that buffer overruns do not occur when copying into a legacy buffer, assuming that querying the size of the wstring() member function is the same as the c_str() size, code similar to the following is required:
if (path.wstring().size()+1 <= _MAX_PATH) { wcscpy(&legacy[0], path.c_str()); } else { // buffer would overrun, do something else ... }
It would be more convenient, and arguably safer, if filesystem::path provides the size of the string that is referenced by the c_str() function.
if (path.size()+1 <= _MAX_PATH) { wcscpy(&legacy[0], path.c_str()); } else { // buffer would overrun, do something else ... }
Change History (2)
comment:1 by , 7 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 by , 7 years ago
My only concern was that there might be confusion with the number of elements that would be found if the path were iterated over.
Then, how about renaming to length
?
(... well, std::string
has both size
and length
member functions.)
</bikeshed>
I've wished for this several times, too.
My only concern was that there might be confusion with the number of elements that would be found if the path were iterated over. That concern didn't seem serious enough to derail the proposal.
Thanks,
--Beman