Date: Thu, 15 Aug 2019 07:12:57 -0400
Execution encoding is a term we use in conversation, it's not actually a
term in the standard. The standard speaks of execution character sets, the
values of which are determined by locale. Which locale is not specified.
On Wed, Aug 14, 2019, 23:21 Tom Honermann via Core <core_at_[hidden]>
wrote:
> On 8/14/19 10:57 AM, Peter Dimov wrote:
> > Tom Honermann wrote:
> >> On 8/14/19 3:54 AM, Peter Dimov wrote:
> >>> Tom Honermann wrote:
> >>>
> >>>> I think we *might* be successful in using "execution encoding" to
> >>>> apply to both the compile-time and run-time encodings by extending the
> >>>> term with specific qualifiers; e.g., "presumed execution encoding" and
> >>>> "run-time/system/native execution encoding".
> >>> This would be implying that there's a single "execution" or "native"
> >>> encoding, whereas there are many.
> >>>
> >>> - encoding used for character literals
> >> I made the "presumed execution encoding" distinction specifically for
> this
> >> case.
> > Right, and I am saying that calling all the encodings "<adjective>
> execution
> > encoding" implies that they are if not the same, then somehow related,
> and
> > they aren't.
> Ok, that is a fair critique.
> >
> > I would call the encoding used for narrow character literals "narrow
> literal
> > encoding" and the encoding used for wide character literals "wide literal
> > encoding". This is what they are.
>
> I feel some reluctance to changing a term that has been around for so
> long, and this strikes me as too specific. There are other constructs
> that are also encoded according to the (presumed) execution encoding.
> For example source locations exposed via the __FILE__ macro, function
> names exposed via __func__, etc..
>
> We don't know at compile-time how encoded literals will be used at
> run-time. They may be passed to the locale sensitive character
> conversion functions, used as filenames, written to a terminal, etc...
> All of these encodings are not known until run-time. I kind of like the
> use of "presumed execution encoding" as indicating a compatible subset
> of all of the encodings used at run-time.
>
> >
> > "Execution encoding" made sense when a program was, say, written in
> > Krasnoyarsk and intended to be executed in Kuala Lumpur. A Krasnoyarsk
> > machine used the Krasnoyarsk encoding for everything, and a Kuala Lumpur
> > machine used the Kuala Lumpur encoding for everything. Hence source and
> > execution.
>
> It still very much makes sense when cross-compiling today.
>
> Tom.
>
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2019/08/7062.php
>
term in the standard. The standard speaks of execution character sets, the
values of which are determined by locale. Which locale is not specified.
On Wed, Aug 14, 2019, 23:21 Tom Honermann via Core <core_at_[hidden]>
wrote:
> On 8/14/19 10:57 AM, Peter Dimov wrote:
> > Tom Honermann wrote:
> >> On 8/14/19 3:54 AM, Peter Dimov wrote:
> >>> Tom Honermann wrote:
> >>>
> >>>> I think we *might* be successful in using "execution encoding" to
> >>>> apply to both the compile-time and run-time encodings by extending the
> >>>> term with specific qualifiers; e.g., "presumed execution encoding" and
> >>>> "run-time/system/native execution encoding".
> >>> This would be implying that there's a single "execution" or "native"
> >>> encoding, whereas there are many.
> >>>
> >>> - encoding used for character literals
> >> I made the "presumed execution encoding" distinction specifically for
> this
> >> case.
> > Right, and I am saying that calling all the encodings "<adjective>
> execution
> > encoding" implies that they are if not the same, then somehow related,
> and
> > they aren't.
> Ok, that is a fair critique.
> >
> > I would call the encoding used for narrow character literals "narrow
> literal
> > encoding" and the encoding used for wide character literals "wide literal
> > encoding". This is what they are.
>
> I feel some reluctance to changing a term that has been around for so
> long, and this strikes me as too specific. There are other constructs
> that are also encoded according to the (presumed) execution encoding.
> For example source locations exposed via the __FILE__ macro, function
> names exposed via __func__, etc..
>
> We don't know at compile-time how encoded literals will be used at
> run-time. They may be passed to the locale sensitive character
> conversion functions, used as filenames, written to a terminal, etc...
> All of these encodings are not known until run-time. I kind of like the
> use of "presumed execution encoding" as indicating a compatible subset
> of all of the encodings used at run-time.
>
> >
> > "Execution encoding" made sense when a program was, say, written in
> > Krasnoyarsk and intended to be executed in Kuala Lumpur. A Krasnoyarsk
> > machine used the Krasnoyarsk encoding for everything, and a Kuala Lumpur
> > machine used the Kuala Lumpur encoding for everything. Hence source and
> > execution.
>
> It still very much makes sense when cross-compiling today.
>
> Tom.
>
> _______________________________________________
> Core mailing list
> Core_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/core
> Link to this post: http://lists.isocpp.org/core/2019/08/7062.php
>
Received on 2019-08-15 13:13:11