Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #119321 > unrolled thread

is "x *= ++f * ++f" a valid statement ?

Back to article view | Back to comp.lang.c++

Contents

  is "x *= ++f * ++f" a valid statement ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-05-23 16:14 +0200
    Re: is "x *= ++f * ++f" a valid statement ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-06-18 18:53 -0700
      Re: is "x *= ++f * ++f" a valid statement ? Bonita Montero <Bonita.Montero@gmail.com> - 2024-06-19 17:40 +0200
      Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 16:55 -0500
        Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-21 18:10 -0400
          Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 18:06 -0500
            Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-21 20:14 -0400
            Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 17:35 -0700
              Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 22:58 -0500
                Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-21 23:18 -0700
                  Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 07:38 -0500
                    Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 09:45 -0400
                      Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 09:13 -0500
                        Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 10:23 -0400
                      Re: is "x *= ++f * ++f" a valid statement ? PLO Mikko <mikko.levanto@iki.fi> - 2024-06-23 11:48 +0300
                    Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 17:54 -0700
            Re: is "x *= ++f * ++f" a valid statement ? PLO James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-21 23:42 -0400
              Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-21 23:02 -0500
                Re: is "x *= ++f * ++f" a valid statement ? PLO David Brown <david.brown@hesbynett.no> - 2024-06-22 13:09 +0200
                  Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 07:40 -0500
                    Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 09:56 -0400
                      Re: is "x *= ++f * ++f" a valid statement ? PLO "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-06-22 12:14 -0700
                    Re: is "x *= ++f * ++f" a valid statement ? PLO David Brown <david.brown@hesbynett.no> - 2024-06-22 16:52 +0200
                      Re: is "x *= ++f * ++f" a valid statement ? PLO olcott <polcott333@gmail.com> - 2024-06-22 11:27 -0500
                        Re: is "x *= ++f * ++f" a valid statement ? PLO Richard Damon <richard@damon-family.org> - 2024-06-22 13:20 -0400
                        Re: is "x *= ++f * ++f" a valid statement ? PLO Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 17:55 -0700
                        Re: is "x *= ++f * ++f" a valid statement ? PLO David Brown <david.brown@hesbynett.no> - 2024-06-23 14:46 +0200
                Re: is "x *= ++f * ++f" a valid statement ? PLO James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-06-22 15:48 -0400
    Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-18 22:27 -0400
    Re: is "x *= ++f * ++f" a valid statement ? olcott <polcott333@gmail.com> - 2024-06-22 21:51 -0500
      Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-06-22 21:51 -0700
      Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-23 07:32 -0400
        Re: is "x *= ++f * ++f" a valid statement ? olcott <polcott333@gmail.com> - 2024-06-23 07:59 -0500
          Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-23 14:25 -0400
            Re: is "x *= ++f * ++f" a valid statement ? olcott <polcott333@gmail.com> - 2024-06-23 14:18 -0500
              Re: is "x *= ++f * ++f" a valid statement ? Richard Damon <richard@damon-family.org> - 2024-06-23 16:23 -0400
                Re: is "x *= ++f * ++f" a valid statement ? David Brown <david.brown@hesbynett.no> - 2024-06-24 09:11 +0200
    Re: is "x *= ++f * ++f" a valid statement ? what@tf.com (testuseri2p) - 2024-07-22 17:51 +0000
      Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-22 14:58 -0700
      Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-22 21:57 -0400
        Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-22 20:40 -0700
          Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-23 10:15 -0400
          Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-23 07:28 -0700
            Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-23 14:42 -0700
              Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-07-23 15:05 -0700
                Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 06:22 -0700
                  Re: is "x *= ++f * ++f" a valid statement ? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-08-11 14:09 -0700
              Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-08-11 06:11 -0700
                Re: is "x *= ++f * ++f" a valid statement ? Chris Ahlstrom <OFeem1987@teleworm.us> - 2024-08-11 09:25 -0400
                Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-08-11 14:17 -0400
        Re: is "x *= ++f * ++f" a valid statement ? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-07-23 07:32 -0700
      Re: is "x *= ++f * ++f" a valid statement ? Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-07-22 19:53 -0700
      Re: is "x *= ++f * ++f" a valid statement ? James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-07-23 10:01 -0400

Page 3 of 3 — ← Prev page 1 2 [3]

#119722

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 7/22/24 13:51, testuseri2p wrote:
>> I'd say in simple words, if you alter a variable multiple times in one
>> statement, you get UB.
>
> The correct (and admittedly more complicated) statement of the relevant
> rule is:
> "If a side effect on a memory location (6.7.1) is unsequenced relative
> to either another side effect on the same memory location or a value
> computation using the value of any object in the same memory location,
> and they are not potentially concurrent (6.9.2), the behavior is undefined."
>
> The biggest difference between the exact rule and what you said is that
> two different updates to a variable may occur in the same statement, so
> long as they are sequenced relative to each other. Sub-expressions of an
> expression are sequenced before evaluation of the expression itself. In
> general, the sub-expressions of a expression are unsequenced, but there
> several exceptions: ||, &&, ?:, the comma operator.

"Sub-expressions of an expression are sequenced before evaluation of the
expression itself."  isn't quite correct.  What the C++ standard says is
that "The value computations of the operands of an operator are
sequenced before the value computation of the result of the operator."

In `++f * ++f`, the values yielded by the two ++f subexpressions are
determined before the "*" operator can be evaluated, but the side
effects of incrementing f (twice) can happen any time before the end of
the evaluation of the full expression.

The full expression is `x *= ++f * ++f`.  There are three side effects,
modifications to x, f, and f, and they can happen in any order.  (It's
because the two modifications of f are unsequenced that the behavior is
undefined.

`x *= ++f * ++g` would be well defined, as long as there f and g are
initialized and aren't any hidden games with any of x, f, and g being
references to the same object.  And the side effects on f and g could
happen before or after the multiplication and assignment are evaluated.

> A minor detail is that a variable must be declared, whereas memory
> locations can, for instance, be part of allocated memory for which no
> declaration exists - it is still undefined behavior to write code that
> applies unsequence side-effects to such memory locations.

Digression: I'm not even sure what "variable" means in C++.  The
standard defines the term, but not in a way that really tells us what it
means.

"A *variable* is introduced by the declaration of a reference other than
a non-static data member or of an object. The variable’s name, if any,
denotes the reference or object."

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#119727

On 7/22/24 23:40, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On 7/22/24 13:51, testuseri2p wrote:
>>> I'd say in simple words, if you alter a variable multiple times in one
>>> statement, you get UB.
>>
>> The correct (and admittedly more complicated) statement of the relevant
>> rule is:
>> "If a side effect on a memory location (6.7.1) is unsequenced relative
>> to either another side effect on the same memory location or a value
>> computation using the value of any object in the same memory location,
>> and they are not potentially concurrent (6.9.2), the behavior is
>> undefined."
>>
>> The biggest difference between the exact rule and what you said is that
>> two different updates to a variable may occur in the same statement, so
>> long as they are sequenced relative to each other. Sub-expressions of an
>> expression are sequenced before evaluation of the expression itself. In
>> general, the sub-expressions of a expression are unsequenced, but there
>> several exceptions: ||, &&, ?:, the comma operator.
>
> "Sub-expressions of an expression are sequenced before evaluation of the
> expression itself." isn't quite correct. What the C++ standard says is
> that "The value computations of the operands of an operator are
> sequenced before the value computation of the result of the operator."

Yes, you're right. I should have checked before posting. Since this rule
is about side-effects, not value computations, the sequencing provided
by that clause is irrelevant to what I was talking about. I remember
thinking that it didn't sound right, and I would probably have realized
my mistake if I'd taken a few more minutes to think about it, but I was
in a hurry to get a pair of 9-year olds to bed.

>> A minor detail is that a variable must be declared, whereas memory
>> locations can, for instance, be part of allocated memory for which no
>> declaration exists - it is still undefined behavior to write code that
>> applies unsequence side-effects to such memory locations.
>
> Digression: I'm not even sure what "variable" means in C++. The
> standard defines the term, but not in a way that really tells us what it
> means.
>
> "A *variable* is introduced by the declaration of a reference other than
> a non-static data member or of an object. The variable’s name, if any,
> denotes the reference or object."

That's the relevant clause. A declaration always declares an identifier
to be the name of the thing declared. Therefore, a memory location that
doesn't have a declared name doesn't qualify as a C variable. However,
such memory locations are still subject to the above rule.

[toc] | [prev] | [next] | [standalone]

#119728

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>> A minor detail is that a variable must be declared, whereas memory
>> locations can, for instance, be part of allocated memory for which
>> no declaration exists - it is still undefined behavior to write
>> code that applies unsequence side-effects to such memory locations.
>
> Digression:  I'm not even sure what "variable" means in C++.  The
> standard defines the term, but not in a way that really tells us
> what it means.
>
> "A *variable* is introduced by the declaration of a reference other
> than a non-static data member or of an object.  The variable's name,
> if any, denotes the reference or object."

What part do you find confusing or hard to understand?

[toc] | [prev] | [next] | [standalone]

#119733

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> [...]
>>> A minor detail is that a variable must be declared, whereas memory
>>> locations can, for instance, be part of allocated memory for which
>>> no declaration exists - it is still undefined behavior to write
>>> code that applies unsequence side-effects to such memory locations.
>>
>> Digression:  I'm not even sure what "variable" means in C++.  The
>> standard defines the term, but not in a way that really tells us
>> what it means.
>>
>> "A *variable* is introduced by the declaration of a reference other
>> than a non-static data member or of an object.  The variable's name,
>> if any, denotes the reference or object."
>
> What part do you find confusing or hard to understand?

The missing part that should tell us what a variable *is*.

It says that certain declarations "introduce" a variable.  That's a
statement about variables, but it doesn't say what a variable is.

Given:

    int n;

we know that the declaration introduces a variable.  Is the object
itself a "variable"?  That's the obvious meaning, and it's consistent
with what the standard says.  Or is a "variable" some kind of logical
binding between an object and a name?  That's also consistent with what
the standard says.  Under the latter interpretation, the "variable" has
a name, and that name denotes an object, but the variable is not the
object.

Given the above declaration, is the introduced variable an object?  If
so, or if not, how does your answer follow from what the standard says?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#119734

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> [...]
>>>> A minor detail is that a variable must be declared, whereas memory
>>>> locations can, for instance, be part of allocated memory for which
>>>> no declaration exists - it is still undefined behavior to write
>>>> code that applies unsequence side-effects to such memory locations.
>>>
>>> Digression:  I'm not even sure what "variable" means in C++.  The
>>> standard defines the term, but not in a way that really tells us
>>> what it means.
>>>
>>> "A *variable* is introduced by the declaration of a reference other
>>> than a non-static data member or of an object.  The variable's name,
>>> if any, denotes the reference or object."
>>
>> What part do you find confusing or hard to understand?
>
> The missing part that should tell us what a variable *is*.
>
> It says that certain declarations "introduce" a variable.  That's a
> statement about variables, but it doesn't say what a variable is.
>
> Given:
>
>     int n;
>
> we know that the declaration introduces a variable.  Is the object
> itself a "variable"?  That's the obvious meaning, and it's consistent
> with what the standard says.  Or is a "variable" some kind of logical
> binding between an object and a name?  That's also consistent with what
> the standard says.  Under the latter interpretation, the "variable" has
> a name, and that name denotes an object, but the variable is not the
> object.
>
> Given the above declaration, is the introduced variable an object?  If
> so, or if not, how does your answer follow from what the standard says?

On further thought, I think the intent has to be that a variable is not
an object.  A variable is introduced by a declaration, and a declaration
is not necessarily a definition.

For example, given:

    int var = 42;
    int main() {
        extern int var;
    }

There are two declarations for "var"; only the first is a definition.
If I understand correctly, each of these declarations introduces a
variable.  So apparently there are two variables with the name "var",
but only one object.  Or is there just one variable that's "introduced"
twice?

But the following paragraph says:

    A *local entity* is a variable with automatic storage duration
    (6.7.5.4), a structured binding (9.6) whose corresponding variable
    is such an entity, or the *this object (7.5.3).

Storage duration is an attribute of objects.  If a variable can have
automatic storage duration, then apparently a variable is an object.

Informally, I think of a "variable" as an object whose name is an
identifer.  Given `int foo[10];`, foo would be a variable, but foo[1]
would not.

Perhaps I'm missing something obvious, but I don't know what.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#119796

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>
>>> [...]
>>>
>>>>> A minor detail is that a variable must be declared, whereas memory
>>>>> locations can, for instance, be part of allocated memory for which
>>>>> no declaration exists - it is still undefined behavior to write
>>>>> code that applies unsequence side-effects to such memory locations.
>>>>
>>>> Digression:  I'm not even sure what "variable" means in C++.  The
>>>> standard defines the term, but not in a way that really tells us
>>>> what it means.
>>>>
>>>> "A *variable* is introduced by the declaration of a reference other
>>>> than a non-static data member or of an object.  The variable's name,
>>>> if any, denotes the reference or object."
>>>
>>> What part do you find confusing or hard to understand?
>>
>> The missing part that should tell us what a variable *is*.
>>
>> It says that certain declarations "introduce" a variable.  That's a
>> statement about variables, but it doesn't say what a variable is.
>>
>> Given:
>>
>>     int n;
>>
>> we know that the declaration introduces a variable.  Is the object
>> itself a "variable"?  That's the obvious meaning, and it's consistent
>> with what the standard says.  Or is a "variable" some kind of logical
>> binding between an object and a name?  That's also consistent with what
>> the standard says.  Under the latter interpretation, the "variable" has
>> a name, and that name denotes an object, but the variable is not the
>> object.
>>
>> Given the above declaration, is the introduced variable an object?  If
>> so, or if not, how does your answer follow from what the standard says?

[...]

> But the following paragraph says:
>
>     A *local entity* is a variable with automatic storage duration
>     (6.7.5.4), a structured binding (9.6) whose corresponding variable
>     is such an entity, or the *this object (7.5.3).
>
> Storage duration is an attribute of objects.  If a variable can have
> automatic storage duration, then apparently a variable is an object.

It seems clear that the quoted sentence is meant to be read as

    A *local entity* is a variable [associated with an object that
    has] automatic storage duration, [etc].

I'm not sure if C++ references also have storage durations, in which
case the word "object" in that sentence might need to be replaced with
"object or reference".  The key point though is that the property of
having automatic storage duration is meant to be associated with the
affiliated object or reference rather than with the variable itself.

[toc] | [prev] | [next] | [standalone]

#119801

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>> [...]
>>>>
>>>>>> A minor detail is that a variable must be declared, whereas memory
>>>>>> locations can, for instance, be part of allocated memory for which
>>>>>> no declaration exists - it is still undefined behavior to write
>>>>>> code that applies unsequence side-effects to such memory locations.
>>>>>
>>>>> Digression:  I'm not even sure what "variable" means in C++.  The
>>>>> standard defines the term, but not in a way that really tells us
>>>>> what it means.
>>>>>
>>>>> "A *variable* is introduced by the declaration of a reference other
>>>>> than a non-static data member or of an object.  The variable's name,
>>>>> if any, denotes the reference or object."
>>>>
>>>> What part do you find confusing or hard to understand?
>>>
>>> The missing part that should tell us what a variable *is*.
>>>
>>> It says that certain declarations "introduce" a variable.  That's a
>>> statement about variables, but it doesn't say what a variable is.
>>>
>>> Given:
>>>
>>>     int n;
>>>
>>> we know that the declaration introduces a variable.  Is the object
>>> itself a "variable"?  That's the obvious meaning, and it's consistent
>>> with what the standard says.  Or is a "variable" some kind of logical
>>> binding between an object and a name?  That's also consistent with what
>>> the standard says.  Under the latter interpretation, the "variable" has
>>> a name, and that name denotes an object, but the variable is not the
>>> object.
>>>
>>> Given the above declaration, is the introduced variable an object?  If
>>> so, or if not, how does your answer follow from what the standard says?
>
> [...]
>
>> But the following paragraph says:
>>
>>     A *local entity* is a variable with automatic storage duration
>>     (6.7.5.4), a structured binding (9.6) whose corresponding variable
>>     is such an entity, or the *this object (7.5.3).
>>
>> Storage duration is an attribute of objects.  If a variable can have
>> automatic storage duration, then apparently a variable is an object.
>
> It seems clear that the quoted sentence is meant to be read as
>
>     A *local entity* is a variable [associated with an object that
>     has] automatic storage duration, [etc].

It seems clear to you.  It's not clear to me.  If the only way to
understand a passage is to assume it includes extra words, it is at best
poorly written -- and I can't be sure that any assumptions about what it
*really* means are correct.

> I'm not sure if C++ references also have storage durations, in which
> case the word "object" in that sentence might need to be replaced with
> "object or reference".  The key point though is that the property of
> having automatic storage duration is meant to be associated with the
> affiliated object or reference rather than with the variable itself.

Perhaps so, but that still doesn't tell me what a "variable" is.

Apparently a "variable" is something *associated with* an object.  But
what is it, and how is the concept useful when we already have the
concept of an "object"?

I tried following your advice and searchin for uses of "variable" in the
C++ standard (which, as James Kuyper pointed out, should not be
necessary to understand the definition).  It was not helpful.  For
example, "Variables with static storage duration are initialized as a
consequence of program initiation.".  So a variable is a thing that can
have a storage duration and be initialized?  And it's not an object?

I get the impression (quite possibly mistaken) that the authors of the
standard implicitly assume in some places that a variable is an object,
and in other places that it's something else.

The most obvious meaning is that a "variable" is an object that has a
name introduced by a declaration.  (I'll gloss over the question of
whether something that's const-qualified is a "variable", but I'm
willing to accept that "variable" doesn't have to mean that something
can vary.)  But that's not what the standard says.

I'll note that the C standard does not define or use the term "variable"
(though it does use the word in its non-tecnical sense).  Instead it
refers to "objects".  Perhaps C++ could have done the same.

If I were to ask you "What is a variable in C++?", could you give a
clear answer?  What would that answer be?  Is a variable an object or
is it not?

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#119795

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>
>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>> [...]
>>
>>>> A minor detail is that a variable must be declared, whereas memory
>>>> locations can, for instance, be part of allocated memory for which
>>>> no declaration exists - it is still undefined behavior to write
>>>> code that applies unsequence side-effects to such memory locations.
>>>
>>> Digression:  I'm not even sure what "variable" means in C++.  The
>>> standard defines the term, but not in a way that really tells us
>>> what it means.
>>>
>>> "A *variable* is introduced by the declaration of a reference other
>>> than a non-static data member or of an object.  The variable's name,
>>> if any, denotes the reference or object."
>>
>> What part do you find confusing or hard to understand?
>
> The missing part that should tell us what a variable *is*.
>
> It says that certain declarations "introduce" a variable.  That's a
> statement about variables, but it doesn't say what a variable is.
>
> Given:
>
>     int n;
>
> we know that the declaration introduces a variable.  Is the object
> itself a "variable"?  That's the obvious meaning, and it's consistent
> with what the standard says.  Or is a "variable" some kind of logical
> binding between an object and a name?  That's also consistent with
> what the standard says.  Under the latter interpretation, the
> "variable" has a name, and that name denotes an object, but the
> variable is not the object.
>
> Given the above declaration, is the introduced variable an object?
> If so, or if not, how does your answer follow from what the standard
> says?

Even moreso than the C standard, the C++ standard needs to be read
holistically.  That may be a damning commentary on the quality of
writing in the C++ standard, but I think it matches the reality.

Given that, when confronted with a question like the ones you ask
about the term "variable", a natural course of action to find
answers to these questions might be to open the C++ standard in
a PDF viewer, and use the viewer's search facility to look at
places where the term in question is used.  The more of those that
can be looked at, the more likely it is that one will be able to
discern answers to such questions.  That's probably what I would
do if I felt I needed a better understanding of, for example, what
the term "variable" is supposed to mean.

[toc] | [prev] | [next] | [standalone]

#119797

Tim Rentsch wrote this copyrighted missive and expects royalties:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>
>>> [...]
>>>
>>>>> A minor detail is that a variable must be declared, whereas memory
>>>>> locations can, for instance, be part of allocated memory for which
>>>>> no declaration exists - it is still undefined behavior to write
>>>>> code that applies unsequence side-effects to such memory locations.
>>>>
>>>> Digression:  I'm not even sure what "variable" means in C++.  The
>>>> standard defines the term, but not in a way that really tells us
>>>> what it means.
>>>>
>>>> "A *variable* is introduced by the declaration of a reference other
>>>> than a non-static data member or of an object.  The variable's name,
>>>> if any, denotes the reference or object."
>>>
>>> What part do you find confusing or hard to understand?
>>
>> The missing part that should tell us what a variable *is*.
>>
>> It says that certain declarations "introduce" a variable.  That's a
>> statement about variables, but it doesn't say what a variable is.
>>
>> Given:
>>
>>     int n;
>>
>> we know that the declaration introduces a variable.  Is the object
>> itself a "variable"?  That's the obvious meaning, and it's consistent
>> with what the standard says.  Or is a "variable" some kind of logical
>> binding between an object and a name?  That's also consistent with
>> what the standard says.  Under the latter interpretation, the
>> "variable" has a name, and that name denotes an object, but the
>> variable is not the object.
>>
>> Given the above declaration, is the introduced variable an object?
>> If so, or if not, how does your answer follow from what the standard
>> says?
>
> Even moreso than the C standard, the C++ standard needs to be read
> holistically.  That may be a damning commentary on the quality of
> writing in the C++ standard, but I think it matches the reality.
>
> Given that, when confronted with a question like the ones you ask
> about the term "variable", a natural course of action to find
> answers to these questions might be to open the C++ standard in
> a PDF viewer, and use the viewer's search facility to look at
> places where the term in question is used.  The more of those that
> can be looked at, the more likely it is that one will be able to
> discern answers to such questions.  That's probably what I would
> do if I felt I needed a better understanding of, for example, what
> the term "variable" is supposed to mean.

This one gives me a headache:

    https://en.cppreference.com/w/cpp/language/value_category#:~:text=The%20expressions%20that%20have%20identity,and%20xvalues%20are%20rvalue%20expressions.

    Value categories

    Each C++ expression (an operator with its operands, a literal, a variable
    name, etc.) is characterized by two independent properties: a type and a
    value category. Each expression has some non-reference type, and each
    expression belongs to exactly one of the three primary value categories:
    prvalue, xvalue, and lvalue.

Not to mention rvalue and glvalue.

-- 
Things past redress and now with me past care.
		-- William Shakespeare, "Richard II"

[toc] | [prev] | [next] | [standalone]

#119799

Tim Rentsch wrote this copyrighted missive and expects royalties:

> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>
>> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>>
>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
...
>>>> "A *variable* is introduced by the declaration of a reference other
>>>> than a non-static data member or of an object.  The variable's name,
>>>> if any, denotes the reference or object."

[That's 6.1p6]

>>> What part do you find confusing or hard to understand?
>>
>> The missing part that should tell us what a variable *is*.
>>
>> It says that certain declarations "introduce" a variable.  That's a
>> statement about variables, but it doesn't say what a variable is.
>>
>> Given:
>>
>>     int n;
>>
>> we know that the declaration introduces a variable.  Is the object
>> itself a "variable"?  That's the obvious meaning, and it's consistent
>> with what the standard says.  Or is a "variable" some kind of logical
>> binding between an object and a name?  That's also consistent with
>> what the standard says.  Under the latter interpretation, the
>> "variable" has a name, and that name denotes an object, but the
>> variable is not the object.
>>
>> Given the above declaration, is the introduced variable an object?
>> If so, or if not, how does your answer follow from what the standard
>> says?
>
> Even moreso than the C standard, the C++ standard needs to be read
> holistically.  That may be a damning commentary on the quality of
> writing in the C++ standard, but I think it matches the reality.
>
> Given that, when confronted with a question like the ones you ask
> about the term "variable", a natural course of action to find
> answers to these questions might be to open the C++ standard in
> a PDF viewer, and use the viewer's search facility to look at
> places where the term in question is used.  The more of those that
> can be looked at, the more likely it is that one will be able to
> discern answers to such questions.  That's probably what I would
> do if I felt I needed a better understanding of, for example, what
> the term "variable" is supposed to mean.

It should not be necessary to do that. In 6.1p6, the word "variable" is
italicized, an ISO convention identifying the sentence in which it
occurs as the official definition of the term. As such, it is supposed
to be sufficient to answer that question; there should be no need to
infer the intended meaning by reading all of the uses of that term in
the document.
I agree, that counts as a damning statement about the quality of writing
of at least that part of the standard.

[toc] | [prev] | [next] | [standalone]

#119729

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 7/22/24 13:51, testuseri2p wrote:
>
>> I'd say in simple words, if you alter a variable multiple times in
>> one statement, you get UB.
>
> The correct (and admittedly more complicated) statement of the
> relevant rule is:

> "If a side effect on a memory location (6.7.1) is unsequenced
> relative to either another side effect on the same memory location
> or a value computation using the value of any object in the same
> memory location, and they are not potentially concurrent (6.9.2),
> the behavior is undefined."
>
> The biggest difference between the exact rule and what you said is
> that two different updates to a variable may occur in the same
> statement, so long as they are sequenced relative to each other.
> Sub-expressions of an expression are sequenced before evaluation of
> the expression itself.  In general, the sub-expressions of a
> expression are unsequenced, but there several exceptions: ||, &&,
> ?:, the comma operator.

Don't forget << (and also >>?).

> A minor detail is that a variable must be declared, whereas memory
> locations can, for instance, be part of allocated memory for which
> no declaration exists - it is still undefined behavior to write code
> that applies unsequence side-effects to such memory locations.

The original statement most likely meant "variable" as a stand-in
for "object".

[toc] | [prev] | [next] | [standalone]

#119720

On 07/22/24 10:51 AM, testuseri2p wrote:
> I'd say in simple words, if you alter a variable multiple times in one
> statement, you get UB.

In simple words, if the variable(s) in the above expression have 
user-defined types and, consequently, the operators in the above 
expression are user-defined (as opposed to being built-in), then your 
above statement does not apply. You can end up with unspecified 
behavior, but not with undefined behavior.

Which is why, once again, there's no specific answer to the original 
question without knowing more about the types of the variables involved.

As for more formal words - see the adjacent answers.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#119726

On 7/22/24 13:51, testuseri2p wrote:
> I'd say in simple words, if you alter a variable multiple times in one
> statement, you get UB.

The correct (and admittedly more complicated) statement of the relevant
rule is:
"If a side effect on a memory location (6.7.1) is unsequenced relative
to either another side effect on the same memory location or a value
computation using the value of any object in the same memory location,
and they are not potentially concurrent (6.9.2), the behavior is undefined."

The biggest difference between the exact rule and what you said is that
two different updates to a variable may occur in the same statement, so
long as they are sequenced relative to each other. Sub-expressions of an
expression are sequenced before evaluation of the expression itself. In
general, the sub-expressions of a expression are unsequenced, but there
several exceptions: ||, &&, ?:, the comma operator.

A minor detail is that a variable must be declared, whereas memory
locations can, for instance, be part of allocated memory for which no
declaration exists - it is still undefined behavior to write code that
applies unsequence side-effects to such memory locations.

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c++

csiph-web