Re: why vector needs an assignable requirement for object T ?
On Dec 30, 1:04 pm, abir <abirba...@gmail.com> wrote:
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.
#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.
The requirements are there because the standard doesn't want to
impose any specific implementation. Insert other than at the
end cannot be made to work correctly without assignment. More
fundamentally, the containers require a value semantic, and a
value semantic supposed assignment.
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& )
What g++ does in c++0x mode is really whatever it wants, since
there isn't (yet) a C++0x. That's an experimental mode, for the
committee members to experiment with, and it shouldn't really be
used otherwise. (At least if it is what I think it is.) And
who knows what draft it corresponds to. (There are at least two
per year.)
(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.
The requirements concern the type. If the type isn't assignable
(your type isn't), then you've violated the requirements. I get
a compiler error from g++, just by trying to instantiate the
class.
T a(1);
T b(2);
at this point a & b are object of type T, thus all the
contracts should be valid.
Contracts of what? As long as you don't instantiate a standard
container over the object type, there's no problem.
b.~T();
after this b is destroyed. It no longer an valid object, thus
it has no valid type.
On the other hand, you're going to be in deep trouble when you
leave scope. Don't even think of doing such things.
b.anything is not going to work at this point, but that
doesn't violate the contract as they are for type T.
Again, what contract are you talking about?
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.
I don't know about the "probably". Some are, some aren't. For
debugging purposes, it's probably best to not reuse the memory
too quickly.
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)?
Not today. I think that something like this is forseen for the
next version of the standard, but what it will look like exactly
is anybody's guess.
probably using some macros?
i am sure this group will be able to give a good answer.
I don't know. Sometimes, it's not clear what language you're
talking about, since much of what you're talking about isn't yet
C++, and we don't know what it will look like exactly once it
becomes C++. (Realistically, the way things are going, I
wouldn't count on any of this being usable before 2015. Maybe
later---look at export.)
--
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