"Carl Daniel" <cpdaniel@pacbell.net> wrote in message news:<B5uQ6.1$8o4.3419@news.pacbell.net>...
> "Kiril Avdeiv" <kavdeiv@mail.ru> wrote in message
> news:873f7ae8.0105271052.5f820f61@posting.google.com...
>
> [snip]
>
> > James, can you also explain what they mean by the value of an object,
> > or a value in itself. There's a kind of definition for it but only for
> > POD types: "For POD types, the value representation is a set of bits
> > in the object representation that determines a _value_, which is one
> > discrete element of an implementation-defined set of values". A most
> > obscure definition, isn't it? It a kind of defines a _value_ through a
> > value :o)
> >
>
> I'm not James, but I'll take a whack at it :)
>
> A _value_ is a conceptual entity - for example, 5.
>
> A _value representation_ is an implementation-specific pattern of bits which
> represents a value, for example (0,0,0,0,0,1,0,1) stored MSB->LSB in the 8
> bits of a byte which resides at the address of an object of type char.
>
> The distinction is made because an implementation may not use all the bits
> in the allocated space for an object.  This is frequently the case for
> structs, which may have padding, and floating point types which frequently
> have undefined bit combinations.
>
> Consider:
>
> struct
> {
>    char a;
>    int b;
> };
>
> On many implementations, there will be one or more undefined bytes between a
> and b.  Suppose char occupies one byte and int occupies 4 (as is common).
> This struct will then occupy 8 bytes of storage.  The byte pattern
> [0,1,2,3,4,5,6,7] and the byte pattern [0,100,101,102,4,5,6,7] have the same
> _value_ because only a subset of the bits of the object representation
> participate in the value representation.  Note that according to memcmp,
> these two structs are different, while according to a compiler-supplied
> operator==, they're the same.   That's because memcmp has no knowledge of
> which bits participate in the value representation and simply compares raw
> memory.

Carl, thank you very much for providing this perspective on my question.

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B1189D5.A0945202@wizard.net>...
> Kiril Avdeiv wrote:
> > James, can you also explain what they mean by the value of an object,
> > or a value in itself. There's a kind of definition for it but only for
> > POD types: "For POD types, the value representation is a set of bits
> > in the object representation that determines a _value_, which is one
> > discrete element of an implementation-defined set of values". A most
> > obscure definition, isn't it? It a kind of defines a _value_ through a
> > value :o)
>
> It does not - you're confusing the value representation with the value
> itself. The distinction between the two is similar to the distinction
> between a map of a hill, and the hill itself.
>
> Each object type has a discrete set of possible values. Values are
> abstract concepts, the value representation is the method the
> implementation uses to encode a particular value in an object of a
> particular type. For instance, the value of arithmetic object is the
> number it represents; the value of a pointer object is the location it
> points at. The value of composite objects is a collection of values of
> the component objects. Notice that values can be shared across many
> different types; 1.0 has a representation in every arithmetic type.
>
> Each distinct possible value of an object is represented by at least one
> pattern of bits (some values can have multiple representations). That
> bit pattern is what they call the value representation.

James, many thanks. It's clear.

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B101E90.388E7378@wizard.net>...
> Kiril Avdeiv wrote:
> >
> > "James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B0EEAF9.408B646A@wizard.net>...
> > > Kiril Avdeiv wrote:
> > > >
> > > > IMO the notions of variable and object are sometimes used
> > > > interchangebly in the standard for C++. Yet I feel there is a
> > > > difference. The standard only says that a variable is introduced by
> > > > the declaration of an object
> > >
> > > Specifically, it says "A _variable_ is introduced by the declaration of
> > > an object. The variable's name denotes the object." The underscores
> > > indicate that _variable_ is in italics, which in this context means that
> > > this is meant to be the official definition of a _variable_. As a
> > > definition, however, it's pretty obscure. My best guess is that a
> > > variable is a named object.
> > >
> > >       int a;
> > >       int *p = new int[10];
>
> > > Both a and p are both variables and objects, of type 'int' and 'int *'
> > > respectively. However, p points at an array object that itself has no
> > > name, and hence is not a variable.
>
> > Thank you for the answer. But an object may also have a name...
>
> Agreed; that was implicit in my statement. 'a' and 'p' are two examples.
>
> > Microsoft documentation on C/C++, which is really out of date, says
> > the following:
> >
> > <<quoting>>
> > This manual draws a distinction between objects and variables:
> > &#8220;object&#8221; means instance of a user-defined type, whereas
> > &#8220;variable&#8221; means instance of a fundamental type.
> >
> > In cases where either object or variable is applicable, the term
> > &#8220;object&#8221; is used as the inclusive term, meaning
> > &#8220;object or variable.&#8221;
> > <<end of quoting>>
> >
> > So I wonder if their definition is the same as those standardizers had
> > in mind?
>
> Most certainly not. All you have to do is to start searching for uses of
> the word "variable" in the standard, and you'll quickly find that those
> definitions don't fit. "A _variable_ is introduced by the declaration of
> an object" would make no sense with those meanings. The One Definition
> Rule (3.2p1) refers only to variables; if the distinction were as you
> suggest, user-defined types could ignore the ODR. The description of the
> meaning of the 'static' keyword (3.7.1p3) refers only to variables, the
> meaning of a static object of user-defined type would be undefined, etc.
> My suggested interpretation is consistent with each of these uses.

I now come to think that you were right from the first. Your
interpretation is consistent indeed. But, IMO the standard could have
been somewhat clearer when inroducing notions so heavily used
throughout the document.

I now think - what's the difference between the name of an object and
the name of a variable? It's already said in the standard that an
object _may_ have a name, so having a name for an object is not
obligatory. Why then to introduce the notion of a variable at all?

James, can you also explain what they mean by the value of an object,
or a value in itself. There's a kind of definition for it but only for
POD types: "For POD types, the value representation is a set of bits
in the object representation that determines a _value_, which is one
discrete element of an implementation-defined set of values". A most
obscure definition, isn't it? It a kind of defines a _value_ through a
value :o)

Thank you
Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Kiril Avdeiv" <kavdeiv@mail.ru> wrote in message
news:873f7ae8.0105271052.5f820f61@posting.google.com...

[snip]

> James, can you also explain what they mean by the value of an object,
> or a value in itself. There's a kind of definition for it but only for
> POD types: "For POD types, the value representation is a set of bits
> in the object representation that determines a _value_, which is one
> discrete element of an implementation-defined set of values". A most
> obscure definition, isn't it? It a kind of defines a _value_ through a
> value :o)
>

I'm not James, but I'll take a whack at it :)

A _value_ is a conceptual entity - for example, 5.

A _value representation_ is an implementation-specific pattern of bits which
represents a value, for example (0,0,0,0,0,1,0,1) stored MSB->LSB in the 8
bits of a byte which resides at the address of an object of type char.

The distinction is made because an implementation may not use all the bits
in the allocated space for an object.  This is frequently the case for
structs, which may have padding, and floating point types which frequently
have undefined bit combinations.

Consider:

struct
{
   char a;
   int b;
};

On many implementations, there will be one or more undefined bytes between a
and b.  Suppose char occupies one byte and int occupies 4 (as is common).
This struct will then occupy 8 bytes of storage.  The byte pattern
[0,1,2,3,4,5,6,7] and the byte pattern [0,100,101,102,4,5,6,7] have the same
_value_ because only a subset of the bits of the object representation
participate in the value representation.  Note that according to memcmp,
these two structs are different, while according to a compiler-supplied
operator==, they're the same.   That's because memcmp has no knowledge of
which bits participate in the value representation and simply compares raw
memory.

-cd


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Kiril Avdeiv wrote:
...
> I now come to think that you were right from the first. Your
> interpretation is consistent indeed. But, IMO the standard could have
> been somewhat clearer when inroducing notions so heavily used
> throughout the document.

I have to agree;

> I now think - what's the difference between the name of an object and
> the name of a variable? ...

If 'variable' means 'named object', then the name of a variable and the
name of an object are just two different ways of saying the same thing.

> ... It's already said in the standard that an
> object _may_ have a name, so having a name for an object is not
> obligatory. Why then to introduce the notion of a variable at all?

It's precisely because an object need not have a name, that you need a
special term to use to describe an object that does have a name. Some
rules only make sense when applied to named objects; the One Definition
Rule being a prime example.

> James, can you also explain what they mean by the value of an object,
> or a value in itself. There's a kind of definition for it but only for
> POD types: "For POD types, the value representation is a set of bits
> in the object representation that determines a _value_, which is one
> discrete element of an implementation-defined set of values". A most
> obscure definition, isn't it? It a kind of defines a _value_ through a
> value :o)

It does not - you're confusing the value representation with the value
itself. The distinction between the two is similar to the distinction
between a map of a hill, and the hill itself.

Each object type has a discrete set of possible values. Values are
abstract concepts, the value representation is the method the
implementation uses to encode a particular value in an object of a
particular type. For instance, the value of arithmetic object is the
number it represents; the value of a pointer object is the location it
points at. The value of composite objects is a collection of values of
the component objects. Notice that values can be shared across many
different types; 1.0 has a representation in every arithmetic type.

Each distinct possible value of an object is represented by at least one
pattern of bits (some values can have multiple representations). That
bit pattern is what they call the value representation.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

IMO the notions of variable and object are sometimes used
interchangebly in the standard for C++. Yet I feel there is a
difference. The standard only says that a variable is introduced by
the declaration of an object

I'll be very grateful for any sound explanation of the difference
backed by an example. If it's not too much to ask for...

Thank you in advance
Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Kiril Avdeiv wrote:
>
> IMO the notions of variable and object are sometimes used
> interchangebly in the standard for C++. Yet I feel there is a
> difference. The standard only says that a variable is introduced by
> the declaration of an object

Specifically, it says "A _variable_ is introduced by the declaration of
an object. The variable's name denotes the object." The underscores
indicate that _variable_ is in italics, which in this context means that
this is meant to be the official definition of a _variable_. As a
definition, however, it's pretty obscure. My best guess is that a
variable is a named object.

 int a;
 int *p = new int[10];
Both a and p are both variables and objects, of type 'int' and 'int *'
respectively. However, p points at an array object that itself has no
name, and hence is not a variable.

int *q = int(10.0)+3;
// int(10.0) creates a temporary object of type int, with a value of 10
// that object has no name, and hence is not a variable.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B0EEAF9.408B646A@wizard.net>...
> Kiril Avdeiv wrote:
> >
> > IMO the notions of variable and object are sometimes used
> > interchangebly in the standard for C++. Yet I feel there is a
> > difference. The standard only says that a variable is introduced by
> > the declaration of an object
>
> Specifically, it says "A _variable_ is introduced by the declaration of
> an object. The variable's name denotes the object." The underscores
> indicate that _variable_ is in italics, which in this context means that
> this is meant to be the official definition of a _variable_. As a
> definition, however, it's pretty obscure. My best guess is that a
> variable is a named object.
>
>  int a;
>  int *p = new int[10];
> Both a and p are both variables and objects, of type 'int' and 'int *'
> respectively. However, p points at an array object that itself has no
> name, and hence is not a variable.
Thank you for the answer. But an object may also have a name...

Microsoft documentation on C/C++, which is really out of date, says
the following:

<<quoting>>
This manual draws a distinction between objects and variables:
&#8220;object&#8221; means instance of a user-defined type, whereas
&#8220;variable&#8221; means instance of a fundamental type.

In cases where either object or variable is applicable, the term
&#8220;object&#8221; is used as the inclusive term, meaning
&#8220;object or variable.&#8221;
<<end of quoting>>

So I wonder if their definition is the same as those standardizers had
in mind?

> int *q = int(10.0)+3;
> // int(10.0) creates a temporary object of type int, with a value of 10
> // that object has no name, and hence is not a variable.
The sub-expression int(10.0) is an rvalue. "An l-value refers to an
object or function. Some rvalue expression -- those of class or
cv-qualified class type -- also refer to objects". "An object is a
region of storage". So I think that int(10.0) does not create an
object at all. I think it merely creates a temporary.

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Kiril Avdeiv wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message news:<3B0EEAF9.408B646A@wizard.net>...
> > Kiril Avdeiv wrote:
> > >
> > > IMO the notions of variable and object are sometimes used
> > > interchangebly in the standard for C++. Yet I feel there is a
> > > difference. The standard only says that a variable is introduced by
> > > the declaration of an object
> >
> > Specifically, it says "A _variable_ is introduced by the declaration of
> > an object. The variable's name denotes the object." The underscores
> > indicate that _variable_ is in italics, which in this context means that
> > this is meant to be the official definition of a _variable_. As a
> > definition, however, it's pretty obscure. My best guess is that a
> > variable is a named object.
> >
> >       int a;
> >       int *p = new int[10];

> > Both a and p are both variables and objects, of type 'int' and 'int *'
> > respectively. However, p points at an array object that itself has no
> > name, and hence is not a variable.

> Thank you for the answer. But an object may also have a name...

Agreed; that was implicit in my statement. 'a' and 'p' are two examples.

> Microsoft documentation on C/C++, which is really out of date, says
> the following:
>
> <<quoting>>
> This manual draws a distinction between objects and variables:
> &#8220;object&#8221; means instance of a user-defined type, whereas
> &#8220;variable&#8221; means instance of a fundamental type.
>
> In cases where either object or variable is applicable, the term
> &#8220;object&#8221; is used as the inclusive term, meaning
> &#8220;object or variable.&#8221;
> <<end of quoting>>
>
> So I wonder if their definition is the same as those standardizers had
> in mind?

Most certainly not. All you have to do is to start searching for uses of
the word "variable" in the standard, and you'll quickly find that those
definitions don't fit. "A _variable_ is introduced by the declaration of
an object" would make no sense with those meanings. The One Definition
Rule (3.2p1) refers only to variables; if the distinction were as you
suggest, user-defined types could ignore the ODR. The description of the
meaning of the 'static' keyword (3.7.1p3) refers only to variables, the
meaning of a static object of user-defined type would be undefined, etc.
My suggested interpretation is consistent with each of these uses.

> > int *q = int(10.0)+3;
> > // int(10.0) creates a temporary object of type int, with a value of 10
> > // that object has no name, and hence is not a variable.

> The sub-expression int(10.0) is an rvalue. "An l-value refers to an
> object or function. Some rvalue expression -- those of class or
> cv-qualified class type -- also refer to objects". "An object is a
> region of storage". So I think that int(10.0) does not create an
> object at all. I think it merely creates a temporary.

You're correct - I should have used a struct type for my example. The
point was that temporary objects are unnamed, and are never referred to
in the standard as variables - that's consistent with my interpretation.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]