Re: egcs-1.0.2 STL problem?

Re: egcs-1.0.2 STL problem?

[Pinwu Xu]

Hi there,
   I've been having problem with the following code section:

#include<proper head>

main()
{
    vector<int> a_i_vec(5, 0);  
    ....
}

if I change the main() code to
    int dummy_int(0);
    vector<int> a_i_vec(5, dummy_int);

it works. You can find the examples for the former code in
several books for STL. It would be appreciated if somebody
could shed a light.

Thanks.

Pinwu


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

Re: egcs-1.0.2 STL problem?

[Ross Smith]

Pinwu Xu wrote:
> 
> Hi there,
>    I've been having problem with the following code section:
> 
> #include<proper head>
> 
> main()
> {
>     vector<int> a_i_vec(5, 0);
>     ....
> }
> 
> if I change the main() code to
>     int dummy_int(0);
>     vector<int> a_i_vec(5, dummy_int);
> 
> it works. You can find the examples for the former code in
> several books for STL. It would be appreciated if somebody
> could shed a light.

This is a problem intrinsic to the way the STL works, not an EGCS bug.
Containers of integer types require careful casting to make some of the
constructors work properly. Two of the constructors of any sequential
container look like this:

    container<T>(container<T>::size_type n, const T& value);
    template <class InputIterator> container<T>(InputIterator first,
InputIterator last);

The size_type of a container is normally unsigned int, and its iterator
type is int*, so for a vector<int>, the first constructor wants
(unsigned, int), while the second will be happy with any two types that
can be used as iterators, including int*. So the constructor signatures
look like:

    vector<int>(unsigned, int)
    vector<int>(int*, int*) // or other specialisations

The rules of C++ say that a plain 0 can be read as either the integer
zero or a null pointer. So your first attempt can look like either
vector<int>(int, int) or vector<int>(int, int*) to the compiler. It will
happily convert this to either of the two signatures above, so you get
an ambiguity error.

You second attempt uses an integer variable rather than the constant 0,
so it can only be read as vector<int>(int, int). This converts more
easily to the first signature, so the ambiguity goes away.

You should be able to make the first version work by explicitly casting
the first argument to the right type:

    vector<int> a_i_vec(vector<int>::size_type(5), 0);

(Why not the second? Because any constant integer expression with value
0 can be read as a null pointer, so int(0) is still ambiguous. Annoying
but we're stuck with it.)

-- 
Ross Smith ............................. < mailto:ross.smith@nz.eds.com >
Internet and New Media, EDS (New Zealand) Ltd., Wellington, New Zealand
"Isn't it interesting that the same people who laugh at science fiction
listen to weather forecasts and economists?" -- Kelvin Throop III

Re: egcs-1.0.2 STL problem?

[Joe Buck]

> Hi there,
>    I've been having problem with the following code section:
> 
> #include<proper head>
> 
> main()
> {
>     vector<int> a_i_vec(5, 0);  
>     ....
> }

This is a known problem.  What's happening is that the compiler tries to
instantiate the two-iterator constructor because both arguments have the
same type.  That is, it thinks you asked for vector::vector(InputIter,
InputIter), not vector::vector(size_type n, const T& value).  Ideally we
should have specializations to take care of this case.

> if I change the main() code to
>     int dummy_int(0);
>     vector<int> a_i_vec(5, dummy_int);
> 
> it works. You can find the examples for the former code in
> several books for STL. It would be appreciated if somebody
> could shed a light.

a_i_vec(5U, 0) would also work.

Re: egcs-1.0.2 STL problem?

[Alexandre Oliva]

Pinwu Xu writes:

>     vector<int> a_i_vec(5, 0);  

This is a common STL gotcha.  Standard template class vector provides
several different constructors, and two of them are viable:

      explicit vector(size_type n, const T& value);
      template <class InputIterator>
        vector(InputIterator first, InputIterator last);

simplyfing for the case of vector<int> and instantiating the template
constructor for InputIterator=int, we get:

      vector(size_type, const int&);
      vector(int, int);

Since size_type is size_t, which is unsigned int, the second
constructor is preferred over the first one, since it is an exact
match.

>     int dummy_int(0);
>     vector<int> a_i_vec(5, dummy_int);

> it works.

egcs's STL is broken in this respect, because it defines two
non-standard constructors:

  vector(int n, const T& value) { fill_initialize(n, value); }
  vector(long n, const T& value) { fill_initialize(n, value); }

Now, since dummy_int is an lvalue (0 was not, so these constructors
were not selected because they would involve the creation of
temporaries), the first of these two constructors is selected as an
exact match.  But there constructors should not be defined, since they 
break ANSI/ISO C++ compliance.

Unfortunately, stl_vector is imported as-is from the SGI
implementation of STL.  Would someone who is in touch with SGI
developers please forward this message to them?

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: egcs-1.0.2 STL problem?

[Mark Mitchell]

>>>>> "Pinwu" == Pinwu Xu <pinwu_xu@hotmail.com> writes:

    Pinwu> Hi there, I've been having problem with the following code
    Pinwu> section:

    Pinwu> #include<proper head>

    Pinwu> main() { vector<int> a_i_vec(5, 0); ....  }

    Pinwu> if I change the main() code to int dummy_int(0);
    Pinwu> vector<int> a_i_vec(5, dummy_int);

    Pinwu> it works. You can find the examples for the former code in
    Pinwu> several books for STL. It would be appreciated if somebody
    Pinwu> could shed a light.

I believe some discussion of this is in the FAQ.

    Pinwu> Thanks.

    Pinwu> Pinwu


    Pinwu> ______________________________________________________ Get
    Pinwu> Your Private, Free Email at http://www.hotmail.com




-- 
Mark Mitchell <mmitchell@usa.net>
http://home.earthlink.net/~mbmitchell
Consulting Services Available

Re: egcs-1.0.2 STL problem?

[Branko Cibej]

Pinwu Xu wrote:

> I've been having problem with the following code section:
>
> #include<proper head>
>
> main()
> {
>     vector<int> a_i_vec(5, 0);
>     ....
> }
>
> if I change the main() code to
>     int dummy_int(0);
>     vector<int> a_i_vec(5, dummy_int);
>
> it works. You can find the examples for the former code in
> several books for STL. It would be appreciated if somebody
> could shed a light.

What kind of problems?

There may be a problem because vector has two similar constructors:

     explicit vector(size_type n, const T& value = T(),
                     const Allocator& = Allocator());

     template <class InputIterator>
         vector(InputIterator first, InputIterator last,
                const Allocator& = Allocator());

Your first declaration fits both of these; but, as you found out,
you can work around the ambiguity by writing

     vector<int> a_i_vec(5, int(0));

(BTW, this question does not really belong to the egcs list; in
fact, I think it's actually answered in the comp.std.c++ FAQ.)

    Brane

--
Branko Cibej   <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
phone: (++386 61) 186 53 49  fax: (++386 61) 186 52 70

Re: egcs-1.0.2 STL problem?

[Nathan Myers]

Alexandre Oliva wrote:

> egcs's STL is broken in this respect, because it defines two
> non-standard constructors:
> 
>   vector(int n, const T& value) { fill_initialize(n, value); }
>   vector(long n, const T& value) { fill_initialize(n, value); }
> 
> Now, since dummy_int is an lvalue (0 was not, so these constructors
> were not selected because they would involve the creation of
> temporaries), the first of these two constructors is selected as an
> exact match.  But there constructors should not be defined, since they
> break ANSI/ISO C++ compliance.
> 
> Unfortunately, stl_vector is imported as-is from the SGI
> implementation of STL.  Would someone who is in touch with SGI
> developers please forward this message to them?

Matt knows about it.  They should not be in the next release of
the SGI STL; likewise the next unsupported/isolib snapshot.

Nathan Myers
ncm@cantrip.org

Re: egcs-1.0.2 STL problem?

[Pinwu Xu]

>Pinwu Xu writes:
>
>>     vector<int> a_i_vec(5, 0);  
>
>This is a common STL gotcha.  Standard template class vector provides
>several different constructors, and two of them are viable:
>
>      explicit vector(size_type n, const T& value);
>      template <class InputIterator>
>        vector(InputIterator first, InputIterator last);
>
>simplyfing for the case of vector<int> and instantiating the template
>constructor for InputIterator=int, we get:
>
>      vector(size_type, const int&);
>      vector(int, int);
>
>Since size_type is size_t, which is unsigned int, the second
>constructor is preferred over the first one, since it is an exact
>match.
>
>>     int dummy_int(0);
>>     vector<int> a_i_vec(5, dummy_int);
>
>> it works.
>
>egcs's STL is broken in this respect, because it defines two
>non-standard constructors:
>
>  vector(int n, const T& value) { fill_initialize(n, value); }
>  vector(long n, const T& value) { fill_initialize(n, value); }
>
>Now, since dummy_int is an lvalue (0 was not, so these constructors
>were not selected because they would involve the creation of
>temporaries), the first of these two constructors is selected as an
>exact match.  But there constructors should not be defined, since they 
>break ANSI/ISO C++ compliance.
>
>Unfortunately, stl_vector is imported as-is from the SGI
>implementation of STL.  Would someone who is in touch with SGI
>developers please forward this message to them?

Thanks for all who answered, and helped. Though I put what I found
working to the list, it is clumsy, comparing to 
  vector<int> aIntV(5U, 0);

I was also curious how other people deal with this problem, cause
I felt that this was a quite common one.

Later.

Pinwu

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com