Error in Sutter book?

[Noah Roberts]

Item #1 in the More Exceptional C++ book uses the following construct:

fstream in;

....

process( in.is_open() ? in : cin,...);
Where process has been shown as having various multiple different
possible definitions. Among them is:

void process(basic_i stream<char>& in,..);

I get errors when I try to do this in visual studio. It looked like an
erroneous construct to me to begin with (using ternary with two
different types being passed back) so I wanted to verify that it
actually worked and it doesn't. I also tried something like so:

istream & s = in.is_open() ? in : cin;

no go.

Working with pointers does work:

istream * s = in.is_open() ? &in : &cin;

This does not:

istream * s = &(in.is_open () ? in : cin);

Is the compiler breaking the standard here or is the use of the ternary
operator flawed?

Another definition he has is:

template < typename In, typename Out>
void process(In & in, Out & out)
{
....
}

But again, how can the ternary operator be used as such:

process(in.is_o pen() ? in : cin, ...)

I suppose the compiler could be really smart and derive a template
based on istream instead of either fstream or whatever cin is but I
don't think there is such a thing, is there? Or it could create two
instances of process and create a totally different branching
construct...aga in, I don't know of any that would and that seems on the
outside of qualifying for "as if".

But if I am right, how did this make it into such a high profile book
by such a high profile author...so I question my understanding.

[Noah Roberts]

Noah Roberts wrote:

istream & s = in.is_open() ? in : cin;

I suppose the error recieved might be of benefit. It is the same for
all uses (except the one pointer use that works) of the ternary
operator in my op.
1>c:\program files\microsoft visual studio 8\vc\include\is tream(842) :
error C2248: 'std::basic_ios <_Elem,_Traits> ::basic_ios' : cannot access
private member declared in class 'std::basic_ios <_Elem,_Traits> '
1 with
1 [
1 _Elem=char,
1 _Traits=std::ch ar_traits<char>
1 ]
1 c:\program files\microsoft visual studio
8\vc\include\io s(151) : see declaration of
'std::basic_ios <_Elem,_Traits> ::basic_ios'
1 with
1 [
1 _Elem=char,
1 _Traits=std::ch ar_traits<char>
1 ]
1 This diagnostic occurred in the compiler generated function
'std::basic_ist ream<_Elem,_Tra its>::basic_ist ream(const
std::basic_istr eam<_Elem,_Trai ts&)'
1 with
1 [
1 _Elem=char,
1 _Traits=std::ch ar_traits<char>
1 ]

[loufoque]

Noah Roberts wrote:

Item #1 in the More Exceptional C++ book uses the following construct:

fstream in;

...

process( in.is_open() ? in : cin,...);
Where process has been shown as having various multiple different
possible definitions. Among them is:

void process(basic_i stream<char>& in,..);

I get errors when I try to do this in visual studio.

Works fine for me with both GCC and Comeau.

[Alf P. Steinbach]

* Noah Roberts:

Item #1 in the More Exceptional C++ book uses the following construct:

fstream in;

...

process( in.is_open() ? in : cin,...);
Where process has been shown as having various multiple different
possible definitions. Among them is:

void process(basic_i stream<char>& in,..);

I get errors when I try to do this in visual studio. It looked like an
erroneous construct to me to begin with (using ternary with two
different types being passed back) so I wanted to verify that it
actually worked and it doesn't. I also tried something like so:

istream & s = in.is_open() ? in : cin;

no go.

Working with pointers does work:

istream * s = in.is_open() ? &in : &cin;

This does not:

istream * s = &(in.is_open () ? in : cin);

Is the compiler breaking the standard here or is the use of the ternary
operator flawed?

Depends whether 'in' and 'cin' are of identical type. If they are, and
both are lvalues, the result is an lvalue. Otherwise the result is an
rvalue, which implies copying, which is meaningless for streams.
[snip]

But if I am right, how did this make it into such a high profile book
by such a high profile author...so I question my understanding.

Check the errate pages. Perhaps there's something.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Alf P. Steinbach]

* Noah Roberts:

>
But if I am right, how did this make it into such a high profile book
by such a high profile author...so I question my understanding.

I was just skimming the 2nd edition of "The C++ Programming Language" by
Bjarne Stroustrup. Here 'main' is variously declared as

int main() {}
main() {}
void main() {}

Nobody's prefect.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Noah Roberts]

Alf P. Steinbach wrote:

* Noah Roberts:

Item #1 in the More Exceptional C++ book uses the following construct:

fstream in;

...

process( in.is_open() ? in : cin,...);

Is the compiler breaking the standard here or is the use of the ternary
operator flawed?

Depends whether 'in' and 'cin' are of identical type. If they are, and
both are lvalues, the result is an lvalue. Otherwise the result is an
rvalue, which implies copying, which is meaningless for streams.

Since cin is set as an istream by the standard and in is an fstream
they are obviously not the same type even though they are related
types.

>

[snip]

But if I am right, how did this make it into such a high profile book
by such a high profile author...so I question my understanding.

Check the errate pages. Perhaps there's something.

It isn't there.

[Noah Roberts]

Alf P. Steinbach wrote:

* Noah Roberts:

But if I am right, how did this make it into such a high profile book
by such a high profile author...so I question my understanding.

I was just skimming the 2nd edition of "The C++ Programming Language" by
Bjarne Stroustrup. Here 'main' is variously declared as

int main() {}
main() {}
void main() {}

Nobody's prefect.

That's a rather minor error though. This one, if it is an error,
tosses out the entire advice given in that section. The first 5 pages
or so of the book become completely erroneous. This is why I'm trying
to figure out why I'm wrong and the book is right even though it
obviously doesn't compile on at least one pretty common compiler.

[Michael]

Item #1 in the More Exceptional C++ book uses the following construct:

>
fstream in;

...

process( in.is_open() ? in : cin,...);

Regrettably, I don't have a copy of this book, but could it be that it
declares the variable 'in' as an ifstream instead of an fstream? That
would seem to make sense in light of the downstream code

void process(basic_i stream<char>& in,..);

Michael

[Default User]

Alf P. Steinbach wrote:

* Noah Roberts:

But if I am right, how did this make it into such a high profile
book by such a high profile author...so I question my understanding.

I was just skimming the 2nd edition of "The C++ Programming Language"
by Bjarne Stroustrup. Here 'main' is variously declared as

int main() {}
main() {}
void main() {}

Nobody's prefect.

The second edition was pre-standard, I believe. The first two forms
were probably correct at the time, but I don't know about the third.
Consistency would probably have been better.


Brian

[Alf P. Steinbach]

* Noah Roberts:

Alf P. Steinbach wrote:

>* Noah Roberts:

>>Item #1 in the More Exceptional C++ book uses the following construct:

fstream in;

...

process( in.is_open() ? in : cin,...);

>>Is the compiler breaking the standard here or is the use of the ternary
operator flawed?

Depends whether 'in' and 'cin' are of identical type. If they are, and
both are lvalues, the result is an lvalue. Otherwise the result is an
rvalue, which implies copying, which is meaningless for streams.

Since cin is set as an istream by the standard and in is an fstream
they are obviously not the same type even though they are related
types.

The standard does not say anything about cin, only about std::cin.

>[snip]

>>But if I am right, how did this make it into such a high profile book
by such a high profile author...so I question my understanding.

Check the errate pages. Perhaps there's something.

It isn't there.

Too bad. Would you care to post a /complete/ code example? Then I (or
others) can say whether it's actually an error in the book (assuming
it's not an example of invalid code, discussed as such), or whether it's
a misinterpretati on or something on your part.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?