std::ofstream oddity

J

jl_post

Hi,

I won't get into the details, but I discovered something strange
recently.

If I have the following C++ program:

#include <iostream>
#include <fstream>
int main(int argc, char ** argv)
{
std::eek:fstream someFile("/tmp/hello.txt");
someFile << "Hello!\n";
return 0;
}

and compile and run it, I get a file named "hello.txt" containing the
following line:

Hello!

But if I replace the first two lines of the main() function with this
one line:

std::eek:fstream("/tmp/hello.txt") << "Hello!\n";

the "hello.txt" file will contain a (non-newline terminted) line like:

0x44000f

It seems to me that the second approach is writing out the hexadecimal
address of the first character of the "Hello!\n" string to file.

But why? In both cases I'm creating a std::eek:stream object and
streaming a literal string to it.

Why would creating a std::eek:fstream variable and streaming to it (the
first approach) be any different than streaming directly to the return
object of a std::eek:fstream constructor (the second approach)? I mean,
in both cases a std::eek:stream object is being constructed, right? So
why are they doing something different with the stream operator?

Thanks for any input.

-- Jean-Luc
 
A

Alf P. Steinbach

* (e-mail address removed):
Hi,

I won't get into the details, but I discovered something strange
recently.

If I have the following C++ program:

#include <iostream>
#include <fstream>
int main(int argc, char ** argv)
{
std::eek:fstream someFile("/tmp/hello.txt");
someFile << "Hello!\n";
return 0;
}

and compile and run it, I get a file named "hello.txt" containing the
following line:

Hello!

But if I replace the first two lines of the main() function with this
one line:

std::eek:fstream("/tmp/hello.txt") << "Hello!\n";

the "hello.txt" file will contain a (non-newline terminted) line like:

0x44000f

It seems to me that the second approach is writing out the hexadecimal
address of the first character of the "Hello!\n" string to file.

But why? In both cases I'm creating a std::eek:stream object and
streaming a literal string to it.

Why would creating a std::eek:fstream variable and streaming to it (the
first approach) be any different than streaming directly to the return
object of a std::eek:fstream constructor (the second approach)? I mean,
in both cases a std::eek:stream object is being constructed, right? So
why are they doing something different with the stream operator?

Thanks for any input.

In the second you case you have a temporary object, an rvalue. And an rvalue
can't be bound to reference-to-non-const-object. And the operator<< overload
that presents the text as text is a freestanding routine with just such a
reference as first argument. Hence some other operator overload is selected.
Namely the member overload that presentes a pointer value.

I think I saw something about this thing having been fixed in C++0x.

I haven't checked though.


Cheers & hth.,

- Alf
 
J

jl_post

In the second you case you have a temporary object,
an rvalue. And an rvalue can't be bound to
reference-to-non-const-object. And the operator<<
overload that presents the text as text is a
freestanding routine with just such a reference as
first argument.


Wow, Alf! Thanks for your quick response.

You seem to be absolutely correct. I tested out what you said by
replacing the second line in:

std::eek:fstream someFile("/tmp/hello.txt");
someFile << "Hello!\n";

with:

operator<<(someFile, "Hello!\n");

This writes out the line "Hello!" to the "hello.txt" file, just as
before. But when I replace that line with a method call:

someFile.operator<<("Hello!\n");

the "hello.txt" file will contain a hex value like "0x44000f".

So now I know that when I use the line:

std::eek:fstream("/tmp/hello.txt") << "Hello!\n";

it's doing the same as:

std::eek:fstream("/tmp/hello.txt").operator<<("Hello!\n");

which (as I've already determined above) writes out a hexadecimal
value.

So now I've found out how come:

std::eek:fstream("/tmp/hello.txt") << "Hello!\n";

does something different than:

std::eek:fstream someFile("/tmp/hello.txt");
someFile << "Hello!\n";

(Now I just need to figure out WHY std::eek:fstream::eek:perator<<(const
char*) writes out a hex value -- unlike operator<<(std::eek:fstream&,
const char*), which writes out the string's characters.)

Thanks for your help, Alf. I appreciate it.

-- Jean-Luc
 
R

Ron

(Now I just need to figure out WHY std::eek:fstream::eek:perator<<(const
char*) writes out a hex value -- unlike operator<<(std::eek:fstream&,
const char*), which writes out the string's characters.)

   Thanks for your help, Alf.  I appreciate it.

There is no function std::eek:fstream::eek:perator<<(const char*),
but there is one that takes a void*.
 
J

jl_post

There is no function std::eek:fstream::eek:perator<<(const char*),
but there is one that takes a void*.


Ah. That makes sense why std::eek:fstream::eek:perator<<(void*) would be
printing out a hex value when a char* is passed in.

Of course, I'd expect std::eek:fstream::eek:perator<<(const char*) to
exist, but maybe I'm expecting a bit too much...

Thanks for your input, Ron.

-- Jean-Luc
 
B

Bart van Ingen Schenau

   Ah.  That makes sense why std::eek:fstream::eek:perator<<(void*) would be
printing out a hex value when a char* is passed in.

   Of course, I'd expect std::eek:fstream::eek:perator<<(const char*) to
exist, but maybe I'm expecting a bit too much...

But why would you need std::eek:fstream::eek:perator<<(const char*), if
there is already an operator<<(std::eek:stream&, const char*)?
The only practical difference is that it can't be applied to a
temporary object, but all user-defined operator<< overloads have
exactly the same problem.
   Thanks for your input, Ron.

   -- Jean-Luc

Bart v Ingen Schenau
 

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

Similar Threads


Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,061
Latest member
KetonaraKeto

Latest Threads

Top