Is there a need for the definition of a container being that strict?
23.1 1 Containers are objects that store other objects. [...]

Couldn't this be left more open to allow containers not to actually hold
data, but to be able to construct the needed data on the fly? (This
would only work for const, of course). And while I am at it, why must
the container components be assignable, in the case of a non mutable
container?
Maybe a better definition would be to allow containers to be a
representation of accumulated objects and classify containers into
constant and mutable.
But maybe I am missing something entirely.

Regards,
 Axel Thimm.
--
Axel Thimm   thimm@physik.fu-berlin.de thimm@ifh.de
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Axel Thimm wrote:
>
> Is there a need for the definition of a container being that strict?
> 23.1 1 Containers are objects that store other objects. [...]

Well, IMO there is no need for this definition at all ( in the C++
standard, that is ). It is just a convenient way to describe the
standard containers and not a requirement that must be followed
rigorously. I see it rather as a coding guideline: when designing a new
class that is similar to the standard containers, try to provide the
interface described in this section because it is well known and helps
you integrate your class with the standard library. You don't have to,
though, if this is difficult or inefficient.

> Couldn't this be left more open to allow containers not to actually hold
> data, but to be able to construct the needed data on the fly?

This sounds similar to what istream_iterator does. Can't you just
provide a clever iterator class? Really, I think that such tasks are
better solved by iterator ranges. You can, of course, define an
additional class with "begin" and "end" member functions, but why do you
want to make it a container?

> Maybe a better definition would be to allow containers to be a
> representation of accumulated objects and classify containers into
> constant and mutable.

IMO you are introducing a concept which has nothing to do with the
standard containers. I think that a language standard should only
describe a conforming implementation and nothing more. I'm not saying
that the concept itself is bad - I just don't see how it could help do
define ISO C++.


Bye

Roman
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]