Date: Wed, 28 Aug 2019 17:44:03 -0400
On Wed, Aug 28, 2019 at 3:05 PM Hyman Rosen via Std-Discussion <
std-discussion_at_[hidden]> wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Krystian Stasiowski via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> > The right way to define this is to say that objects have a value
>> representation consisting
>> of a fixed subset of the bits of their object representation, and that
>> the value of an object
>> is the sequence of bits in the value representation.
>>
>> Not quite, while the value representation of an trivially copyable type
>> will appear in the object representation, for an object of non-trivially
>> copyable type, the value is a user established thing: such as
>> `std::string`, since it has a pointer to external data.
>>
>
> Not not quite. Pick your own words if you want, but we should have one
> word
> for the contents of the value representation and another for the
> "user-established
> thing". I like "same" for the former and "equal" for the latter, so two
> std::string
> objects are the same if they point to the same external data (makes more
> sense
> for string views), and are equal if they point to identical sequences of
> characters.
>
What is the value in having a word for "has the same bits", when almost
nothing in the language cares about having the same bits?
If we do have a word for it, should it use a short and generic word like
"same", or something more specific? (ie "bitwise-equal"?)
This conversation started with a wording question/suggestion that revolves
around the word "value".
I asked:
> Are you then going to continue, and define what value is?
I should have probably not just asked a question in such a "Socratic"
manner. (ie Hoping the question would reveal larger insights.)
I should probably have said:
About a year ago, I tried to understand what "value" means in the
standard. The word occurs over 1000 times. I read them *all*, multiple
times.
- As you can imagine, it wasn't entirely clear, and possibly inconsistent.
- The library usage is less clear than core. Library tends to mean "==".
Or maybe "consistent with ==".
- Core tends to mean "the number that is being represented". int x = 1
means x has the mathematical value of 1. And double y = 1.0 has the same
value. We don't define what 1 is, we rely on math for that. (And it is very
tricky, see Gottlob Frege's "The Foundations of Arithmetic" (1884) for a
great, but failed, attempt at defining 1.) See also Stepanov's EoP for
some fundamental definitions.
My conclusion would be that it would be really hard to define "value" in
the standard, in a useful way that is consistent with most of the current
uses of "value".
At the same time, the beauty of C++ is that we can raise our thinking to
the level of "value", and implement our own classes with their own meaning
of value. As long as the class's definition of value is sensible,
everything falls into place - the STL works as expect, as does the core
language, etc.
I don't think the definition of value has much, if anything, to do with
bits.
std-discussion_at_[hidden]> wrote:
> On Wed, Aug 28, 2019 at 2:53 PM Krystian Stasiowski via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> > The right way to define this is to say that objects have a value
>> representation consisting
>> of a fixed subset of the bits of their object representation, and that
>> the value of an object
>> is the sequence of bits in the value representation.
>>
>> Not quite, while the value representation of an trivially copyable type
>> will appear in the object representation, for an object of non-trivially
>> copyable type, the value is a user established thing: such as
>> `std::string`, since it has a pointer to external data.
>>
>
> Not not quite. Pick your own words if you want, but we should have one
> word
> for the contents of the value representation and another for the
> "user-established
> thing". I like "same" for the former and "equal" for the latter, so two
> std::string
> objects are the same if they point to the same external data (makes more
> sense
> for string views), and are equal if they point to identical sequences of
> characters.
>
What is the value in having a word for "has the same bits", when almost
nothing in the language cares about having the same bits?
If we do have a word for it, should it use a short and generic word like
"same", or something more specific? (ie "bitwise-equal"?)
This conversation started with a wording question/suggestion that revolves
around the word "value".
I asked:
> Are you then going to continue, and define what value is?
I should have probably not just asked a question in such a "Socratic"
manner. (ie Hoping the question would reveal larger insights.)
I should probably have said:
About a year ago, I tried to understand what "value" means in the
standard. The word occurs over 1000 times. I read them *all*, multiple
times.
- As you can imagine, it wasn't entirely clear, and possibly inconsistent.
- The library usage is less clear than core. Library tends to mean "==".
Or maybe "consistent with ==".
- Core tends to mean "the number that is being represented". int x = 1
means x has the mathematical value of 1. And double y = 1.0 has the same
value. We don't define what 1 is, we rely on math for that. (And it is very
tricky, see Gottlob Frege's "The Foundations of Arithmetic" (1884) for a
great, but failed, attempt at defining 1.) See also Stepanov's EoP for
some fundamental definitions.
My conclusion would be that it would be really hard to define "value" in
the standard, in a useful way that is consistent with most of the current
uses of "value".
At the same time, the beauty of C++ is that we can raise our thinking to
the level of "value", and implement our own classes with their own meaning
of value. As long as the class's definition of value is sensible,
everything falls into place - the STL works as expect, as does the core
language, etc.
I don't think the definition of value has much, if anything, to do with
bits.
-- Be seeing you, Tony
Received on 2019-08-28 16:46:20