several input-output questions

J

Jess

Hello,

When I copy contents from an input string to a vector, I typically use
something like this

vector<string> v;
ifstream in("file");
copy(istream_iterator<string> (in), istream_iterator<string>(),
back_inserter(v));

However, I also tried to define istream_iterator separately. I did

istream_iterator<string> it(in);

this works, but there's no way I can define something equivalent to
istream_iterator<string>() above. I tried

istream_iterator<string> it;

and this failed. What does "istream_iterator<string>()" mean? Does
it define an iterator that's not bound to any istream? If so, why my
code above "istream_iterator<string> it;" doesn't work?

There are some error-detection functions, such as "bad(), "good()",
"fail()". I'm not sure what constitutes "errors". If I read from a
file and hit the end of the file, does it leave the stream in an error
state? If the reading reaches EOF, then do I need to use "clear()" to
reset it? If I use "clear()" to reset a stream (for whatever error
reasons), are the remaining data on the stream lost?

Thanks a lot!
Jess
 
J

John Harrison

Jess said:
Hello,

When I copy contents from an input string to a vector, I typically use
something like this

vector<string> v;
ifstream in("file");
copy(istream_iterator<string> (in), istream_iterator<string>(),
back_inserter(v));

However, I also tried to define istream_iterator separately. I did

istream_iterator<string> it(in);

this works, but there's no way I can define something equivalent to
istream_iterator<string>() above. I tried

istream_iterator<string> it;

and this failed.

It should work (apart from the fact that you seem to have used the
variable name 'it' twice). What error did you get?

What does "istream_iterator said:
it define an iterator that's not bound to any istream? If so, why my
code above "istream_iterator<string> it;" doesn't work?

There are some error-detection functions, such as "bad(), "good()",
"fail()". I'm not sure what constitutes "errors". If I read from a
file and hit the end of the file, does it leave the stream in an error
state?

Yes

If the reading reaches EOF, then do I need to use "clear()" to
reset it?

Yes, but be careful here, reaching the end of file is not the same as
trying to read past the end of file. Only the latter is an error.

If I use "clear()" to reset a stream (for whatever error
 
J

Jess

It should work (apart from the fact that you seem to have used the
variable name 'it' twice). What error did you get?

Thanks, I tried it again, and this error disappears. :) By the way,
it seems both "istream_iterator it();" and "istream_iterator it;"
work, is there any difference?
Jess
 
R

Robert Bauck Hamar

Jess said:
Thanks, I tried it again, and this error disappears. :) By the way,
it seems both "istream_iterator it();" and "istream_iterator it;"
work, is there any difference?

istream_iterator it();

declares it as a function returning an istream_iterator, whereas

istream_iterator it;

defines it as an istream_iterator object and calls its default constructor.
 
J

John Harrison

Jess said:
Thanks, I tried it again, and this error disappears. :) By the way,
it seems both "istream_iterator it();" and "istream_iterator it;"
work, is there any difference?
Jess

Well this time I will say that it should NOT work. This

istream_iterator<string> it;

declares a variable called 'it' of type istream_iterator<string>, no
problem. But this

istream_iterator<string> it();

declares a FUNCTION called 'it' which takes zero arguments and returns a
istream_iterator<string>. This is a common newbie mistake, by adding the
brackets you've written a function prototype.

I guess this was the source of your original confusion.

john
 
O

Obnoxious User

I see my problems now, thanks!

On the other hand, in program

copy(istream_iterator<string> (in), istream_iterator<string>(),
back_inserter(v));

Does it convert "in" to an istream_iterator<string>? If so, what is
"istream_iterator<string>()"? Neither of them looks like a function
call or constructing an istream_iterator<string> object...

Jess

'istream_iterator<string>(in)' creates a temporary object based on 'in'
'istream_iterator<string>()' creates a temporary object representing the
end iterator.
'back_inserter(v)' creates a temporary object

Consider:

class T {};

T t = T();
 
J

Jess

I see my problems now, thanks!

On the other hand, in program

copy(istream_iterator<string> (in), istream_iterator<string>(),
back_inserter(v));

Does it convert "in" to an istream_iterator<string>? If so, what is
"istream_iterator<string>()"? Neither of them looks like a function
call or constructing an istream_iterator<string> object...

Jess
 
J

Jess

'istream_iterator<string>(in)' creates a temporary object based on 'in'
'istream_iterator<string>()' creates a temporary object representing the
end iterator.
'back_inserter(v)' creates a temporary object
Consider:

class T {};

T t = T();

I'm sometimes confused by the object creation syntax. To create an
object t of type T, I think I can use the following statements.

T t; //default constructor
T t(arg); //constructor with argument arg
T t = T(); //call default constructor for T()? then call copy
constructor to create t using the temporary object created from T()
T t = T(arg); //does the right hand side call the constructor with
argument arg, then call the copy constructor to get t?
T t = existing_t_object;
T* tp = new T; //call default constructor
T* tp = new T(arg); //constructor with argument arg

Are they correct? Have I missed something?

Thanks,
Jess
 
J

James Kanze

I see my problems now, thanks!
On the other hand, in program
copy(istream_iterator<string> (in), istream_iterator<string>(),
back_inserter(v));
Does it convert "in" to an istream_iterator<string>? If so, what is
"istream_iterator<string>()"? Neither of them looks like a function
call or constructing an istream_iterator<string> object...

According to the standard, they are both function style casts.
The first converting in into an istream_iterator<string>, and
the second converting nothing into an istream_iterator<string>.
In practice, most people view them as explicit creation of a
temporary, the first initialized with "in", and the second
initialized using the default constructor. (Converting nothing
into something doesn't sound much like a cast in most people's
mind, regardless of what the standard calls it.)
 
J

James Kanze

I'm sometimes confused by the object creation syntax. To create an
object t of type T, I think I can use the following statements.
T t; //default constructor
T t(arg); //constructor with argument arg
T t = T(); //call default constructor for T()? then call copy
constructor to create t using the temporary object created from T()
T t = T(arg); //does the right hand side call the constructor with
argument arg, then call the copy constructor to get t?
T t = existing_t_object;
T* tp = new T; //call default constructor
T* tp = new T(arg); //constructor with argument arg
Are they correct? Have I missed something?

They're all correct for creating named objects. There are,
however, two types unnamed objects: those created using operator
new (dynamically allocated objects), and temporary objects. A
temporary object is the result of an expression: in the case of
an object of class type, a function call or a "cast". Thus, for
example: "static_cast< T >( arg )" behaves exactly like "T
t(arg)", except that the resulting object is unnamed. Of
course, there are two other ways of writing
"static_cast<T>(arg)": "(T)arg" and "T(arg)". In the latter
case, the standard also allows 0 or more than one argument; it
still calls it a cast, even if it doesn't seem very logical.
 
J

Jess

They're all correct for creating named objects. There are,
however, two types unnamed objects: those created using operator
new (dynamically allocated objects), and temporary objects. A
temporary object is the result of an expression: in the case of
an object of class type, a function call or a "cast". Thus, for
example: "static_cast< T >( arg )" behaves exactly like "T
t(arg)", except that the resulting object is unnamed. Of
course, there are two other ways of writing
"static_cast<T>(arg)": "(T)arg" and "T(arg)". In the latter
case, the standard also allows 0 or more than one argument; it
still calls it a cast, even if it doesn't seem very logical.

--
James Kanze (Gabi Software) email: (e-mail address removed)
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

I see now, thanks a lot!
Jess
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,534
Members
45,007
Latest member
obedient dusk

Latest Threads

Top