Some Basic QUESTIONS.

K

kunjaan

I was just going through the C++ STL and it says that "the STL was
created with four ideas in mind: generic programming, abstractness
without loss of efficiency, the Von Neumann computation model, and
value semantics."

1. What are value semantics?
2. What kind of losses do you get with abstractions?
 
S

Stefan Ram

kunjaan said:
1. What are value semantics?

An object represents an immutable value (vs. an object
represents a system with a mutable state.)
2. What kind of losses do you get with abstractions?

Evaluating (( lambda( x )( add x x ))2 ) at runtime usually
will be less efficient than evaluating ( add 2 2 ).
 
J

James Kanze

An object represents an immutable value (vs. an object
represents a system with a mutable state.)

Not necessarily, at least not in C++. I do like the idea that
an object with value semantics can only be modified by the
assignment operators, but this is far from the general
case---std::string, for example, clearly has value semantics,
despite a large number of mutator functions. (One can argue
that this is a design error, but if so, it's still one we have
to live with.)

The important consideration for value semantics is that only the
value of an object is significant, not its identity. So you can
copy it (copy constructor or assignment) as much as you like,
and any copy can be used in place of the original with no change
in the behavior of the program. Arguably, this implies
immutability (except by assignment), since any changes will only
affect the copy, but in practice, with care, mutable types
like std::string do seem to be usable as values as well.
 
S

Stefan Ram

James Kanze said:
The important consideration for value semantics is that only the
value of an object is significant, not its identity. So you can
copy it (copy constructor or assignment) as much as you like,

One can eventually identify five different concepts that can
be used to explain this notion in a more precise manner, these
are: extensionality, definiteness, substitutivity of identity,
unfoldability, and referential transparency.

More details:

http://www.purl.org/stefan_ram/pub/referential_transparency
 
S

Stefan Ram

James Kanze said:
only the value of an object is significant, not its identity.

Since I wrote »more precise« in my previous post, I need to
explain my problems with the above wording regarding »value
semantics«.

I am not sure what »the value of an object« versus »the
identity of an object« is, and what »significant« means here.
I believe that none of these notions is given by ISO/IEC
14882:2003(E).

Since an object is a typed region of storage, the »value of an
object« might be taken to be the state of this storage, thus,
»the value« is a composite value in the case of a class with
multiple fields. Such a thing might not be a »first-class
value« in C++, I believe it is represented by a so-called
»temporary object« when it is being transferred.

(Below, I choose to avoid the term »value« and use »==«
instead.)

»The identity of an object« might be read as »the address of
an object«.

»significant« might mean »able to change the observable
behavior of the program«.

Thus, the above possibly might be worded as:

The observable behavior of the evaluation of a function
call »f( o )« with a function »f« that has value-semantics
with regard to an argument object »o« will not change,
when the call is being replace by »f( o_ )«, given that
»o_« has the same type as »o« and »( o == o_ )« and that
»f( o_ )« is being evaluated with the same state of the
environment as »f( o )«.

This usually implies that the behavior of »f« does not
depend on the address of this argument.
 
S

Stefan Ram

»o_« has the same type as »o« and »( o == o_ )« and that

Oops: I assumed that »==« was overloaded to give »value
equality« for this class, but does not compare the addresses.
(I am not sure whether this is common usage in C++.)
 
J

James Kanze

Since I wrote »more precise« in my previous post, I need to
explain my problems with the above wording regarding »value
semantics«.
I am not sure what »the value of an object« versus »the
identity of an object« is, and what »significant« means
here. I believe that none of these notions is given by
ISO/IEC 14882:2003(E).

My use doesn't really concern what the stanard says. It's more
of a design issue. And yes, the concept isn't really that
precise: on can break it down into different aspects (as was
done in the article you linked to in your other response). In
practice, however, you usually don't have to---although
conceptually, these aspects are orthogonal, in practice, most of
the time, you will design an object to support all of them, or
non.
Since an object is a typed region of storage, the »value of an
object« might be taken to be the state of this storage, thus,
»the value« is a composite value in the case of a class with
multiple fields. Such a thing might not be a »first-class
value« in C++, I believe it is represented by a so-called
»temporary object« when it is being transferred.

The standard is a little vague in this regard. The "value" of a
POD is basically the bit pattern in its bytes (except that in
some cases, multiple bit patterns may be considered equal). The
value of a non-POD is intentionally left vague---the idea is
that it is up to the programmer to define what he means by it.
(Note that this makes the specification of concepts like
CopyConstructible or Assignable vague as well. Again, this is
largely intentional; its up to the user to decide what
"equivalent" means, or should mean, in his case, and implement
the various constructors and operators accordingly.)
 
V

Vaclav Haisman

kunjaan wrote, On 25.3.2009 0:32:
I was just going through the C++ STL and it says that "the STL was
created with four ideas in mind: generic programming, abstractness
without loss of efficiency, the Von Neumann computation model, and
value semantics."

1. What are value semantics?
Compare value semantics and pointer/reference semantics. If you have value
semantics, you assume that for some type T and variables A, B of the type T,
if you do A = B and then you modify B, variable A will not be affected in any
way. Opposite to that, with pointer/reference semantics (in language like
Java or Python) assignment A = B makes A point/refer to the same value as B
does, it does not make a copy of it. Any changes then done on/through B will
also be visible through A.
2. What kind of losses do you get with abstractions?
Abstraction often means introducing some form of indirection, often pointers.
In C++, abstraction can be achieved using virtual member functions.
Unfortunatelly, using virtual member functions usually means that compilers
cannot do inlining and other optimizations. That is loss of efficiency caused
by abstraction.

OTOH, abstracting things using generic programming and templates means that
compilers can see through all the code and function calls and can do inlining
and many other optimizations that would be inhibited by use of virtual member
functions.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top