[Bug libstdc++/16875] Fails to compile: STL container of const pointer to X

["igodard at pacbell dot net" <gcc-bugzilla@gcc.gnu.org>]

------- Additional Comments From igodard at pacbell dot net  2004-10-06 22:04 -------
I've reopened this PR after looking at #16875 (which I can't re-open, although 
I've cross-posted this note there). The basic argument to reject that bug was 
that putting consts in a standard collection is non-sensical, because the 
collections re-organize themselves and you can't do that with a const element 
type. This seems shortsighted, as my application shows (the test case I 
submitted was simplified from the actual use).

In my application, I have a number of data values (the number is statically 
known) that I need to put into a data structure and subsequently do various 
kinds of searches on them. The searchers are not to be permitted to change the 
values once they are in the structure. Using "int" as the element and "vector" 
as the collection (mine is more complicated), the code looks something like:

     vector<const int> v;
     #define count = 5
     v.reserve(count);
     void init() { for (int i = 0; i < count; ++i) {int j; j << cin;
         v.push_back(j);}} // push_back works because it constructs, not copies
     void use() {  for_each(v.begin(), v.end(), something()); }

That is, I want to be able to use the whole algorithm and collection 
machinery without re-inventing the wheel, on a standard collection and that 
collection's contents that will be immutable once it is built. This seems a 
reasonable need to me; do you differ and still think it is non-sensical?

Ivan


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16875