Re: why vector needs an assignable requirement for object T ?
On Dec 30, 3:50 pm, James Kanze <james.ka...@gmail.com> wrote:
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.
i know about the copy constructible requirement (wich can be solved
with the rvalue ref).
Don't know why the assignable requirement is there.
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.)
Yes, but in gcc c++0x mode (gcc 4.3) it uses std::fill and demands an
assignment op
(i.e X& operator(X& )
(while doesn't need the copy requirement, only X(X&& ) (is it called
move copy ? ) is sufficient)
Moreover for the point that it violates type's non assignable
constraint ( as pointed by Alf )
I am not sure why this violates the contract. contract works for the
type, not on the memory.
T a(1);
T b(2);
at this point a & b are object of type T, thus all the contracts
should be valid.
b.~T();
after this b is destroyed. It no longer an valid object, thus it has
no valid type.
b.anything is not going to work at this point, but that doesn't
violate the contract
as they are for type T.
new( &b ) T(a);
i am creating another object here with a copy from a at the location
previously pointed by b.
if i try to use old b & say this is a violation of contract, this is
definitely my fault.
in my system, if i write,
T* a = new T(1);
delete a;
T* b = new T(2);
at this point mostly i get a == b, as probably my system's new is
implemented in that way.
But that doesn't say it violated any contract of the object types
because as soon as i delete a,
i don't have any contract.
one auxiliary question,
can i have an existing c++ equiv of this one?
template<typename T,typename... Args>
void construct(T* p,const Args&&... a){
new(p) T(a...);
};
i.e forward the arguments in the construct site without having the
copy ctor (for T only)?
probably using some macros?
i am sure this group will be able to give a good answer.
thanks
--
James Kanze (GABI Software) email:james.ka...@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