Bill Wade wrote about problems specializing std::vector<T>
>
> There is an easy work-around, and that is to not specialize
> std::vector in the first place, but rather to use a different name,
> myvector<foo>, with the desired characteristics.  Unfortunately the
> work balloons, because template functions designed to work with
> vector
>
>     template<class T> void SerializeOut(const vector<T>&, destination);
>
> will also have to be modified.

I can't really address your original quandary, but as far as this
example goes, I'd recommend not putting the container in the
interface.  It may be too late, the code may already exist and have
all sorts of calls to it.

If SerializeOut() only has to iterate through the items in the
container and access them, presumably to serialize them to some
destination, then use an iterator.

I 'spose this example is a particularly sore point with me as I
recently encountered a similar situation in a project at work.  The
project is in Java, but the problem is essentially the same.  A method
of a particular class returns a Vector of items.  Throughout the rest of
the code the Vector is used, usually searched for a particular
element.

I wanted to change the Vector to a different container, one more
efficient for searching, say a Hashtable or Set.  But, since the
Vector is in the interface, and further solidified by the calling
code, I had to change about 50 files.

In my case, I wish the original programmer would have at least
returned a Container (the abstract base class of the containers in
Java's standard library).  Also if the users of the method didn't
expect a Vector (but rather a Container), then the method could have
been changed to return a Set or Hashtable, and no other code would
have needed to change.

</RANT>

Aaron


[ 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              ]

17.4.3.1/1 [lib.reserved.names] Allows programs to specialize standard
templates that depend on user defined types.  For instance if I write class
foo{...}, I can specialize std::vector<foo>.

I believe that it is currently legal for me to do the specialization so that
vector<foo> is implemented in-terms-of vector<foo*>.  I might do so in order
to speed operations that can be implemented in terms of iter_swap (such as
insert or growing capacity).  This is not a big-O speedup, but depending on
the cost of foo's copy constructor, it could be significant.  Another
benefit would be that my vector could easily provide the strong exception
guarantee (roll-back semantics) for a number of operations, such as insert.
I might also get some minor code-bloat savings, since vector<T*> might be
implemented in terms of vector<void*>.

Obviously my vector<foo> does not satisfy the contiguous requirement of
issue 69 (require vectors to be contiguous).

17.4.3.1/1 also requires that such a "specialization [meet the] library
requirements for the original template."

I would assume that means that once the DR is promoted to a TC that my
specialization will no longer be legal.

There is an easy work-around, and that is to not specialize std::vector in
the first place, but rather to use a different name, myvector<foo>, with the
desired characteristics.  Unfortunately the work balloons, because template
functions designed to work with vector

    template<class T> void SerializeOut(const vector<T>&, destination);

will also have to be modified.

Now a promise of contiguous vectors (especially for POD T) is more valuable
to me than a promise that I can write vector<foo> in the manner I described
above.  I'm just wondering if anyone sees any way to get both?




[ 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              ]