Re: Insert object with const member in vector
On Jul 17, 8:39 pm, Joe Hesse <JoeHe...@gmail.com> wrote:
On Sat, 17 Jul 2010 20:08:04 +0200, Rolf Magnus wrote:
Joe Hesse wrote:
I repeat, you would be better ignoring that advice, I
dropped it without thinking about its consequences.
Creating a meaningful assignment in this case is hard to
do if at all possible - I suspect the way I would
implement it will lead to UB in any case.
I added an "operator =" to "class Data" with a const data
member for the sole purpose of being able to make a
vector<Data> of that class.
That's a design error. If you make a member const that means
that it's supposed to not change duing the entire life time
of the object. But your operator= is designed for the sole
purpose of breaking that contract. So obviously the member
should not be const in the first place.
I think the const implementation in C++ has let me down.
Without going into details, I have a big text file where I
want to put the information in each line(s) in a C++ object.
The data in the class won't change and shouldn't change, so,
following the advice of the experts, I make the data const.
Which experts? I'd almost never recommend const for a class
member, and only if the class itself was non-copiable. In fact,
I often use pointers in the class when the external interface
only exposes references, just to allow copying and assignment.
In this case, I don't understand what you're saying. The data
in the class won't change, and shouldn't change. If this is
really the case, then the class can't support assignment (which
implies that the data does change), and thus can't be used in a
standard container (since said containers *do* change the data
in specific instances).
Note that in a large sense, saying that "the data won't change,
and shouldn't change" doesn't really make sense for objects
which can be copied. Depending on the role your object plays in
the application, probably, it should either have identity, and
not support copy (in which case, it also probably hase some sort
of specific lifetime, and the container should contain pointers
to it), or be just a typical value, and support copy and
assignment.
Since I won't be doing any copying or assignment, it makes
sense not to define these operators for my class.
Standard containers have value semantics. They copy the object
inserted into them, and may use assignment to move it around
later. You have to decide whether your object should have value
semantics, or whether you want to give it identity.
In fact, I view it as an error to copy or assign my objects
and, afaik, an error message will be produced if I try to do
it since the class has a const data member.
You can still copy it. If you don't want copy and assignment,
it's best to make the interdiction explicit, say by deriving
from boost::noncopyable.
Since I have many objects I want to put them someplace and a
vector seems the way to do it.
You seem to have misunderstood what vector does. The objects in
a vector are in the vector. You can't put an existing object in
a vector; you can only create a copy of it in the vector.
After I have the objects in a vector, I can iterate through
the vector and print my desired report. The problem is that
the const data in my class prevents me from creating the
vector. I can easily fix everything by removing the const.
If I have to do this then I can't use the const feature of
C++.
I hardly see where not declaring something const because you
want to be able to modify it means that you can't use the const
feature of C++.
--
James Kanze