Re: Get_Line problem (GNAT bug?)

Dmitry A. Kazakov wrote:

When End_Of_File meets a CR (Ctrl-M) it cannot know if this CR manifests
the end of the current line or both the line end and the file end.
I understand. But then I consider the specs to be broken, see below. :-)

No. It is the concept, which is broken. And that wasn't Ada, who broke it,
but crippled operating systems like Windows and Unix. In a proper OS the
line terminator is not a character.

That's a brave concept. ;-)
Why do you assign the special meaning to the line terminator? Is it *that* special in, for example, your previous post? Why not assign the special meaning to word or sentence terminator? Or anything else for that matter. Isn't it domain-specific? Do you want support from "proper OS" for all this stuff?

1. Never ever use End_Of_File with text files;
This is broken. For me, End_Of_File is a concept that is completely orthogonal to what the file contains and how it is interpreted.

Right, so see above. You need a file system which has EOF state
determinable without look ahead.

No. I might be using pipes or fifos or sockets or whatever else where EOF is not really determinable by position. It's not file system issue.

[Though I don't defend End_Of_File. I would simply remove it from Text_IO.]

But then it would be somewhere else. There would be an opportunity to specify it correctly, without messing with interpretation of the file structure.

It is true that it is defined in Text_IO and therefore it might be a hint that actually EOF is somehow entangled with interpretation of text markers, but that's not what I would expect.

Huh, what did you expect buying Windows? (:-))

I don't understand this - Windows is not involved in this discussion at all (not mentioning buying it).

2. If you yet use End_Of_File then do it for *each* character of the file;
I don't see how it might solve this problem - End_Of_File would block after first <CR> anyway.

Yes, but then at least you would know what's going on. End_Of_File happened
to be lower level (in OSI hierarchy terms) than Get_Line.

This is exactly what I would expect. End_Of_File should not mess with file structure.

Mixing levels is
asking for trouble.

Agreed.

3. As Adam has suggested, End_Error exception is the right design;
I don't find it to be "right". For me, exception is something that is unexpected. An error, usually. [...]

OK, this is a bit "theological" issue... (:-))

Indeed. :-)

My answer is no. Exception is not an error. It indicates an exceptional
state. Note that an exceptional state is a *valid* state. While an error
(bug) has no corresponding program state at all.

It's not about bugs. I have presented an example of truncated XML file - there's no bug in a program that happened to be given a broken file to digest. It's an error in a sense that the program cannot read the data that it genuinely expects. Still, the program should handle this case reasonably, so we have valid state.

Now, if the program specs says: "read the lines from input until EOF", then this for me immediately translates into a loop with some exit condition. A while loop, probably, or something in this area. "Read until" - you have a regular end-of-sequence condition here. Close to iterators. How do you write iteration routines? Do you use exceptions for the end-of-sequence condition to break the loop? In what way iteration over the container is different from reading lines from input?

(Probably the best thing would be to just have "line iterators".)

Sorry, I'm not convinced that exception might be a correct design choice for breaking the loop that reads data from well formatted file.

This is because you consider it from the C++ stand point.

Which is, of course, evil by definition. ;-)

In Ada exceptions
are efficient.

So how do you write iteration routines?

They are highly recommended for use in place of return
codes.

Good point. There is no return code here. Everything is managed at the same level. The red-light here is that with exceptions I would need to use empty "where" clause. Empty clause at the same level? Looks like goto in disguise.

End_Of_File in your program serves the
purpose of return code.

Nope. It's the end-of-sequence condition. Just like with iterators.

What is even worse, from the software design
perspective, is that one operation "give me next line" is split into two,
so that the side effect of one determines the outcome of another and
reverse.

Same with iterators.

It is a very fragile (and wrong) design. Just notice how much
efforts it requires to analyse.

Frankly, I don't find it difficult. Ada is very readable, you know. ;-)

And what for? To defend a myth, that each
loop should have only one exit?

If the specs says "read until end", then this means single exit condition to me.

Your code didn't managed that either!

Why?

Neither manages it inputs longer than 99 characters.

Good point. How should I solve this?

Do you call it clean?

Yes.

Further, even in C you wouldn't use it either.

You're right, I wouldn't. Why would I use C if C++ gets it right? ;-)

string line;
while (getline(cin, line))
{
// play with line here
}


--
Maciej Sobczak : http://www.msobczak.com/
Programming : http://www.msobczak.com/prog/
.

Relevant Pages

  • Re: long double versions of functions in gcc under Cygwin
    ... rather than the nearest enclosing one) and a decent exception ... them it doesn't seem like goto usage would be affected ... int typfun() ... Why use a for loop when it is just a while loop in disguise? ...
    (comp.lang.c)
  • Re: CInternetSession
    ... the presence of the Sleepindicates the serious design flaw. ... Sleep() calls around like pixie dust, your design is fundamentally broken and will need to ... If you use Sleepin a loop, your design is probably wrong and needs to be ... The "First Chance Exception" message usually indicates nothing harmful. ...
    (microsoft.public.vc.mfc)
  • Re: long double versions of functions in gcc under Cygwin
    ... missing feature in the language. ... named break (which could be used to break out of a specified loop ... rather than the nearest enclosing one) and a decent exception ... goto just operates on the control flow of your program. ...
    (comp.lang.c)
  • Re: Threading and Serial port issue
    ... "fails" is pretty useless information. ... If it generates an exception, ... I then sit in a loop waiting for data to arrive. ... private void SetupBoard_Click ...
    (microsoft.public.dotnet.framework.compactframework)