Portability problem with STL-vector

[Markus Mottl]

Hello!

The following piece of code demonstrates a portability problem of the
STL-vector class (egcs-2.91.57):

file: foo.cc, compile with 'g++ foo.cc'
---------------------------------------------------------------------------
#include <vector>

// This bug appears for all instances of 'vector'

// This works with Linux/Intel but not with Digital Unix 4.0d/Alpha
unsigned int dim1 = 0;
vector<char> vec1 (dim1, 'a');

// Vice versa
long unsigned int dim2 = 0;
vector<char> vec2 (dim2, 'a');

// These always work
vector<char> vec3 (dim1);
vector<char> vec4 (dim2);
---------------------------------------------------------------------------

The error message on the Alpha:
foo.cc: In function `(static initializers for
/usr/local/include/g++/stl_algobase.h)':
foo.cc:7: call of overloaded `vector(unsigned int &, char)' is ambiguous
/usr/local/include/g++/stl_vector.h:98: candidates are:
vector<char,__default_alloc_template<false,0> >::vector<char, alloc>(long
unsigned int, const char &)
/usr/local/include/g++/stl_vector.h:99:
vector<char,__default_alloc_template<false,0> >::vector<char, alloc>(int,
const char &)
/usr/local/include/g++/stl_vector.h:100:
vector<char,__default_alloc_template<false,0> >::vector<char, alloc>(long
int, const char &)

The error message on Linux:
/usr/local/include/g++/stl_vector.h:98: candidates are:
vector<char,__default_alloc_template<false,0> >::vector<char, alloc>
(unsigned int, const char &)
/usr/local/include/g++/stl_vector.h:99:
vector<char,__default_alloc_template<false,0> >::vector<char, alloc>(int,
const char &)
/usr/local/include/g++/stl_vector.h:100:
vector<char,__default_alloc_template<false,0> >::vector<char, alloc>(long
int, const char &)

Digital's 'cxx' compiles the code without problems.

The problem has probably to do with the different sizes of integer
representation on both machines. 'long unsigned int' and 'unsigned int'
have different size on the Alpha (8/4), on Intel the same (4/4).

g++ obviously failes to resolve the overloading of the constructor,
because the library does not supply an unambiguous case. 'size_type'
seems to default to the size that comes closest to the one used by the
the machine, but the library does not provide any information for the
other case.

I am not sure, but shouldn't the compiler handle coercion to the
'right' size?

Regards,
Markus Mottl

-- 
*  Markus Mottl              |  University of Economics and       *
*  Department of Applied     |  Business Administration           *
*  Computer Science          |  Vienna, Austria                   *
*  mottl@miss.wu-wien.ac.at  |  http://miss.wu-wien.ac.at/~mottl  *