Some Basic QUESTIONS.
kunjaan
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?
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.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
James Kanze
> James Kanze <james.ka...@gmail.com> writes:
> >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).
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.)
Vaclav Haisman
> 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?
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.
--
VH