Date: Sun, 12 May 2019 15:06:33 +0000
1. Just like std::array<T,N> to T[N]. Less error prone.
2. Not allowed to initialize it from nullptr_t
3. it has a name.
4. allow comparison operators == != < >
5. allow ranged based for loop for(auto const &e : cstr)
6. No overhead
7. Avoid the usages of strcmp, strncmp, strnlen
8. Tell people get size() of a cstring is linear time complexity
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Tony V E<mailto:tvaneerd_at_[hidden]>
Sent: Sunday, May 12, 2019 23:01
To: sotrdg sotrdg via Std-Proposals<mailto:std-proposals_at_[hidden]>; std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: sotrdg sotrdg<mailto:euloanty_at_[hidden]>
Subject: Re: [std-proposals] My proposal of std::basic_cstring<__char_type, __traits>
What's the advantage of your class over char *?
Sent from my BlackBerry portable Babbage Device
From: sotrdg sotrdg via Std-Proposals
Sent: Sunday, May 12, 2019 10:14 AM
To: std-proposals_at_[hidden]
Reply To: std-proposals_at_[hidden]
Cc: sotrdg sotrdg
Subject: [std-proposals] My proposal of std::basic_cstring<__char_type, __traits>
There was a proposal std::basic_cstring_view. However, the proposal claimed a cstring_view with sized version is aka “better choice” than no-sized version.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf
I disagree with this proposal.
1. ABI breaking/Backward compatibility
People cannot switch to cstring_view when they store their char const* in the structs/classes because the layout of struct would change, which means even you have cstring_view, you cannot kill the use cases of char const*. The c-style string will just exist forever.
struct legacy_structure
{
char const* str;
std::size_t s;
};
2. The reason people are using c_str() is to pass parameters towards c interface.
For example:
std::string str(“abc.txt”);
FILE *fp = fopen(str.c_str(),”w”); //ignore exception safety issues here.
Suppose, we are using std::cstring_view, it solves nothing and only makes the problem worse since we have to pay extra theta(n) cost for reading the size. It brings zero advantages over neither std::basic_string_view, nor std::basic_view.
3. What is the point of making cstring_view which did exactly the same thing string_view could do? What real advantages could cstring_view bring? It is impossible to ensure ‘\0’ for the sequence as well, just like string_view. Also would people just abolish string_view when they could just use cstring_view? (because they could be potentially misleading cstring_view is “better”)
4. What does this call std::cstring_view, not just std::cstring? I do think the standard library requires a minimum interface for c_str(), not some kinds of “view”. Calling it cstring_view is pretty hard to differentiate it with string_view.
Here is our proposal with source code.
We need a minimum interface for wrapping c style string. Here are our design goals:
1. The class is to provide a generic interface for different string classes in order for passing through C APIs, no other purposes.
2. Unlike std::basic_string or std::basic_string_view. The std::basic_cstring provides As few APIs as possible (to ensure security). No no start_with(), no back(), no size(), no find(), no substr(), remove_suffix() etc.
3. No its unique string literals.
4. No hash function,
5. Reduce potential usages of c-style string APIs such as strcmp, strlen, strncmp, strnlen,
6. end() should be a special iterator type.
7. all operations are constexpr
8. It does not rely on std::basic_string,std::basic_string_view. The cstring_view auto-detects any char sequences class with v.data() through C++20 concepts lite.
For example:
std::vector<char> vec(4,'a');
vec.back()=0;
std::experimental::cstring svv(vec);
9. No std::ostream support. Use template for outputing cstring instead. This would reduce the reliance of std::ostream&. We do not need #include<ostream> which would greatly reduce compilation time
template<typename __ostrm,typename __char_type,typename __traits>
inline decltype(auto) operator<<(__ostrm& __os,basic_cstring<__char_type,__traits> const & __a)
{
return __os<<__a.c_str();
}
I’ve provided my implementation of std::basic_cstring_view in the attachments.
Sent from Mail for Windows 10
2. Not allowed to initialize it from nullptr_t
3. it has a name.
4. allow comparison operators == != < >
5. allow ranged based for loop for(auto const &e : cstr)
6. No overhead
7. Avoid the usages of strcmp, strncmp, strnlen
8. Tell people get size() of a cstring is linear time complexity
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10
From: Tony V E<mailto:tvaneerd_at_[hidden]>
Sent: Sunday, May 12, 2019 23:01
To: sotrdg sotrdg via Std-Proposals<mailto:std-proposals_at_[hidden]>; std-proposals_at_[hidden]<mailto:std-proposals_at_[hidden]>
Cc: sotrdg sotrdg<mailto:euloanty_at_[hidden]>
Subject: Re: [std-proposals] My proposal of std::basic_cstring<__char_type, __traits>
What's the advantage of your class over char *?
Sent from my BlackBerry portable Babbage Device
From: sotrdg sotrdg via Std-Proposals
Sent: Sunday, May 12, 2019 10:14 AM
To: std-proposals_at_[hidden]
Reply To: std-proposals_at_[hidden]
Cc: sotrdg sotrdg
Subject: [std-proposals] My proposal of std::basic_cstring<__char_type, __traits>
There was a proposal std::basic_cstring_view. However, the proposal claimed a cstring_view with sized version is aka “better choice” than no-sized version.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1402r0.pdf
I disagree with this proposal.
1. ABI breaking/Backward compatibility
People cannot switch to cstring_view when they store their char const* in the structs/classes because the layout of struct would change, which means even you have cstring_view, you cannot kill the use cases of char const*. The c-style string will just exist forever.
struct legacy_structure
{
char const* str;
std::size_t s;
};
2. The reason people are using c_str() is to pass parameters towards c interface.
For example:
std::string str(“abc.txt”);
FILE *fp = fopen(str.c_str(),”w”); //ignore exception safety issues here.
Suppose, we are using std::cstring_view, it solves nothing and only makes the problem worse since we have to pay extra theta(n) cost for reading the size. It brings zero advantages over neither std::basic_string_view, nor std::basic_view.
3. What is the point of making cstring_view which did exactly the same thing string_view could do? What real advantages could cstring_view bring? It is impossible to ensure ‘\0’ for the sequence as well, just like string_view. Also would people just abolish string_view when they could just use cstring_view? (because they could be potentially misleading cstring_view is “better”)
4. What does this call std::cstring_view, not just std::cstring? I do think the standard library requires a minimum interface for c_str(), not some kinds of “view”. Calling it cstring_view is pretty hard to differentiate it with string_view.
Here is our proposal with source code.
We need a minimum interface for wrapping c style string. Here are our design goals:
1. The class is to provide a generic interface for different string classes in order for passing through C APIs, no other purposes.
2. Unlike std::basic_string or std::basic_string_view. The std::basic_cstring provides As few APIs as possible (to ensure security). No no start_with(), no back(), no size(), no find(), no substr(), remove_suffix() etc.
3. No its unique string literals.
4. No hash function,
5. Reduce potential usages of c-style string APIs such as strcmp, strlen, strncmp, strnlen,
6. end() should be a special iterator type.
7. all operations are constexpr
8. It does not rely on std::basic_string,std::basic_string_view. The cstring_view auto-detects any char sequences class with v.data() through C++20 concepts lite.
For example:
std::vector<char> vec(4,'a');
vec.back()=0;
std::experimental::cstring svv(vec);
9. No std::ostream support. Use template for outputing cstring instead. This would reduce the reliance of std::ostream&. We do not need #include<ostream> which would greatly reduce compilation time
template<typename __ostrm,typename __char_type,typename __traits>
inline decltype(auto) operator<<(__ostrm& __os,basic_cstring<__char_type,__traits> const & __a)
{
return __os<<__a.c_str();
}
I’ve provided my implementation of std::basic_cstring_view in the attachments.
Sent from Mail for Windows 10
Received on 2019-05-12 10:08:16