Re: why vector needs an assignable requirement for object T ?

From:

alfps <alf.p.steinbach@gmail.com>

Newsgroups:

comp.lang.c++

Date:

Mon, 29 Dec 2008 23:30:06 -0800 (PST)

Message-ID:

<0c0d3268-fc13-47e1-bdd5-68b121bff0f7@t39g2000prh.googlegroups.com>

On 30 Des, 07:09, abir <abirba...@gmail.com> wrote:

Hi
I am using an object with a const member like ,
struct Foo{
const int x_;
explicit Foo(int x) : x_(x){}};

I am happy with default copy ctor ...
but as its member is const, i can't make it assignable.

if i have std::vector<Foo> FV;
FV v; v.push_back(Foo(1));
Now i can't store it in vector. push_back internally calls insert and
which somewhere needs fill.
Why it is required at all,?
I have a handcrafted vector class where push_back does not need
assignment (not even copy ctor, an move op is sufficient)
I don't know where it is required apart from v[i] = Foo(3); or
equivalently *it = Foo(3); kind of statement.
even for insert at the mid i can transfer the mid elements at the
tail and copy /move construct the new elements at the raw memory at
mid.

When you use a non-assignable element type you're violating the
promise that that type gives: if you have a pointer or reference or
iterator to such an element you have a right to expect that it won't
change.

Removing or inserting in a vector can however change the elements
beyond the removal/insertion point.

And there is no separate class for "constant vector".

In the end it's an issue of complexity.

std::vector would have to be more complicated to deal with the issue
of non-assignable element type (but note that the restriction to
assignable is just a specification bug for std::list, corrected in C+
+0x).

Cheers & hth.,

- Alf