is_at_eof: request for critique

[Juha Nieminen]

[While the original decision to overload << does seem pretty
questionable, by now that particular usage has become so idiomatic that
it basically isn't an issue anymore.]

OK, operator <<() is livable.

I have never understood what the problem with using operator<< is.

How many times have you needed the bit shift operator on an I/O
statement? (And even if in a one-in-a-million case you would need it,
what would be the problem with using parentheses to disambiguate?)

 

[Juha Nieminen]

Your debating technique here is somewhat trollish.

I get the impression that you accuse anybody who disagrees with you
of trolling, regardless of what the actual arguments are.

 

[Florian Weimer]

* Juha Nieminen:

I have never understood what the problem with using operator<< is.

It's problematic for I18N, and changing stream formatting is quite
cumbersome.

 

[Alf P. Steinbach /Usenet]

* Juha Nieminen, on 18.10.2010 19:03:

I get the impression that you accuse anybody who disagrees with you
of trolling, regardless of what the actual arguments are.

First you *snipped* the clarification that you sought, and went on about
something in your mind as if we'd been having a technical discussion.

Now you again *snipped* the (very short) context and try to create some
impression, which is plain lying.

What's the point?

You on a crusade or something?


- Alf

 

[Öö Tiib]

I have never understood what the problem with using operator<< is.

"livable" means possible to bear, endurable, tolerable. Not too good,
not too enjoyable, but not a real problem. You really haven't read
such points before several times? It gets too far from OP who was more
interested in input it felt ... but let me try then.

iostreams addresses the task to format the text output not that
elegantly. Sort of simplistic, cryptic and verbose outcome. printf()
family ... (especially the ones from gettext package) feel better. It
is still useful, just cumbersome and time consuming to get a text to
look natural. Also the code looks not too pretty after that.

Fine for plain pre-made "Hello world" messages, but it is rare that
you do not want to display anything calculated runtime inside of the
output. Fine with texts not meant to be internationalized, but even
selling only to Finland for example they likely expect English +
Finnish + Swedish. Might be useful for texts not meant for humans to
be read ... but there are other gotchas, i really prefer binary or XML
at such places. Boost::format repairs majority of annoyances but it
also turns majority of formatting functionality in iostreams into
obsolete. Boost is unfortunately not always available, even getting it
to compile for some smaller device that has limited console might be
troublesome. As irony of fate ... good formatting is more desirable
for such things.

How many times have you needed the bit shift operator on an I/O
statement? (And even if in a one-in-a-million case you would need it,
what would be the problem with using parentheses to disambiguate?)

Rarely. The operator itself is fine, no problems at all there.

 

[James Kanze]

Please, critique as much as you can about this function:

bool
is_at_eof( std::istream & in )
{
typedef std::istream::traits_type
traits_type ;

assert( ! in.bad() ) ;
return in.rdbuf() != NULL
&& in.rdbuf()->sgetc() == traits_type::eof() ;
}

What's it good for? I can't think of any place you might
reasonably want to use it.

 

[Gennaro Prota]

Hi James,

thanks for chiming in. You seemed to be absent and I was
despairing to get anything useful from this thread.

What's it good for? I can't think of any place you might
reasonably want to use it.

I haven't used it yet Seriously, could you be more specific?
I gave a possible (I hope) usage scenario in the reply to Maxim:
basically, I want to copy everything from standard in to
standard out but I don't want an immediate eof on std::cin
(i.e.: there are no characters to extract at all) to set an
error bit anywhere; in the specific case I wrapped the inserter
from a streambuf pointer (the wrapper is shown in that reply)
but, regardless of that particular solution, it seems to make
sense to ask std::cin if it is at eof or not. I'm very wary,
though, because I know that the subject of "predictive eof" is
full of intricacies.

I'd be very glad to have your opinion on both functions
(is_at_eof() and the mentioned wrapper).

Thanks.

 

[Gennaro Prota]

On 19/10/2010 18.19, Gennaro Prota wrote:
[...]

I haven't used it yet Seriously, could you be more specific?
I gave a possible (I hope) usage scenario in the reply to Maxim:

Oh, I forgot to say...: I changed the subject for that reply (to
'On piping cin to cout, "predictive eof" and other amenities
[was: ...]'), so it might appear in a different thread in your
newsreader.

 

[James Kanze]

* Juha Nieminen, on 16.10.2010 22:39:

Inefficient,

That depends on the implementation. There's been at least one
implementation (Dietmar Kühl's) that was faster than stdio.

complex,

They solve a complex problem, for which there are no simple
solutions.

misleading and cryptic names.

The names definitly could have been better. As could have been
the error handling. Other than that...

Books have
been written about using them (not necessary with any decent
design). They use that abomination, two-phase initialization.

What do you consider "two-phase initialization" here? You can't
guarantee that a stream will be usable for its full lifetime.
So the usual criticism just doesn't apply: it's not two-phase
initialization, it's the fact that at any time, the stream may
enter a bad state (including asynchronously).

They don't support exceptions (or rather, the support that's
present is completely impractical and unusable).

I'd say rather that they allow you to use exceptions too much.
But you don't have to.

They're
modal, in particular error mode,

That's what you want for error handling when dealing with
streams.

but also all that formatting stuff.

The modality there could be better defined, but I've yet to see
anyone propose a viable alternative.

They willy-nilly mix abstraction levels.

Are you kidding? They cleanly separate sinking and sourcing
from formatting.

They strongly couple locale and internationalization stuff to
basic i/o.

Yes and no. They're not designed to handle "basic i/o", any
more than FILE* is. For basic I/O, you have to go to the system
level; neither C++ nor C has a portable abstraction.

They even have Undefined Behavior for the most basic things,
such as inputting hex numbers.

That was an oversight, which has been fixed (and was never an
issue in any real implementations, which all did the right
thing).

And what are you proposing as an alternative?

 

[James Kanze]

* Juha Nieminen:

It's problematic for I18N, and changing stream formatting is
quite cumbersome.

It does break up the strings, so that you can't just extract
them and send them to the translator. But in practice, just
extracting them and sending them to the translator doesn't work
for any of the other systems I've seen either. The translator
needs even more context to do a decent job.

The correct way of handling internationalization is to send the
storybook which provided your original strings to the
translator, and then implement the translations in a different
DLL. (You need to anyway, since different languages have
radically different grammars.)

 

[James Kanze]

Well, having this would have a double purpose: first, as you
know, calling eof() on a given istream object isn't a reliable
way to know if it is at eof or not;

No, but calling fail() after reading an object is a reliable way
of knowing whether you've successfully read the object or not.
And as long as streams support input of various types (rather
than just bytes), there's no way to know whether the next read
will fail because of EOF or not. It's simply not possible
before knowing whether the next read will skip spaces or not.