how to print a filename from ifstream?

[sam]

Hi,

Can anyone tell me how to print a file name from ifstream?

the following cout code does not print the filename I created with
ifstream preivous:

ifstream is;
is.open ("text.txt");

cout << "filename in ifstream: " << is << endl;

Sam.

[SirMike]

Don't you think is a little bit stupid ?
If you know the name of a stream i design-time simply print it like
cout<<"name";

If you don't know it you must have it in a variable haven't you ?
In this case use cout<<variable;

--
SirMike
the code is my strength
http://www.sirmike.grudziadz.com

[Victor Bazarov]

sam wrote:

Can anyone tell me how to print a file name from ifstream?
Nope. Nobody can. ifstream does not retain that information.
[..]

V

[dkultasev]

I don't know if it will help you,
but if it okfor you you can do like that:
String FileName;
FileName="text.txt";
cout <<"filename ..."<<FileName<<endl;
but it is the same like SirMike said to you

[codigo]

"sam" <[e-mail]> wrote in message news:d5**********@news.hgc.com.hk...

Hi,

Can anyone tell me how to print a file name from ifstream?

the following cout code does not print the filename I created with
ifstream preivous:

ifstream is;
is.open ("text.txt");

cout << "filename in ifstream: " << is << endl;

Sam.

That doesn't make sense. The only way a file name would find itself in an
ifstream is if the filename was read / parsed from the specified file.

Don't you think that the input file stream should jealously protect the
provided filename parameter from modification during file stream processing
(even when the parameter is required to be a constant, such as in this
case)? Shouldn't this fact pop out as logicly obvious in any object that is,
or will be, processing a stream?

How would you feel if i was able to change your parachute to an umbrella
between the time you boarded the plane, jumped and hit the ground? Do you
beleive that a programmer doesn't have the responsability to protect that
parachute?

Don't laugh. The consequences of not protecting the ifstream's parameter
would be worse. Not because the ifstream never gets to hit the ground, but
because the whole world that is in (the program) enters a state of
unexpected behaviour (UB).

Have you ever heard of variables?

try:

#include <iostream>
#include <fstream>
#include <string>

int main()
{
std::string s_filename("text.txt");

std::ifstream ifs;
ifs.open(s_filename.c_str());
if (!ifs)
{
std::cout << "error while opening ";
std::cout << s_filename << std::endl;
}

std::cout << s_filename << std::endl;

return 0;
}

[Howard]

"codigo" <co****@codigo.trap.com> wrote in message
news:Kw*******************@news20.bellglobal.com.. .

"sam" <[e-mail]> wrote in message news:d5**********@news.hgc.com.hk...

Hi,

Can anyone tell me how to print a file name from ifstream?

the following cout code does not print the filename I created with
ifstream preivous:

ifstream is;
is.open ("text.txt");

cout << "filename in ifstream: " << is << endl;

Sam.
That doesn't make sense. The only way a file name would find itself in an
ifstream is if the filename was read / parsed from the specified file.

Well, that's true, given the actual design of the filestream. But it's
certainly *concievable* to envision a filestream class design that
maintained the filename as a member which could be queried. Of course, that
would mean using something like "is.name", not just "is", but it's possible.
Don't you think that the input file stream should jealously protect the
provided filename parameter from modification during file stream
processing
(even when the parameter is required to be a constant, such as in this
case)? Shouldn't this fact pop out as logicly obvious in any object that
is,
or will be, processing a stream?

How would you feel if i was able to change your parachute to an umbrella
between the time you boarded the plane, jumped and hit the ground? Do you
beleive that a programmer doesn't have the responsability to protect that
parachute?

Don't laugh. The consequences of not protecting the ifstream's parameter
would be worse. Not because the ifstream never gets to hit the ground, but
because the whole world that is in (the program) enters a state of
unexpected behaviour (UB).

Well, that's a bit over-dramatic, in my opinion. Nobody said anything about
changing the name while the stream is open, did they? And even if one were
able to attempt to change the variable while the file was open, that doesn't
mean that the world would come crashing down. It *might* screw up a given
file system if the filename were changed while the file was open, but the OS
could (and likely does) forbid that anyway, which would mean that even if
the filestream class allowed the attempt to change it, the actual action
would fail in that instance, most likely with an exception of some sort,
which it could catch as needed.

-Howard

[codigo]

"Howard" <al*****@hotmail.com> wrote in message
news:lf*********************@bgtnsc05-news.ops.worldnet.att.net...

"codigo" <co****@codigo.trap.com> wrote in message
news:Kw*******************@news20.bellglobal.com.. .

"sam" <[e-mail]> wrote in message news:d5**********@news.hgc.com.hk...

Hi,

Can anyone tell me how to print a file name from ifstream?

the following cout code does not print the filename I created with
ifstream preivous:

ifstream is;
is.open ("text.txt");

cout << "filename in ifstream: " << is << endl;

Sam.
That doesn't make sense. The only way a file name would find itself in an ifstream is if the filename was read / parsed from the specified file.

Well, that's true, given the actual design of the filestream. But it's
certainly *concievable* to envision a filestream class design that
maintained the filename as a member which could be queried. Of course,

that would mean using something like "is.name", not just "is", but it's possible.

Possible it certainly is, in fact its trivial. Would it be desireable,
probably not. The issue here is why provide access to a provided constant
string filename parameter? The OP can just as well pass a variable to the
ifstream and then manipulate the variable without bothering the ifstream or
object. I would think that efficiency is a primary concerns in the design of
such a mutating object.

Don't you think that the input file stream should jealously protect the
provided filename parameter from modification during file stream
processing
(even when the parameter is required to be a constant, such as in this
case)? Shouldn't this fact pop out as logicly obvious in any object that
is,
or will be, processing a stream?

How would you feel if i was able to change your parachute to an umbrella
between the time you boarded the plane, jumped and hit the ground? Do you beleive that a programmer doesn't have the responsability to protect that parachute?

Don't laugh. The consequences of not protecting the ifstream's parameter
would be worse. Not because the ifstream never gets to hit the ground, but because the whole world that is in (the program) enters a state of
unexpected behaviour (UB).

Well, that's a bit over-dramatic, in my opinion. Nobody said anything

about changing the name while the stream is open, did they? And even if one were able to attempt to change the variable while the file was open, that doesn't mean that the world would come crashing down. It *might* screw up a given
file system if the filename were changed while the file was open, but the OS could (and likely does) forbid that anyway, which would mean that even if
the filestream class allowed the attempt to change it, the actual action
would fail in that instance, most likely with an exception of some sort,
which it could catch as needed.

-Howard

Which brings us back to the crux of the problem. I can understand checking a
file stream's error condition bits, but why a *supplied* parameter?

#include <iostream>
#include <fstream>
#include <string>

class FileStream
{
const std::string m_filename;
std::ifstream m_ifs;
std::string m_sdata;
public:
FileStream(std::string s) : m_filename(s), m_ifs(), m_sdata("") { }
~FileStream() { }
std::string getFilename() const
{
return m_filename;
}
const std::string getData()
{
m_ifs.open(m_filename.c_str());
if (!m_ifs)
{
m_sdata = "error opening file " + m_filename;
return m_sdata;
}
std::getline(m_ifs, m_sdata);
return m_sdata;
}
};

int main()
{
std::string s("data.dat");
FileStream fs(s);

std::cout << fs.getFilename() << std::endl;
std::cout << fs.getData();

return 0;
}

output:
data.dat
the only data string

whats wrong with...

int main()
{
std::string s("data.dat");
FileStream fs(s);

std::cout << s << std::endl;
std::cout << fs.getData();

return 0;
}

and forego having to provide the getFilename() member function?

[__PPS__]

LOL

[__PPS__]

I didn't check, but I strongly believe that implementations of
std::fstream do not store name of the opened file as private member.
They just pass it over to the os (when you call open or use appropriate
constructor) and os then returns some sort of specific
handler/descriptor which is stored.

[codigo]

"__PPS__" <bl******@mail.ru> wrote in message
news:11********************@g14g2000cwa.googlegrou ps.com...

I didn't check, but I strongly believe that implementations of
std::fstream do not store name of the opened file as private member.
They just pass it over to the os (when you call open or use appropriate
constructor) and os then returns some sort of specific
handler/descriptor which is stored.

It doesn't store the filename on those implementations i've used. My
arguement was that providing such a mechanism just doesn't make sense. Even
in a class with an ifstream member.

Look at the OP's code. He's passing a constant string to the ifs instead of
storing the string for later use.

[Howard]

"codigo" <co****@codigo.trap.com> wrote in message
news:l0********************@news20.bellglobal.com. ..

"__PPS__" <bl******@mail.ru> wrote in message
news:11********************@g14g2000cwa.googlegrou ps.com...

I didn't check, but I strongly believe that implementations of
std::fstream do not store name of the opened file as private member.
They just pass it over to the os (when you call open or use appropriate
constructor) and os then returns some sort of specific
handler/descriptor which is stored.

It doesn't store the filename on those implementations i've used. My
arguement was that providing such a mechanism just doesn't make sense.
Even
in a class with an ifstream member.

Look at the OP's code. He's passing a constant string to the ifs instead
of
storing the string for later use.

Yes, I see that, and you're right, that the calling code can store that
value itself. But that's a simple case. Lots of objects are created that
store the values passed to their constructors. Why not be able to query
that information later? Suppose you had a pool of such objects. Why store
the parameters passed to each object's constructor yourself, when the
obejcts themselves can store it and you can query them later. I'll admit
that's not so likely with streams (I can't think of a major use for a pool
of streams). But in the general case, it makes perfect sense to query an
object for information passed to its constructor. That was my point.

-Howard