'is_palindrome' and 'const char*'
Hello. I have some question about some case for 'is_palindrome' algo. 'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false. But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users. So... what do you think about it? Should I implement special version for const char* or not? -- Best regards, Zaitsev Alexander
Sorry, i forgot about link. You can find this algo in Boost.Algorithm: https://github.com/boostorg/algorithm/blob/develop/include/boost/algorithm/i... -- Best regards, Alexander Zaitsev 12.08.2016, 04:00, "Зайцев Александр" <zamazan4ik@tut.by>:
Hello. I have some question about some case for 'is_palindrome' algo.
'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false.
But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users.
So... what do you think about it? Should I implement special version for const char* or not?
-- Best regards, Zaitsev Alexander
-- С уважением, Зайцев Александр.
On August 11, 2016 9:00:12 PM EDT, "Зайцев Александр" <zamazan4ik@tut.by> wrote:
Hello. I have some question about some case for 'is_palindrome' algo.
'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false.
But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users.
So... what do you think about it? Should I implement special version for const char* or not?
That certainly seems appropriate to me. -- Rob (Sent from my portable computation device.)
My feeling would be that the const char* version should be specifically disabled for the following reasons: 1. it encourages the use of unwrapped c-style strings. 2. c++17 will soon be offering string_view, which will already perform as intended. 3. not all char buffers are null-terminated. expecting the buffer to be so can be equally surprising. 4. const char* is not a Range, and it is trivial to wrap it so that it behaves like one. If disabled, the ensuing error message could even me a nicely worded string (via static_assert) that what the user is about to do is dangerous. An alternative can be suggested in the same string. Now the the function has become safe and educational. On 13 August 2016 at 03:33, Rob Stewart <rstewart@ptd.net> wrote:
On August 11, 2016 9:00:12 PM EDT, "Зайцев Александр" <zamazan4ik@tut.by> wrote:
Hello. I have some question about some case for 'is_palindrome' algo.
'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false.
But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users.
So... what do you think about it? Should I implement special version for const char* or not?
That certainly seems appropriate to me.
-- Rob
(Sent from my portable computation device.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
I agree with your point of view. I will disable const char* version with static_assert. Thanks for the answer! 14.08.2016, 05:53, "Richard Hodges" <hodges.r@gmail.com>:
My feeling would be that the const char* version should be specifically disabled for the following reasons:
1. it encourages the use of unwrapped c-style strings. 2. c++17 will soon be offering string_view, which will already perform as intended. 3. not all char buffers are null-terminated. expecting the buffer to be so can be equally surprising. 4. const char* is not a Range, and it is trivial to wrap it so that it behaves like one.
If disabled, the ensuing error message could even me a nicely worded string (via static_assert) that what the user is about to do is dangerous. An alternative can be suggested in the same string. Now the the function has become safe and educational.
On 13 August 2016 at 03:33, Rob Stewart <rstewart@ptd.net> wrote:
On August 11, 2016 9:00:12 PM EDT, "Зайцев Александр" <zamazan4ik@tut.by> wrote: > Hello. I have some question about some case for 'is_palindrome' algo. > > 'is_palindrome' algorithm checks a sequence - if sequence is a > palindromeor empty, function returns true, in other cases returns > false. > > But in case e.g. "a" (is_palindrome("a")) result is false, because "a" > = {'a', '\0'}. And maybe this behaviour is unexpected for users. > > So... what do you think about it? Should I implement special version > for const char* or not?
That certainly seems appropriate to me.
-- Rob
(Sent from my portable computation device.)
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- С уважением, Зайцев Александр.
participants (3)
-
Richard Hodges -
Rob Stewart -
Зайцев Александр