Re: why vector needs an assignable requirement for object T ?
On Dec 30, 7:09 am, abir <abirba...@gmail.com> wrote:
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.
Sure you can. You just can't change the value of x_ in the
assignment. Do you want to be able to change the value of x_ or
not? If so, don't declare it const. If not, not changing the
value means not changing the value, regardless of the expression
being used.
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,?
Why is what required? The standard requires that all types in
standard containers be assignable. This is because standard
containers use value semantics, and value semantics suppose
assignable. And in practice, many of the functions of the
containers do require assignable in order to work. (The
exception is node based containers, like std::list and the
associative containers. And the next version of the standard
will not require assignable for these.)
I have a handcrafted vector class where push_back does not need
assignment (not even copy ctor, an move op is sufficient)
What's a "move op"? The standard says that std::vector requires
assignable. It may be possible to implement some of the member
functions without using assignment, but a good implementation
will generally trigger a compiler error if assignment is not
supported, even if no member functions are ever called, e.g.:
#include <vector>
struct Foo{
const int x_;
explicit Foo(int x) : x_(x){}};
void
f()
{
std::vector< Foo > v ;
}
does not compile with my compiler (but it is undefined behavior,
so an error message is not guaranteed---it might compile, then
reformat your hard disk at run-time).
struct Foo{
const int x_;
explicit Foo(int x) : x_(x){}};
I don't know where it is required apart from v[i] = Foo(3); or
equivalently *it = Foo(3); kind of statement.
The current version of the standard says that for all
containers, "The type of objects stored in these components must
meet the requirements of CopyConstructible types and the
additional requirements of Assignable types." No exceptions.
Failing to abide by this is undefined behavior. Good compilers
will generate an error at any attempt to instantiate the
component with a type which doesn't conform, but this is not
required by the standard; as far as the standard is concerned,
it is undefined behavior.
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.
I'm not sure what you mean by "move construct". There is no
"move construct" in the current standard. (There will be in the
next version, and the requirements are being reworked to take
this and rvalue references into account. But it will
doubtlessly be awhile before compilers implement this.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34