🚀 go-pugleaf

Drock (drock@owens.ridgecrest.ca.us) wrote:
: csigjb@luxor.latrobe.edu.au () wrote:



: >This program should exit such that the screen is clear with the DOS prompt
: >in the upper left corner, but no, it exits with a short line of text on the
: >first line and then the DOS prompt on the next line. I never (or rarely)
: >have these sort of problems with Pascal so why do they continuously crop up
: >with C.

: Well, I'm not sure why this happens but there is a couple colutions:

: The Ugly way:
: 	Use the borland graphic interface to capture the data on the screen
: before anything happens in the program. Then restore the buffer upon
: exit. In c++, this can be done using a constructor/destructor. The
: only problem is, If you are using Borland, then you have to use their
: BGI drivers. THEY SUCK!!!!!!! 

This is your professional opinion?

: The clean way. Write yourself a cool little routine that stores the
: contents of the active page. This can be done with a pointer  that is
: assigned an absolute address to video memory and treating it as an
: array. Then just use the same array to restore what the screen to it's
: original status upon exit. look up 

I thought the original poster wanted a CLEAN screen, not the ORIGINAL
screen returned.

: >PROBLEM 2 :

: >const escape=27;
: >const cr=13;
: >const bs=8;

: >while (ch!=cr)
: >{
: >     .
: >     .
: >     .
: >}

: >while (ch!=escape)
: >{
: >     .
: >     .
: >     .
: >}

: >If I replace the 27 with \27' or the 13 with '\13' then these loops don't
: >work i.e. an infinite loop results. WHY?

: >Also if I want to do somthing like this : puts("\24 \25"); which should
: >print the up and down arrows on the screen (ASCII 24 and 25), but no, it
: >prints some other ASCII characters. As far as I can tell C has its own
: >unique character table, at least for the control characters. WHY?

: >Sometimes I wonder whether some one needs to go back an rewrite the damn
: >language so that it works sensibly and predictably like Pascal can be
: >relied upon to do.

: Because when you actually press the esc key, it's ASCII value is 27,
: using /27 refers to esc  when using the printf stuff. The /13 is
: evaluated in those particular functions but I don';t think they are
: evaluated when doing a straight compare. This has happened to me
: before. If you do a printf and use /13, you get a CR , but if you read
: in a CR, you get 13. Think about it, it's only a byte value and should
: be treated as such. 

No.  I have no idea what you are talking about here, but it's wrong.

The tokens "13" and "\13" (note the reverse slash) refer to two
different va
                        -- Collins --
                        
-----
The views expressed here are mine alone.

Ron Collins/Hughes Aircraft Company/M20,P20/Tucson Az 85706
rcollins@thor.tu.hac.com	collins@seagull.rtd.com
­----
lues.  The token "13" is a decimal thirteen, which (as it
happens) is the ASCII ordinal value for a carraige-return.  The token
"\13" is an _octal_ eleven, which is ASCII vertical-tab, or control-K.

The reverse-slash notation is used within strings (using either octal
notation \ooo or hex notation \xhhh) simply because it is a convenient
method of putting otherwise non-printable characters inside a string.