tricky stringstream-based temporary

[Kai-Uwe Bux]

Hi folks,
I have trouble writing a class, derving from stringstream, that collects
item and once it's done will write them to std::cout in one go. It works
fine except when I use it as a temporary. Here is a tiny test programm:

#include <iostream>
#include <sstream>

class Gatherer : public std::stringstre am {
public:

~Gatherer ( void ) {
std::cout << this->str() << std::endl;
}

};

int main ( void ) {
{
Gatherer() << "hello world!";
}
{
Gatherer gather;
gather << "hello world!";
}
{
Gatherer() << std::dec << "hello world!";
}
}
On my machine, it prints:

0x8049e48
hello world!
hello world!

So, clearly the first line is an address. I have no explanation for this. I
am especially puzzled by the third line. Inserting a std::dec should not
have this effect, or should it?
Best regards

Kai-Uwe

[Victor Bazarov]

"Kai-Uwe Bux" <jk********@gmx .net> wrote...

I have trouble writing a class, derving from stringstream, that collects
item and once it's done will write them to std::cout in one go. It works
fine except when I use it as a temporary. Here is a tiny test programm:

#include <iostream>
#include <sstream>

class Gatherer : public std::stringstre am {
public:

~Gatherer ( void ) {
std::cout << this->str() << std::endl;
}

};

int main ( void ) {
{
Gatherer() << "hello world!";
}
{
Gatherer gather;
gather << "hello world!";
}
{
Gatherer() << std::dec << "hello world!";
}
}
On my machine, it prints:

0x8049e48
hello world!
hello world!

So, clearly the first line is an address. I have no explanation for this. I am especially puzzled by the third line. Inserting a std::dec should not
have this effect, or should it?

I think you're running into synchronisation problem. When compiled
with Intel v4.5 or VC++ v6sp5, this code outputs three hello. When
compiled with VC++ v7.1, it prints an address first and then two
hello, just like you described.

I think what you get is that by the time the destructor is executing,
all bets are off WRT the contents of this->str(), it may not contain
anything, or return a valid object... You might be incurring the UB.
Just a guess.

Victor

[Kai-Uwe Bux]

Victor Bazarov wrote:

"Kai-Uwe Bux" <jk********@gmx .net> wrote...

I have trouble writing a class, derving from stringstream, that collects
item and once it's done will write them to std::cout in one go. It works
fine except when I use it as a temporary. Here is a tiny test programm:

#include <iostream>
#include <sstream>

class Gatherer : public std::stringstre am {
public:

~Gatherer ( void ) {
std::cout << this->str() << std::endl;
}

};

int main ( void ) {
{
Gatherer() << "hello world!";
}
{
Gatherer gather;
gather << "hello world!";
}
{
Gatherer() << std::dec << "hello world!";
}
}
On my machine, it prints:

0x8049e48
hello world!
hello world!

So, clearly the first line is an address. I have no explanation for this.

I

am especially puzzled by the third line. Inserting a std::dec should not
have this effect, or should it?

I think you're running into synchronisation problem. When compiled
with Intel v4.5 or VC++ v6sp5, this code outputs three hello. When
compiled with VC++ v7.1, it prints an address first and then two
hello, just like you described.

I think what you get is that by the time the destructor is executing,
all bets are off WRT the contents of this->str(), it may not contain
anything, or return a valid object... You might be incurring the UB.
Just a guess.

Victor

Thanks for your help.

I eliminated inheritance as a possible source of the problem:

#include <fstream>

int main ( void ) {
std::ofstream( "greeting.o ut" ) << "hello world!\n";
}
This compiles fine. But it does unexpected things (well, as of now, I
actually was expecting this):

news_group> cat greeting.out
0x8048a01news_g roup>
So the problem definitely lies in the fact that a temporary is created.
Does the standard say that temporary streams have undefined behaviour? I
was under the impression that a temporary is supposed to behave exactly
like the real thing except that for its life time there are only very few
guarantees (like it will live at least to see the completion of the
expression of which it is a part).

As of now, I am considering the possibility that it could be a bug in my
standard library.
Thanks again

Kai-Uwe

[Russell Hanneken]

Kai-Uwe Bux wrote:

int main ( void ) {
{
Gatherer() << "hello world!";
}
{
Gatherer gather;
gather << "hello world!";
}
{
Gatherer() << std::dec << "hello world!";
}
}

You're not supposed to pass a temporary for a non-const reference
parameter (in this case, the first parameter of operator<<). The result
of doing so is undefined.

--
Russell Hanneken
eu*******@cbobk .pbz
Use ROT13 to decode my email address.

[Kai-Uwe Bux]

Russell Hanneken wrote:

Kai-Uwe Bux wrote:

int main ( void ) {
{
Gatherer() << "hello world!";
}
{
Gatherer gather;
gather << "hello world!";
}
{
Gatherer() << std::dec << "hello world!";
}
}

You're not supposed to pass a temporary for a non-const reference
parameter (in this case, the first parameter of operator<<). The result
of doing so is undefined.

First off all: thank you. I was really puzzled.

Second: Could you direct me to the point in the standard where I find this.
I was just reading 12.2.5:

.... A temporary bound to a reference parameter in a function call (5.2.2)
persists until the completion of the full expression containing the call.
....

Wouldn't that have been a great place to put in a warnig? Please do not
get me wrong, I do not doubt that you are right -- I am just curious.
Thanks again

Kai-Uwe

[Siemel Naran]

Kai-Uwe Bux wrote:

{
Gatherer() << "hello world!";
}
Some background:

(1) When you call a function f(T()) then the function signature must be
either f(T) or f(const T&) but not f(T&). In other words, if the signature
is f(T&) then the argument cannot be a temporary.

(2) When you call a function T().f() then the function signature of T::f may
be either T::f() const or T::f(). In other words, you can call a non-const
member function on a temporary. This is a contrast to (1).

The reason my you see a number is that because of

Gatherer() <<

the compiler spots a temporary, and looks for member overloads
Gatherer::opera tor<< that match the function arguments. Now operator<<
const void* is implemented as a member, but operator<< const char * is
implemented as a non-member.

So while we wish the code calls

std::ostream<ch ar>& std::operator<< (ostream&, const char *);

it really calls only std::ostream::o perator<<(const void *);

As a QoI, a good compiler would probably look for both members and
non-members to call, and if it finds the non-member function is the right
one to call, issue an error or warning that the first argument cannot be a
temporary -- or at least issue an ambiguity between the two possible
operator<< to call.

So what you're seeing is the address of "hello world!". Try const char * s
= "hello world!" and then Gatherer() << s, followed by cout << (const void
*)(s), and see what happens
{
Gatherer gather;
gather << "hello world!";
}
Works as expected.
{
Gatherer() << std::dec << "hello world!";
}
}
Also works as expected. Fortunately Gatherer() << std::dec calls a member
function

basic_ostream:: operator<<(ios_ base& (*)(ios_base&))

and for member functions you are allowed to call non-const member functions
on a temporary. So this sets the decimal mode, returns an ostream&, adds
text to the ostream, and finally destroys the object and it prints what it
should.
You're not supposed to pass a temporary for a non-const reference
parameter (in this case, the first parameter of operator<<). The result
of doing so is undefined.

Right, but for the last case it's fine.
To the original problem, a possible solution is

class Gatherer : public std::stringstre am {
public:

~Gatherer ( void ) {
std::cout << d_stream.str() << std::endl;
}
template <class T>
Gatherer& operator<<(cons t T&);

private:
std::stringstre am d_stream;
};

[Siemel Naran]

"Victor Bazarov" <v.********@com Acast.net> wrote in message news:QX7yc.2123

I think you're running into synchronisation problem. When compiled
with Intel v4.5 or VC++ v6sp5, this code outputs three hello. When
compiled with VC++ v7.1, it prints an address first and then two
hello, just like you described.

MSVC7is more right than Intel or MSVC7. The compiler should never call the
non-member. The ideal compiler would give an error/warning.

[Russell Hanneken]

Kai-Uwe Bux wrote:

Russell Hanneken wrote:

You're not supposed to pass a temporary for a non-const reference
parameter (in this case, the first parameter of operator<<). The result
of doing so is undefined.

Could you direct me to the point in the standard where I find this.

I couldn't find a place where it's stated directly. I think it's more
an implication of 8.5.3, section 5, which lists the valid ways to
initialize a reference. Temporaries just don't meet the qualifications
to be an initializer for a non-const reference.

Bjarne Stroustrup puts it pretty bluntly on page 98 of _The C++
Programming Language_: "The initializer for a 'plain' T& must be an
lvalue of type T."

--
Russell Hanneken
eu*******@cbobk .pbz
Use ROT13 to decode my email address.

[Kai-Uwe Bux]

Hi,
Thank you very much for this detailed explanation. Walking me through
the problem like that was more than I could have hoped for.
Best

Kai-Uwe

[Russell Hanneken]

Siemel Naran wrote:

Gatherer() << std::dec << "hello world!";

Also works as expected. Fortunately Gatherer() << std::dec calls a member
function

basic_ostream:: operator<<(ios_ base& (*)(ios_base&))

and for member functions you are allowed to call non-const member functions
on a temporary. So this sets the decimal mode, returns an ostream&, adds
text to the ostream, and finally destroys the object and it prints what it
should.

You're not supposed to pass a temporary for a non-const reference
parameter (in this case, the first parameter of operator<<). The result
of doing so is undefined.

Right, but for the last case it's fine.

I don't follow this. The result of

Gatherer() << std::dec

is a reference to a temporary. So

(result of first expression) << "hello world!"

is an attempt to initialize a non-const reference parameter with a
temporary, which is still a problem, right?

--
Russell Hanneken
eu*******@cbobk .pbz
Use ROT13 to decode my email address.