In article <8hggsi$4881@interserv.etn.com>,
brey@ductape.net says...
> What is the reasoning behind the blanket requirement in 23.1/3 that all
> objects stored by any of the container classes be Assignable?

A container never stores the original, and never returns what is in it.
It always stores a copy of the original and returns a copy of what's in
it.  In one sense, you can think of it as a black box that copies on the
way in and copies on the way out.  What is actually inside you can
*NEVER* access.  It is forever inaccessible!

Therefore things going into a container absolutely have to be able to be
copied.  C++ structs/classes having well-behaved data members copy easily
and safely with no work at all:

class X { int i; string s; };
class Y { X x; };

Both X and Y above copy without any work on your part.  No need to define
a copy constructor or an assignment operator.  The rules of C++ establish
memberwise assignment which works perfectly well on class X and Y above.

If you store and manage a pointer in a class, such as allocating in the
constructor and deallocating in the destructor, then beware when using it
in a container!  You will definitely then need both a copy constructor
and assignment operator.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 7 Jun 2000 01:32:31 CST, Max Polk <none@none.invalid> wrote:

> In article <8hggsi$4881@interserv.etn.com>,
> brey@ductape.net says...
> > What is the reasoning behind the blanket requirement in 23.1/3 that all
> > objects stored by any of the container classes be Assignable?
>
> A container never stores the original, and never returns what is in it.
> It always stores a copy of the original and returns a copy of what's in
> it.

I think you missed the point of the question.  It asks about assignment.
A node based container has no need for assignment.  It can copy
construct.

Consider map.  Value type is pair<Key const, Value> which is not
assignable.  It works fine.  Of course, that means that map is not
a container because containers have assignable value types. ;-)

John

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

What is the reasoning behind the blanket requirement in 23.1/3 that all
objects stored by any of the container classes be Assignable?  I can see how
being assignable would be helpful for vector, but for containers and
operations that do not invalidate references except on removal of an
element, when can Assignable be useful?

Requiring elements be Assignable puts an unnecessary burden on program
design, since situations like this result in undefined behavior:

#include <deque>
struct A {
 int& i;
 A(int& i) : i(i) {}
};

int main() {
 int i = 3;
 std::deque<A> d;
 d.push_back(i);
}

Had I performed an insert in the middle of a populated deque, then I would
expect A to need an assignment operator, for the same reason as it is needed
for vector.  In this case, however, as in the case of using an associative
container, A's assignment operator should never be called.

In this example, the problem can be worked around with a pointer, but this
eliminates the nice restrictions that references provide, making program
maintenance more error prone.

I suppose an unnecessary restriction such as this doesn't qualify as a
defect, so that even if I'm not overlooking anything, loosening up the
current standard isn't an option.  If I'm wrong about this, somebody please
let me know.


A minor point I noticed in digging through the standard: In 17.3.2.1/1,
footnote 149, CopyConstructable is spelled wrong (should be
CopyConstructible).  (I found this by misspelling it myself and then
wondering how a search could possible bring up only one occurrence.)  How
should minor typos like this be addressed?  A full-blown defect report seems
like overkill.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]