5

In C++11 3p3 it states:

An entity is a value, object, reference, function, enumerator, type, class member, template, template specialization, namespace, parameter pack, or this.

In 17.6.1.1p1 it states:

The C++ standard library provides definitions for the following types of entities: macros, values, types, templates, classes, functions, objects.

What is an example of a value that the C++ standard library provides a definition for, that is not an object?, and conversly: What is an example of an object that the C++ standard library provides a definition for, that is not a value?

Charles
  • 50,943
  • 13
  • 104
  • 142
Andrew Tomazos
  • 66,139
  • 40
  • 186
  • 319
  • 1
    This doesn't directly answer the question, but cppreference is pretty good at categorizing this stuff: [Objects](http://en.cppreference.com/w/cpp/language/object) and [value categories](http://en.cppreference.com/w/cpp/language/value_category) –  Feb 09 '14 at 05:16
  • @remyabel: Thanks, but a value category is not a value. A value category is a property of an expression. Likewise an expression has a value. What isn't clear is "a value that the standard library provides a definition for". – Andrew Tomazos Feb 09 '14 at 05:48
  • 2
    Objects and values are part of the core language, so I don't think the standard *library* will be of much help. – Kerrek SB Feb 09 '14 at 06:44

3 Answers3

3

An object is something that is stored in memory (cf. 1.8: "An object is a region of storage"). Every object has a value (which is itself), but values are more general, in the sense that the evaluation of every expression gives a value. For example, a prvalue, such as the value of f() for a declared function T f();, may or may not have storage – you cannot take its address, and its existence may not need to be manifest as storage. (However, once you bind the value to a reference variable or formal parameter, you now have a way of referring to the object by name.)

The difference is mainly one of language semantics, though, and not usually of practical importance. (For example, people often refer to "temporary objects", although "temporary value" would be more accurate.) Values and objects both have types (which are always object types), an object can be evaluated to produce a value, and a value can be treated as an object. I would use "object" when talking about the code design, allocations and storage, and "value" when talking about grammatical rules of the language.

Kerrek SB
  • 464,522
  • 92
  • 875
  • 1,084
  • 3
    Values are things an object can *hold*, one at a time. – n. m. could be an AI Feb 09 '14 at 05:33
  • Thanks for your time Kerrek, but this doesn't actually answer my question. An answer to this question would consist of two entities that the standard library provides definitions for. Admittedly the title is not really correct, I will fix it. – Andrew Tomazos Feb 09 '14 at 05:43
  • Indeed. And to quote the father of the STL, Alexander Stepanov "I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. ..." – Aluan Haddad Feb 09 '14 at 11:26
  • "Every object has a value (which is itself)" -- An uninitialised object doesn't yet have one. "(For example, people often refer to "temporary objects", although "temporary value" would be more accurate.)" -- I think "temporary object" is right. Temporary objects occupy a block of memory in the exact same way as other local variables would (which may, in some cases, be optimised away, exactly like other local variables). –  Feb 09 '14 at 11:53
  • @hvd: OK, more precisely, *evaluating* an object gives a value that is itself. You can evaluate an uninitialized object, but there are limits to what you are allowed to do with the value (e.g. you cannot perform rvalue-to-lvalue conversion on it). – Kerrek SB Feb 09 '14 at 17:32
  • Given an uninitialised `unsigned char u;`, `u == u` is not required to evaluate to true, and depending on exactly which standard you're using, may not even have defined behaviour. (It's undefined in C90 and C++98/C++03. It's valid with an unspecified result in C99, and I'm not sure C++11 adopted that rule.) For either of those results, I wouldn't say "the value of `u`" has any useful meaning. (I thought you were referring to the result after lvalue-to-rvalue conversion. If not, then I'm not entirely sure what you do mean.) –  Feb 09 '14 at 17:38
  • @hvd: performing lvalue-to-rvalue conversion is UB in C++ in that case. – Kerrek SB Feb 09 '14 at 17:40
  • @KerrekSB I just checked, you're right for the C++11 standard. Later drafts (indicative of a future standard, but not standard now) do loosen the requirements, but not as far as C99. `unsigned char u; u == u;` would be undefined, but `unsigned char u; &u; u == u;` would be valid with an unspecified result. –  Feb 09 '14 at 17:46
  • @hvd: I really don't want to talk about C. C has a very different object model, and I'm not familiar with it at all. That should probably be a separate question. But I edited the question to emphasize that the difference between "object" and "value" is mainly one of context. – Kerrek SB Feb 09 '14 at 17:50
  • 1
    @KerrekSB That's fine with me. It wasn't my intention to bring C this much into this, but I do get the C and C++ rules mixed up sometimes. Anyway, C++11 has a precise but surprising definition of "value". See [basic.types]p4, it's too long to include in a comment here. "value" only applies to trivially copyable types, and for those types, the "value" is what the bits in the "object" represent. What's surprising about that is that other types don't have values at all. They do have lvalues, xvalues and prvalues, but just "values" don't even exist. –  Feb 09 '14 at 18:03
  • 1
    @hvd: No, that's value *representation*... All objects have values, but for trivially copyable ones the value representation determines the value. (I.e. copying the value representation amounts to copying the value.) – Kerrek SB Feb 09 '14 at 18:07
  • 1
    @KerrekSB *value* is defined in the same paragraph, the sentence directly after the one that defines *value representation*. The fact that *value* is in italics there means that it's the definition of the term. –  Feb 09 '14 at 18:09
  • 1
    @hvd: I don't think it's saying that *every* value arises in this fashion. Only that the value representation gives rise to a value if the object is trivially copyable. There can be other values. – Kerrek SB Feb 09 '14 at 18:12
  • @KerrekSB Right (and I didn't intend to claim otherwise -- I would think that `1` is both a prvalue and a value -- but I can see how you would think I did), but the definition of "value" is inside the "For trivially copyable types" condition, so "value" is never defined for types that are not trivially copyable. –  Feb 09 '14 at 18:15
  • @hvd: I'd say that 3.10 and 5 together define "value" reasonably well, non? – Kerrek SB Feb 09 '14 at 18:17
  • @KerrekSB 3.10 defines "lvalue", "xvalue", "prvalue", "glvalue", "rvalue", "value category", but not "value". 5 does not define it at all, but does seem to use it as short for "lvalue or xvalue or prvalue", seemingly contradicting the definition. –  Feb 09 '14 at 18:23
  • 2
    *"(For example, people often refer to "temporary objects", although "temporary value" would be more accurate.)"*. The term "temporary value" sounds like a nonsensical thing to me. The attribute "temporary" in C++ restricts the lifetime. But a value does not have a lifetime. It is a *meaning* of a set of bits, it is "immaterial", somewhat. What is, in fact, temporary is the *object* that holds the value. – Johannes Schaub - litb Feb 09 '14 at 21:29
  • FWIW, as resolving http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1299 , the committee is currently cleaning up the term "temporary", and will likely introduce the term "temporary expression" as a conservative approximation of (prvalue) expressions that refer to temporary objects. – Johannes Schaub - litb Feb 09 '14 at 21:30
  • I think I would say it this way: Evaluation can result in a value (example, `42`), object (example, `string("hello")`), function (`std::terminate`) or function template (and some other things I forgot, probably). – Johannes Schaub - litb Feb 09 '14 at 21:38
  • 1
    I don't think it makes sense to say that "the object itself is the value". Example, you have `int a = 2; +a`. Then `a` is an object. But the value of `+a` is *not* `a`. That doesn't make sense at all. The value is "two". In a similar way, you as the programmer might define a `rational` class and define that `rational(2, 4)` stores the same value as `rational(1, 2)`, attributing "meaning" to a set of bits. But this "value" has nothing to do with the Standard's notion of it. As @hvd said, "value" is defined in the spec for trivially copyable types, and I think it makes sense that way. – Johannes Schaub - litb Feb 09 '14 at 21:49
  • @JohannesSchaub-litb: No, indeed, the value of `+a` is separate. But the value of the id-expression `a` is `a`, and the value of `(a)` is also `a`. And for `int & f() { return a; }`, the value of `f()` is also `a`. – Kerrek SB Feb 10 '14 at 00:01
  • I think whatever the definition of *value* is, you should be able to say *for `int a = 5; int b = a;`, `a` and `b` are different objects, but have the same value*. That the Standard isn't unambiguous about its usage of terms isn't something new. Especially in regard to the lvalue-to-rvalue conversion, which IMO is tightly coupled to the difference between objects and values. – dyp Feb 10 '14 at 00:07
  • @dyp: Hm, maybe we're getting somewhere with this... for `int & f() { return a; }` and `int g() { return a; }` it's true that the values of `f()` and `g()` compare equal (so they have "the same value"), but it's also true that the value of `f()` *is* in some sense the object `a`, whereas the value of `g()` is not. So perhaps the right way to think about this is that values can be compared for semantic equality, and objects for identity. – Kerrek SB Feb 10 '14 at 00:12
  • I'm not quite sure [expr] is using the term *value* unambiguously: It's talking about the *range of representable values* in [expr]/4 (which doesn't make sense for objects with identity) and *value of a parenthesized expression* in [expr.prim.general]/6 (which should also apply to objects with identity, and should imply `&(a) == &a`). The term *value* is not used that often in [expr] in the latter way and [expr.prim.general]/8 about identifiers/id-expressions uses the term *result of an expression* instead of *value of an expression*. – dyp Feb 10 '14 at 00:36
  • (Btw the new/C++1y [conv.lval]/2 says "value contained in the referenced object".) – dyp Feb 10 '14 at 00:36
  • I -1ed this because I think it contains confusing statements. I don't claim that I know how the Standard should be interpreted, and therefor I wouldn't put an answer up here in which I claim my theories as facts. SO is about facts, not personal theories (and IMO, this isn't a very good theory because it has very few support in the Standard text). – Johannes Schaub - litb Feb 10 '14 at 00:51
  • The standard does not define value. If it did, there would be no argument -- it would be obvious to all. 3.9 defines 'value' in the context of an object, but the value of a literal or an expression may never get stored in any object. – david.pfx Feb 11 '14 at 10:32
  • @JohannesSchaub-litb "Evaluation can result in a value (example, 42), object (example, string("hello")) ..." 1.9p12: "Evaluation of an expression in general includes both value computations and initiation of side effects". 5p1: "An expression can result in a value and can cause side effects." I think (non-void) expressions does only result in a value, and this value (lvalue) refers to a function, template function, (lvalue/xvalue) object..., or is used to initialice and object (declarator, parameter, etc, etc) when it is a prvalue. – ABu Feb 13 '14 at 02:46
  • 1
    @Peregring-lk "*can* result in a value". Sure, but not *must*. Also yes, it is called "value computation", but this thing does not refer to the computation of a value. The phrase "value computation" is a sort of "atomic" term, which does not refer to the defined term "value", really. But in any case, defects of the Standard in using a defined term does not mean that the term is not defined. And sure, there are quite a few defects about *value* and it might even be that the definition itself is defective. – Johannes Schaub - litb Feb 13 '14 at 21:54
  • Ok, I have read your last comment and I continue reasoning: from 5p1: "can result in a value"; I think this "can" can be replaced by "must" when we don't consider void expression. Why? From 1.9p12: "including determining the identity of an object for glvalue evaluation"; doesn't "glvalue evaluation" generate a value (e.g, the address of a function/object)? From this point of view, any expression (lvalue, xvalue or prvalue) results in a value (of course, not neccesarily the value of an object) when evaluated, except void expressions, which I don't know even if they fit in any value category. – ABu Feb 14 '14 at 00:02
3

The standard iostream objects defined in 27.4.1 [iostreams.objects.overview] such as cin, , cout, cerr and clog (and their wide character cousins) would be examples of objects defined by the Standard Library.

Similarly, the std::ios_base::fmtflags type defined in 27.5.3 [ios.base] has several constexpr values defined (e.g. boolalpha).

TemplateRex
  • 69,038
  • 19
  • 164
  • 304
  • 1
    Does what the `NULL` macro resolve to count as a value? Also, there's `io_errc::stream`, which is defined to be an enumerator. – dyp Feb 09 '14 at 15:01
  • 1
    @dyp [diff.library]/3 defines `NULL` as a macro (i.e. expanded by the preprocessor) and [diff.library]/4 defines `CHAR_BIT` and its cousins as values. – TemplateRex Feb 09 '14 at 16:35
  • @TemplateRex I think CHAR_BIT and its cousins are defined as values for pure inheritage of C. But lexically they name literals, and literals represents values but they are not itself values, since values are more related with the "logical meaning" of a "physical representation" of a literal, or better said, literals are somehow "mapped" to physical representations of the values they represent. – ABu Feb 13 '14 at 02:17
0

The C++ standard does not provide a definition for 'value', relying on its ordinary English meaning. It defines 'object' as a 'region of storage'.

The C++ standard library provides many values that are not objects. A simple example is NULL. Others include SIZE_MAX, EXIT_SUCCESS and FE_OVERFLOW. You may quibble over whether they are 'defined', since little explanation is provided in the standard.

The C++ standard library provides few definitions of objects that I can find, in the sense of a name for a 'region of storage'. The only ones I know of (courtesy of a commenter) are the 'standard iostream objects' such as cin and cout.

Since it includes the C standard library, another obvious one is errno, although even this includes a quibble that 'errno may not be the identifier of an object'.

The standard libary does provide a large number of functions that return a pointer to an object on execution, new and malloc() being obvious examples. So it defines many dynamic objects, if you like.

[edited to include iostream objects, new]

david.pfx
  • 10,520
  • 3
  • 30
  • 63
  • `std::cin` is an object, isn't it? and every object occupies storage since, except base class objects or bit-fields, it shall occupy at least one byte and have a non-repeated address. – ABu Feb 10 '14 at 13:02
  • You're absolutely correct. One edit coming right up. – david.pfx Feb 10 '14 at 13:11
  • And if I'm not wrong, I think these names: NULL, SIZE_MAX, etc, doesn't define values either, rather they define alias for other literals. After the preprocessing phase, these names (they are not variables) doesn't appear in the code, but its associated literals, and literals are not values, but "textual" representations in the source code of their values, which real values (set of bits in memory or physical representations of these values) are normally implementation-defined. So, this question is more complicated that seems to be (from a formal point of view). – ABu Feb 10 '14 at 13:30
  • @Peregring-lk: I take your point, but within the scope of the standard I think these are macros which represent values. There are other macros which do not. NULL in particular has little choice but to be represented as some kind of zero. – david.pfx Feb 11 '14 at 10:22
  • I think the standard, for any reason, doesn't put effort enough when using the word "value", but literals does always represent values (like zero). But strictly speaking, these types of macros define alternative (preprocessing) names for literals, since, once preprocessed, the resulting sustitutions are literals, not values (although they represent values). I think the unique situation where a value appear is after evaluating a non-void expression. When evaluated, a value is generated and inmediatly used to initialize other object (temporary object, parameter, declarator, ...). – ABu Feb 13 '14 at 02:10