Re: why vector needs an assignable requirement for object T ?
On Dec 30, 12:30 pm, alfps <alf.p.steinb...@gmail.com> wrote:
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.
I am not sure what promise the type need to give. The only promise i
can think of is that the container can rearrange the elements in any
memory in any order (for vector even the memory order is specified as
for any ith element &v[i+1] == &v[i]+1)
Why the type need to promise that it need to be copy ctor'able apart
from that it can be moved inside the vector's memory (through copy,
through move, through direct construct or whatever other way
possible). I think c++0x removed that requirement, as in latest gcc
build i can write
v.push_back(1,2); for a struct which can take 2 args, and do inplace
construction.
or even a move ctor if i had externally constructed the object.
After that it can only rearrange the elements, or place them in some
new memory etc.
Why i need to give a promise that the vector (or any other container)
can change the state of the object which i requested it to store only?
one can always move an object with const state (or const object) in
another memory.
raw memory
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.
It may be issue of complexity, but why it is a requirement?
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