[
https://issues.apache.org/jira/browse/THRIFT-5497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17477465#comment-17477465
]
Richard H. Gumpertz edited comment on THRIFT-5497 at 1/17/22, 10:48 PM:
------------------------------------------------------------------------
I have three important questions:
(1) What should the *default ::apache::thrift::to_string* format be for display
blobs? embedding lots of *\x* sequences is ugly: *"\Xde\Xad\Xbe\Xef"* !!!
I'm very much leaning toward {*}X"deadbeef"{*}. One could also consider the
C++ syntax *"deadbeef"{_}X{_}* _(using syntax like a C++ _user-defined literal
operator_ ""_X, but that could conflict with an application's use of operator
""_X). Furthermore, it has a readability problem: one's eye tends not to see
the X at the end of the string; it it much more attention getting at the
beginning. PLEASE SUBMIT SUGGESTIONS!
(2) Due to unfamiliarity with the general layout of the Thrift include files, I
am a bit unsure where to put the definition of
:{*}:apache::thrift::binary_string{*}. I believe the header file Thrift.h is
the appropriate place but would very much appreciate confirmation. Any
feedback from the more experienced Thrift community?
(3) Is *::apache::thrift::to_string* used just for displaying strings to users
or is it also used in non-binary protocols for passing data? If the latter,
must any reader(s) or other functions be able to parse strings generated by
to_string? If so, which? **
Finally, here is the latest working definition of
::apache::thrift::binary_string: [^binary_string_2022.01.17_#2.h] . I believe
it may finally be fairly stable,
was (Author: JIRAUSER283319):
I have two important questions:
(1) What should the *default ::apache::thrift::to_string* format be for display
blobs? embedding lots of *\x* sequences is ugly: *"\Xde\Xad\Xbe\Xef"* !!!
I'm very much leaning toward {*}X"deadbeef"{*}. One could also consider the
C++ syntax *"deadbeef"_X* (using syntax like a C++ _user-defined literal
operator_ ""_X, but that could conflict with an application's use of operator
""_X). Furthermore, it has a readability problem: one's eye tends not to see
the X at the end of the string; it it much more attention getting at the
beginning. PLEASE SUBMIT SUGGESTIONS!
(2) Due to unfamiliarity with the general layout of the Thrift include files, I
am a bit unsure where to put the definition of
:{*}:apache::thrift::binary_string{*}. I believe the header file Thrift.h is
the appropriate place but would very much appreciate confirmation. Any
feedback from the more experienced Thrift community?
Finally, here is the latest working definition of
::apache::thrift::binary_string: [^binary_string_2022.01.17_#2.h] . I believe
it may finally be fairly stable,
> Change the C++ representation of binary be std::basic_string<unsigned_char>
> ---------------------------------------------------------------------------
>
> Key: THRIFT-5497
> URL: https://issues.apache.org/jira/browse/THRIFT-5497
> Project: Thrift
> Issue Type: Improvement
> Reporter: Richard H. Gumpertz
> Priority: Minor
> Attachments: binary_string-1.h, binary_string.h,
> binary_string_2022.01.16_#2.h, binary_string_2022.01.17.h,
> binary_string_2022.01.17_#2.h
>
>
> I would like to change the C++ representation of binary from "std::string" to
> "std::basic_string<unsigned_char>". This would allow C++ templates to
> distinguish the Thrift type "string" from "binary".
> If nothing else, ::apached::thrift::to_string could print binary differently
> than string. Currently, it can get pretty ugly when one calls printTo on a
> struct containing a binary field that has data that is not readable!
> There is an issue as to how they should be displayed by default; using
> \xDE\xAD\xBE\xEF with a \ before every byte seems ugly. Alternativlely,
> "DEADBEEF"_x because it could also be used as input if the C++ operator""_x
> is defined by the user? Alternatively just <binary> or <27-byte binary>
> (mirroring <null> for unset fields), hiding the contents? Perhaps leave
> to_string(std::basic_string<unsigned char> &value) undefined and force the
> user to define it if needed? Thoughts & suggestions???
> Given that such a change could break existing code, it should probably be
> enabled under a new thrift compiler option to --gen cpp. I haven't come up
> with a good name for such an option yet: --gen cpp:binary_as_unsigned_string
> is explicit but wordy. Any suggestions???
> I would be willing to do the work necessary to add the relevant code if there
> are no volunteers who have a better understanding of precisely what code
> would have to be updated (or at least help me find such code)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
