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]

Re: Error in Sutter book?


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]

Re: Error in Sutter book?

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]

Re: 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?

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]

Re: Error in Sutter book?

* 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]

Re: Error in Sutter book?


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]

Re: Error in Sutter book?


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]

Re: Error in Sutter book?

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]

Re: Error in Sutter book?

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]

Re: Error in Sutter book?

* 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?

[bjarne]

Re: Error in Sutter book?


Noah Roberts wrote:

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.

Indeed. However, that 2nd edition was published in 1991. It's a
venerable antique. Retire it to a top shelf somewhere and try again
with an up-to-date book, such as my 3rd edition - especially recent
printings; I maintain my books.

In 1991, seven years before we managed to ban "implicit int" in the
standard, plain

main() { }

was legal, as it had been since the first days of C.

"void main()" never was legal in C or C++. See :

http://www.research.att.com/~bs/bs_faq2.html#void-main

Assuming I wrote "void main", it was a bug. As somone said "nobody is
perfect". I had a quick look, but didn't find any occurrences of "void
main".

-- Bajrne Stroustrup; http://www.research.att.com/~bs

[Noah Roberts]

Re: Error in Sutter book?


Alf P. Steinbach wrote:

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

That's not being honest Alf. You know exactly to what I refer.

>
>

[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.

2. Write an ECHO program that simply echoes its input and that can be
invoked equivalently in the two following ways:

ECHO <infile >outfile
ECHO infile outfile

The Tersest Solution:


#include <iostream>
#include <fstream>

int main(int argc, char* argv[])
{
using namespace std;

(argc 2
? ofstream(argv[2], ios::out | ios::binary)
: cout)
<<
(argc 1
? ifstream(argv[1], ios::in | ios::binary)
: cin)
.rdbuf();
}


VC++ 8 output:


1>playground.cp p
1>c:\program files\microsoft visual studio 8\vc\include\os tream(581) :
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_ost ream<_Elem,_Tra its>::basic_ost ream(const
std::basic_ostr eam<_Elem,_Trai ts&)'
1 with
1 [
1 _Elem=char,
1 _Traits=std::ch ar_traits<char>
1 ]
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 ]
1>Project : warning PRJ0018 :

[Noah Roberts]

Re: Error in Sutter book?


Michael wrote:

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

No, it doesn't. In the terse example he does though and that also
doesn't work on this compiler.

[Noah Roberts]

Re: Error in Sutter book?


Noah Roberts wrote:

Michael wrote:

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

>
No, it doesn't.

err, it makes sense...the book doesn't do it.


In the terse example he does though and that also

doesn't work on this compiler.

[Old Wolf]

Re: Error in Sutter book?

Noah Roberts wrote:

I also tried something like so:
>
fstream in;
istream & s = in.is_open() ? in : cin;
>
no go.

It works for me. The error message you posted, doesn't seem to
correspond to this construct. Can you post a complete program
that gives the error? (and the error itself that that program gives
you).

Also, try this:
istream & s = in.is_open() ? static_cast<ist ream &>(in) : cin;

Then the compiler will know to convert cin to istream& .