Topic: istream_iterator & vector


Author: Pete Becker <petebecker@acm.org>
Date: 1998/04/28
Raw View
Mike Enright wrote:
>
> ark@research.att.com (Andrew Koenig) wrote:
>
> > VC++5.0 doesn't support member templates.
> >
>
> I *use* member templates with VC++5.0.

Those are two somewhat different statements. VC++ 5.0 does let you write
code that uses member templates, but they don't work very well. So, yes,
you can use them in rather limited situations, but they aren't robust
enough to support, for example, the Standard C++ Library.
---
[ 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              ]





Author: jkanze@otelo.ibmmail.com
Date: 1998/04/21
Raw View
In article <6hfh6h$to1$1@nnrp1.dejanews.com>#1/1,
  dietmar.kuehl@izbsoft.de wrote:
>
> Hi,
> In article <6h8n0i$okb@marianna.psu.edu>,
>   zabluda@math.psu.edu (Oleg Zabluda) wrote:
> > In comp.std.c++ dietmar.kuehl@claas-solutions.de wrote:
> > : BTW, the following does *NOT* what most people do expect:
> >
> > :  vector<int> vec(istream_iterator<int>(cin), istream_iterator<int>());
> >
> > : I'd expect this to define a 'vector' which is initialized by reading
from
> > : 'cin'. The truth is nearly worth a "Guru of the Week"...
>
> > It does exactly what you say, short of possibly entering
> > an infinite loop, and consequently throwing bad_alloc if there
> > is an i/o or format error while reading from cin, or some other
> > error condition occurs, i.e. cin.eof() will never return true.
>
> There will be no infinite loop! Equivalence of 'istream_iterator's is
defined
> to be either both valid or both invalid (where validity refers to any error
> bits being set). This does not really become clear from Nov'96 DWP but it
is
> clearly the intention. However, whatever error condition is hit, the two
> iterators will compare equivalent afterwards. Thus, there is no danger of
an
> infinite loop.
>
> Er, which two iterators am I talking off? In the declaration (at least, it
is
> indeed a declaration) there is only ONE iterator! In fact, this declaration
is
> NOT a definition of a 'vector<int>'. It is a declaration of a function
> returning a 'vector<int>' named 'vec'. It takes two arguments: An
> 'istream_iterator<int>', which is named 'cin', and a function with no
> arguments returning an 'istream_iterator<int>'. The second argument is not
> named.

Can a function parameter have the type "function ..."?  This is news to
me; you certainly cannot pass a function as an argument.  (If you pass
the name of a function, it is converted to a pointer to function, whose
type in this case would be istream_iterator<int>(*)().)

If you cannot declare a function with a parameter of type function...,
then either the above declaration is illegal, and the compiler should
complain, or, because the context does not allow a function declaration,
the presumed second argument cannot be parsed as a declaration, and
so must be an initializer, like most people would expect.  (Which of
these two depends on the order in which the compiler is required to
make its decisions.)

Of course, in real life, this particular case wouldn't occur, because
we all know that you have to put parentheses around the type name (or
use some other form of cast syntax) when invoking an explicit constructor
with a single argument, don't we? :-)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
        +49 (0)69 66 45 33 10    mailto: jkanze@otelo.ibmmail.com
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading


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






Author: enrightm@acm.org (Mike Enright)
Date: 1998/04/23
Raw View
ark@research.att.com (Andrew Koenig) wrote:

>> Bing Ran (bing_ran@bc.sympatico.ca) wrote:
>
>> The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
>> VC++5.0 or G++2.8
>>
>><snip something that doesn't compile>
>> the construction of b is not accepted.
>
>> Any idea?
>
>The constructor that makes a vector from two iterators is a
>member template.  VC++5.0 doesn't support member templates.
>

I *use* member templates with VC++5.0.

--
Mike Enright
enrightm@acm.org (Email replies cheerfully ignored, use the news group)
http://www.users.cts.com/sd/m/menright/
Cardiff-by-the-Sea, California, USA



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






Author: dietmar.kuehl@claas-solutions.de
Date: 1998/04/17
Raw View
Hi,
In article <6h380m$2un$1@news.bctel.net>,
  "Bing Ran" <bing_ran@bc.sympatico.ca> wrote:
>     ifstream is(from.c_str());
>     istream_iterator<string> ii(is);
>     istream_iterator<string> eos;
>
>     vector<string> b(ii, ios);   // !!!!! not compile
                           ^
Have you tried using 'eos' instead? This should compile...

BTW, the following does *NOT* what most people do expect:

      vector<int> vec(istream_iterator<int>(cin), istream_iterator<int>());

I'd expect this to define a 'vector' which is initialized by reading from
'cin'. The truth is nearly worth a "Guru of the Week"...

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]





Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/04/17
Raw View
In comp.std.c++ Bing Ran <bing_ran@bc.sympatico.ca> wrote:
: The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
: VC++5.0 or G++2.8

: ...
:     ifstream is(from.c_str());
:     istream_iterator<string> ii(is);
:     istream_iterator<string> eos;

:     vector<string> b(ii, ios);   // !!!!! not compile
: ....

: the construction of b is not accepted.

1. Typo. Should be eos, not ios.
2. ios is a name of a class.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.


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






Author: Oleg Zabluda <zabluda@math.psu.edu>
Date: 1998/04/19
Raw View
In comp.std.c++ dietmar.kuehl@claas-solutions.de wrote:
: BTW, the following does *NOT* what most people do expect:

:       vector<int> vec(istream_iterator<int>(cin), istream_iterator<int>());

: I'd expect this to define a 'vector' which is initialized by reading from
: 'cin'. The truth is nearly worth a "Guru of the Week"...

Ok, I'll bite. Even if it'll make me only a "Guru of the day" [1]

It does exactly what you say, short of possibly entering
an infinite loop, and consequently throwing bad_alloc if there
is an i/o or format error while reading from cin, or some other
error condition occurs, i.e. cin.eof() will never return true.

Which means that one should set an appropriate exceptions bitmask
on cin, before attempting that. Hmm....

If you are one of those ``bad user input is not an exception''
people :-), then, I guess, you'd have to write a bunch of
your own iterators, which compare equal to an ``end of stream''
iterator, not only if you've reached the end of file, but also
if you've encountered one of the above mentioned errors as well.

Any other takers?

[1] I hope it will not be an ``embarasment of the month''.

Oleg.
--
Life is a sexually transmitted, 100% lethal disease.
---
[ 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              ]





Author: dietmar.kuehl@claas-solutions.de
Date: 1998/04/20
Raw View
Hi,
In article <6h8n0i$okb@marianna.psu.edu>,
  zabluda@math.psu.edu (Oleg Zabluda) wrote:
> In comp.std.c++ dietmar.kuehl@claas-solutions.de wrote:
> : BTW, the following does *NOT* what most people do expect:
>
> :  vector<int> vec(istream_iterator<int>(cin), istream_iterator<int>());
>
> : I'd expect this to define a 'vector' which is initialized by reading from
> : 'cin'. The truth is nearly worth a "Guru of the Week"...

> It does exactly what you say, short of possibly entering
> an infinite loop, and consequently throwing bad_alloc if there
> is an i/o or format error while reading from cin, or some other
> error condition occurs, i.e. cin.eof() will never return true.

There will be no infinite loop! Equivalence of 'istream_iterator's is defined
to be either both valid or both invalid (where validity refers to any error
bits being set). This does not really become clear from Nov'96 DWP but it is
clearly the intention. However, whatever error condition is hit, the two
iterators will compare equivalent afterwards. Thus, there is no danger of an
infinite loop.

Er, which two iterators am I talking off? In the declaration (at least, it is
indeed a declaration) there is only ONE iterator! In fact, this declaration is
NOT a definition of a 'vector<int>'. It is a declaration of a function
returning a 'vector<int>' named 'vec'. It takes two arguments: An
'istream_iterator<int>', which is named 'cin', and a function with no
arguments returning an 'istream_iterator<int>'. The second argument is not
named.

The declaration could also be parsed as a definition of a vector. However, the
standard specifies that if there is an ambiguity between a declaration and a
definition, the declaration is used instead (dcl.ambig.res paragraph 1). The
only real surprise is the fact, that the declaration can be parsed as function
declaration (at least, it was a surprise to me...).

> [1] I hope it will not be an ``embarasment of the month''.

Well, at least nobody should blame you: at the last committee meeting Nico
Josuttis showed this example to several committee members (he came up with
this code when he tried to compile an example for his book about the standard
C++ library). Except Andrew Koenig everybody expected it to be a definition of
a vector. ... and Andy was told that it is not a definition of a vector. That
is, you are in good company.

What might be blamed is the rule resolving the ambiguity or the rule allowing
extra paranthesis around argument names in function declarations.

Finally, here is a correct definition of a vector of 'int' initialized from
'cin':

  vector<int> vec((istream_iterator<int>(cin)), (istream_iterator<int>()));

Putting extra parenthesis around the arguments removes the ambiguity since now
the declaration cannot be parsed as a declaration any longer. Actually, it
would be sufficient to put paranthesis around only one of the arguments.

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/   Now offering spam-free web-based newsreading
---
[ 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              ]





Author: "Bing Ran" <bing_ran@bc.sympatico.ca>
Date: 1998/04/16
Raw View
The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
VC++5.0 or G++2.8

...
    ifstream is(from.c_str());
    istream_iterator<string> ii(is);
    istream_iterator<string> eos;

    vector<string> b(ii, ios);   // !!!!! not compile
....

the construction of b is not accepted.

Any idea?

Bing Ran


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






Author: d922601@si.hhs.nl (Vink)
Date: 1998/04/16
Raw View
Bing Ran (bing_ran@bc.sympatico.ca) wrote:
: The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
: VC++5.0 or G++2.8

: ...
:     ifstream is(from.c_str());
:     istream_iterator<string> ii(is);
:     istream_iterator<string> eos;

:     vector<string> b(ii, ios);   // !!!!! not compile
: ....

: the construction of b is not accepted.

: Any idea?

Could it be an #include < string > or use std or something?
---
[ 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              ]





Author: ark@research.att.com (Andrew Koenig)
Date: 1998/04/16
Raw View
> Bing Ran (bing_ran@bc.sympatico.ca) wrote:

> The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
> VC++5.0 or G++2.8

> ...
>     ifstream is(from.c_str());
>     istream_iterator<string> ii(is);
>     istream_iterator<string> eos;
>
>     vector<string> b(ii, ios);   // !!!!! not compile
> ....

> the construction of b is not accepted.

> Any idea?

The constructor that makes a vector from two iterators is a
member template.  VC++5.0 doesn't support member templates.

G++2.8 does support member templates, but perhaps you're using a
version of vector that doesn't implement those constructors so
that it will compile on a compiler that doesn't support member templates.
--
    --Andrew Koenig
      ark@research.att.com
      http://www.research.att.com/info/ark



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






Author: dHarrison@worldnet.att.net (Doug Harrison)
Date: 1998/04/16
Raw View
On 16 Apr 1998 14:29:24 GMT, "Bing Ran" <bing_ran@bc.sympatico.ca>
wrote:

>The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
>VC++5.0 or G++2.8
>
>...
>    ifstream is(from.c_str());
>    istream_iterator<string> ii(is);
>    istream_iterator<string> eos;
>
>    vector<string> b(ii, ios);   // !!!!! not compile
>....
>
>the construction of b is not accepted.
>
>Any idea?

VC5's standard library implementation doesn't use member templates,
and the example relies on vector's standard InputIterator member
template ctor.

--
Doug Harrison
dHarrison@worldnet.att.net


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






Author: "Martin Ambuhl" <mambuhl@tiac.net>
Date: 1998/04/16
Raw View

Bing Ran wrote in message <6h380m$2un$1@news.bctel.net>...
:The example on page 61, "The C++ Language, 3rd Edition" doesn't compile with
:VC++5.0 or G++2.8

=========
This is based on BS's errata pages (HTML-stripped)
(If I haven't introduced errata of my own)
Note the includes (BS frequently omits these)
pg.61
#include <string>
#include <iostream>
#include <fstream>
#include <vector>
#include <algorithm>
int main()
{
    string from, to;
    cin >> from >> to;
    ifstream is(from.c_str());
    istream_iterator<string> ii(is);
    istream_iterator<string> eos;
    vector<string>b(ii, eos);
    sort(b.begin(),b.end());
    ofstream_os(to.c_str());

    ostream_iterator<string> oo(os,"\n");
    // was: ostream_iterator<string> oo(os);

    unique_copy(b.begin(),b.end(),oo);

    return (!is.eof() && !os);
    // was return (is && !os);
}

// From "unresolved issues"

*pg 61:
I write
    ostream_iterator<string> oo(os);
I got caught by using an old version of STL where ostream_iterator
was defined like this:
    template < class T>
    class ostream_iterator : public output_iterator {
    protected:
        ostream* stream;
        char* string;
        // ...
    };
The standards conforming version (pg 560) looks like this:
    template < class T, class Ch, class Tr = char_traits< Ch> >
    class ostream_iterator : public iterator<
output_iterator_tag,void,void,void,void> {
    public:
        typedef Ch char_type;
        typedef Tr traits_type;
        typedef basic_ostream< Ch,Tr> ostream_type;
        // ...
    };
Consequently, I find that my code using istream_iterators and
ostream_iterators
is broken according to the standard if not for most current implementations.
For example:
    ostream_iterator< string> oo(os);   // error: too few template arguments
It should be:
    ostream_iterator< string,char> oo(os);
The problem appears to be caused by an accidentally incomplete
conversion of ostream_iterator to use templatized streams.
I think the proper definition ought to be:
    template < class T, class Ch = char, class Tr = char_traits< Ch> >
    class ostream_iterator : public iterator<
output_iterator_tag,void,void,void,void> {
    public:
        typedef Ch char_type;
        typedef Tr traits_type;
        typedef basic_ostream< Ch,Tr> ostream_type;
        // ...
    };
I have raised the issue in the standards committee and hope to see it resolved
soon.
=========


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