macOS Escape sequences in C

[cybrscot]

Hi all, I'm reading about escape sequences in C and it's confusing me. I always thought of an "escape" being just that, the \n "escapes" to the next line.

Now I'm reading about them with regards to character constants. For example, a constant representing the escape character would be written '\33 (or '\x1b').

I don't understand the above claim at all. Since it says "a constant representing the escape character" I'm assuming that '\33 and '\x1b' are the constants it's using as an example, and is the book saying that they represent the escape character.......are they referring to \n ??

Since \n "escapes" to a new line, why do we need to confuse everything and use a numerical constant to represent an escape?? I don't get it at all? If I want to escape to a new line, why not just always use \n? Why would I ever want to write my escape character as '\33? Is it cooler to do? What's the point in this?

 

[lee1210]

The primary problem is with your understanding of "escape" and your book failing to lay it out properly. There are a lot of characters that we can't readily type and display in source code. An escape sequence is used to represent a character value without that character appearing literally. \n is popular, \t is also. \" is a good one, as is \\. These sequences are special, but the numeric form allows you to escape any character you want. Maybe A would be too straight-forward, so \x41 can be used instead.

The name originated because the esc key was used originally, but you just need to know that the \ means the characters that come next will be interpreted specially.

-Lee

 

[cybrscot]

The name originated because the esc key was used originally, but you just need to know that the \ means the characters that come next will be interpreted specially.

-Lee

Thanks Lee, this bit helps a lot. So \ just really means to pay attention to what is next. I understand that to print an "\" you need to type \\, because that first \ allows the second \ to be displayed, just like comments right?

How can I understand this snippet from my book,

do {
    scanf ("%c", &ch);
  } while (ch != '\n');

//When scanf is called the next time, it will read the first character on the next input line.

When I read the code, I read it as a loop that allows the user to continue to enter characters, stored in ch, this loop continues until the user enters \n.

I'm pretty sure my understanding is wrong, because when would any user ever enter \n?? Are they referring to the entire \n? Or just the "n", which is the special character after the \ symbol?

Further, if I'm on track or completely off track how does the books explanation of

"When scanf is called the next time, it will read the first character on the next input line" Is the \n in the above loop telling the computer to go to a new line, just like in my previous programs?

 

[lee1210]

\n has a special meaning. It represents a newline. In output you use this to go to the next line. In input this appears when the user strikes enter. Hopefully your book has a list of the special characters that can be used after \ and what characters they represent.

That code will read characters until a newline is encountered. That means the user pressed enter, which is typically assumed to mean "I'm done typing, here you go".

With \\ you need both because just one will start an escape sequence and use the next character(s) to complete the sequence. When you are typing a string or character literal you can't type """ or ''' to have a string with a " or the ' character, because those are the delimiters for the literal. So you have to type "\"" or '\''. I didn't follow your comment about // for in-code comments. This isn't really related. I suppose / is the division operator, so that alone can't be reused elsewhere, but // /* */ are just syntax structures and aren't really related to escape sequences.

-Lee

 

[cybrscot]

That code will read characters until a newline is encountered. That means the user pressed enter, which is typically assumed to mean "I'm done typing, here you go".
-Lee

Ahhh, that makes sense. No the book doesn't connect the dots that the \n in input means the enter key is pressed. I had no idea. Why don't they explain this stuff better?

But since my example from the book was a loop, how does the loop in fact loop if they can't press the enter key? If a user types the following characters, example: atmbhiijsk, this was typed without hitting enter, and of course there is no loop here. But the books loop example says it will keep reading and storing characters until the (ch != '\n'), which means, according to your explanation above, that the user just hit the enter key.

 

[lee1210]

Ahhh, that makes sense. No the book doesn't connect the dots that the \n in input means the enter key is pressed. I had no idea. Why don't they explain this stuff better?

But since my example from the book was a loop, how does the loop in fact loop if they can't press the enter key? If a user types the following characters, example: atmbhiijsk, this was typed without hitting enter, and of course there is no loop here. But the books loop example says it will keep reading and storing characters until the (ch != '\n'), which means, according to your explanation above, that the user just hit the enter key.

scanf doesn't wait for enter to be pressed, it will read input as it is entered. There are other input routines that read a line at a time, which do wait for an enter before they return. In this case if the user enters some characters without pressing enter your program will be sitting at the scanf waiting for another character to be entered. This will continue forever until the user presses enter, resulting in ch equaling a newline, resulting in the loop exiting.

-Lee

 

[cybrscot]

Oh, ding ding ding! Finally!!

The book also says (further down)"consider the scanf loop that we used to skip the rest of an input line" (which is the same loop we're discussing)

After your comments Lee, it just clicked, I think.

If the user is entering characters, a, b, t, j, m, l, p, etc scanf will read each one and store in ch. But when they hit enter, the scan will stop. Enter is hence the \n symbol on the input side as you explained to me.

Why does the book say "used to skip the rest of an input line"? I'm assuming "an input line" is the input before the user hits the enter key, right? So, if they did enter a, b, t, j, m, l, p then hit enter. The loop ends, but what was skipped in the previous input line?

 

[lee1210]

Oh, ding ding ding! Finally!!

The book also says (further down)"consider the scanf loop that we used to skip the rest of an input line" (which is the same loop we're discussing)

After your comments Lee, it just clicked, I think.

If the user is entering characters, a, b, t, j, m, l, p, etc scanf will read each one and store in ch. But when they hit enter, the scan will stop. Enter is hence the \n symbol on the input side as you explained to me.

yes, this sounds right.

Why does the book say "used to skip the rest of an input line"? I'm assuming "an input line" is the input before the user hits the enter key, right? So, if they did enter a, b, t, j, m, l, p then hit enter. The loop ends, but what was skipped in the previous input line?

The book is sounding a bit odd here. Traditionally an input line ends with a newline. Hence the newLINE. If you pasted some input that contained a newline I guess some of that input would be skipped. I really don't know what the book means.

-Lee

 

[Bill McEnaney]

The book is sounding a bit odd here. Traditionally an input line ends with a newline. Hence the newLINE. If you pasted some input that contained a newline I guess some of that input would be skipped. I really don't know what the book means

I don't know what it mean either. But why use scanf to read characters one by one when getc, fgetc, and gechar do that? You might write:

while (ch != '\n')
   ch = getchar();

Or,

while ((ch = getchar()) != '\n')
   continue;

You could even delete the word "continue," so the semicolon would be the only character in the loop's body.

 

[balamw]

But why use scanf to read characters one by one when getc, fgetc, and gechar do that?

Because the author has introduced scanf for input and chooses to introduce getchar later in the chapter.

http://knking.com/books/c2/content.html

7.3 Character Types 134
Operations on Characters 135
Signed and Unsigned Characters 136
Arithmetic Types 136
Escape Sequences 137
Character-Handling Functions 138
Reading and Writing Characters using scanf and printf 139
Reading and Writing Characters using getchar and putchar 140
Program: Determining the Length of a Message 141

B

Why does the book say "used to skip the rest of an input line"?

cybrscot, your interpretation is leading you astray. If you quote from the book, please do so verbatim without changing it.

What he says (thanks Amazon) is:

For example, the following loop will read and ignore all remaining characters in the input line:

do {
    scanf ("%c", &ch);
  } while (ch != '\n');

When scanf is called the next time, it will read the first character on the next input line.

Other input may precede this, but since the result of the scanf isn't stored or acted upon in the loop this just clears the input buffer to the newline effectively ignoring it.

Your implication was that it ignores everything after that newline, when his implication was up to.

B

 

[Bill McEnaney]

Because the author has introduced scanf for input and chooses to introduce getchar later in the chapter.

Maybe it makes more sense to introduce simple functions before you introduce complex ones. The functions I mentioned take an argument each. To use scanf, students need to learn about format strings and address-of operator, i.e., the ampersand.

 

[balamw]

Maybe it makes more sense to introduce simple functions before you introduce complex ones.

Which is exactly what makes many of us here wonder why this book is so highly rated for beginners.

The author presents things in what seems to be a strange order (IMHO) and seems to dwell on potentially confusing side topics rather than just moving on and getting back to fine details at a later point.

Maybe it works well in a classroom setting, with someone guiding you through the material, but it doesn't seem to be clicking all that well with cybrscot working on his own.

B

 

[Bill McEnaney]

Which is exactly what makes many of us here wonder why this book is so highly rated for beginners.

The author presents things in what seems to be a strange order (IMHO) and seems to dwell on potentially confusing side topics rather than just moving on and getting back to fine details at a later point.

Maybe it works well in a classroom setting, with someone guiding you through the material, but it doesn't seem to be clicking all that well with cybrscot working on his own.
B

Thanks B. I hadn't thought about your points when I suggested King's book.

With my philosophical background, I prefer theory to practice. After I told my friend Dr. Michael Covington, who taught Prolog, told me that his students wanted to learn practical information right away. How much do they learn about program design, another practical topic, when textbooks begin by teaching C syntax. In his book Object-Oriented Software Construction, readers learn object-oriented design by contract when they're learning Eiffel. He doesn't say, "Here's a bunch of statements and how to use them. Now go to it." Readers learn how to reason the way object-oriented programmers.

I believe C urges C programmers to think about minute syntactic details when they should think first about program design and abstraction. I don't do high-level thinking when I'm telling myself, "I need a comma here, and ampersand there, and an 'lf' after the percent sign." How long do I need to wonder whether some line of code complies with the C99 Standard or whether I need to cast a character into an integer?

Bill

 

[Sydde]

Perhaps the author's idea is to progress from scanf to fscanf: the concept of stepping through a file line by line?

 

[balamw]

How much do they learn about program design, another practical topic, when textbooks begin by teaching C syntax.

This is certainly a real issue. Programming books from times before emphasized flowcharting, top-down and bottom-up design.

This is one of the reasons I don't think starting with C to learn Objective-C is necessarily the right approach for everyone. If you spend too much time working out the details of C it can become harder to develop more OOP-y thinking later.

Books like Kochan's Objective-C book and the Big Nerd Ranch iPhone book do a bit of both by working on bits of a larger project as the book progresses.

In this way I quite enjoyed MR user Sander's book: https://forums.macrumors.com/posts/12149809/ it's short enough to read through pretty quickly and builds up concepts quickly to build actually useful programs, and it takes some time to discuss variations that exist in other languages FORTRAN, etc.. or versions of C.

B

 

[notjustjay]

What I would suggest to cybrscot, and anyone else looking to learn programming from a book, is not to limit yourself to working through just one book. Get several books (or internet tutorials). Work through one, and when you get confused, change gears and try another.

Since I grew up with procedural programming (quite literally -- I learned Applesoft BASIC when I was about 9, getting into C when I was 14), it took several different books before I finally truly understood the concepts of Object Oriented Programming.

My favourite C programming book, though now a bit antiquated, is "Practical C Programming" published by O'Reilly.

 

[PatrickCocoa]

That's the least of it

This is one of the reasons I don't think starting with C to learn Objective-C is necessarily the right approach for everyone. If you spend too much time working out the details of C it can become harder to develop more OOP-y thinking later.

It's not just having to wash your brain of the procedural stuff and replace it with OOP, it's also the focus on 1960's era input and output. Typing values from a terminal? Formatting output? We now have Cocoa to take care of this for us - NSString and NSTextField.

 

[Bill McEnaney]

This is certainly a real issue. Programming books from times before emphasized flowcharting, top-down and bottom-up design.

I learned Fortran IV from a book that taught me how to draw structured flowcharts, called "Nassi Schneiderman flowcharts," I think. Since there weren't any arrows it them, they didn't tempt me to write programs full of gotos. I needed gotos because I was writing Fortran IV. But those flowcharts forced me to think top-down. Nobody even mentioned pseudocode before I began to learn Pascal.

This is one of the reasons I don't think starting with C to learn Objective-C is necessarily the right approach for everyone. If you spend too much time working out the details of C it can become harder to develop more OOP-y thinking later.

I blame programming languages for my sometimes-annoying detail-orirntation. I can tell you where to put a semicolon, why the computer is complaining about one character in a program, what the machine will say when a Cobol verb's first character appears before column 12 . . . I pay syntactic detail too much attention and too little attention to general ideas.

In a functional programming language, Haskell. say, it's often easy to translate a program specification into a program. Functional programming and logic programming seem to come almost naturally to me because Plato's Early Socratic Dialogues taught me to search for the essences of things. A real definition, the kind of definition Socrates always asked for, tells you what a thing consists of, not a dictionary's meaning of a word.

If I describe relationships by writing in a declarative programming language, the program probably will be shorter than and more readable the equivalent procedural program. In any programming language, I need to tell the machine what to do. But declarative languages let me tell it a lot about relationships and not so much about algorithms. Before I can teach the computer how to do something, I need to know what I need it to do. Sometimes, when I know the "what," I can ignore most of the "how." C makes me pay too much attention to the "how."

I think I'll order the book B suggests.

 

[jiminaus]

After I told my friend Dr. Michael Covington, who taught Prolog, told me that his students wanted to learn practical information right away. How much do they learn about program design, another practical topic, when textbooks begin by teaching C syntax. In his book Object-Oriented Software Construction, readers learn object-oriented design by contract when they're learning Eiffel. He doesn't say, "Here's a bunch of statements and how to use them. Now go to it." Readers learn how to reason the way object-oriented programmers.

Just of the record, Bertrand Meyer wrote Object-oriented software construction, not Michael Covington.

 

[Bill McEnaney]

Just of the record, Bertrand Meyer wrote Object-oriented software construction, not Michael Covington.

Thanks for the reminder. I must have been sleep-typing.