From 1d2c9bfdb1bef14782e3499ababf853f04f68c6d Mon Sep 17 00:00:00 2001 From: "Frank B. Brokken" Date: Fri, 24 May 2024 18:05:50 +0200 Subject: [PATCH] wip on the I/O stream chapter, various typo corrections --- .../yo/advancedtemplates/concepts/simple.yo | 2 +- annotations/yo/advancedtemplates/noexcept.yo | 2 +- annotations/yo/exceptions/noexcept.yo | 2 +- annotations/yo/iostreams/intro.yo | 66 ++++++++++--------- annotations/yo/iostreams/readwrite.yo | 12 +++- 5 files changed, 47 insertions(+), 37 deletions(-) diff --git a/annotations/yo/advancedtemplates/concepts/simple.yo b/annotations/yo/advancedtemplates/concepts/simple.yo index 29fe6553..c1fe6c1e 100644 --- a/annotations/yo/advancedtemplates/concepts/simple.yo +++ b/annotations/yo/advancedtemplates/concepts/simple.yo @@ -17,7 +17,7 @@ the index operator the following simple requirement can be used: Here the em(stand-in argument) 0 is used to specify the index operator's argument. The argument value used in the simple requirement really is a stand-in. The following code fragment compiles, as tt(string) supports the -index operator. Athough argument 0 is used in the simple requirement +index operator. Although argument 0 is used in the simple requirement specification the argument 5 is in fact being used: verb( string str; idx(str, 5);) diff --git a/annotations/yo/advancedtemplates/noexcept.yo b/annotations/yo/advancedtemplates/noexcept.yo index b019f85a..280c0d33 100644 --- a/annotations/yo/advancedtemplates/noexcept.yo +++ b/annotations/yo/advancedtemplates/noexcept.yo @@ -69,7 +69,7 @@ with the following message: Keep in mind that the current purpose of tt(noexcept) is to allow templates to optimize their code by using move operations where the code must also be able -to offer the string exception guarantee. Since tt(noexcept) also offers the +to offer the strong exception guarantee. Since tt(noexcept) also offers the conditional tt(noexcept(condition)) syntax (with tt(noexcept(true)) and tt(noexcept) having identical semantics), tt(noexcept) can be made conditional to the `noexcepting' nature of template types. Note that this is diff --git a/annotations/yo/exceptions/noexcept.yo b/annotations/yo/exceptions/noexcept.yo index 6fcb9009..b0f9efea 100644 --- a/annotations/yo/exceptions/noexcept.yo +++ b/annotations/yo/exceptions/noexcept.yo @@ -10,7 +10,7 @@ specifying the ti(noexcept) keyword (see section ref(SYSTEMERROR) for examples of function declarations specifying tt(noexcept)). When using tt(noexept) there's a slight run-time overhead penalty because the -function needs an over-all tt(try-catch) block catching any eception that +function needs an over-all tt(try-catch) block catching any exception that might be thrown by its (called) code. When an exception is caught (violating the tt(noexcept) specification) then the tt(catch) clause calls tt(std::terminate), ending the program. diff --git a/annotations/yo/iostreams/intro.yo b/annotations/yo/iostreams/intro.yo index 88cb9665..16a4fefc 100644 --- a/annotations/yo/iostreams/intro.yo +++ b/annotations/yo/iostreams/intro.yo @@ -74,38 +74,34 @@ opened, closed, positioned, read, written, etc.. In bf(C++) the basic tt(FILE) structure, as used in bf(C), is still available. But bf(C++) adds to this I/O based on classes, resulting in type safety, extensibility, and a clean design. -In the i(ANSI/ISO) standard the intent was to create architecture independent -I/O. Previous implementations of the iostreams library did not always comply -with the standard, resulting in many extensions to the standard. The I/O -sections of previously developed software may have to be partially -rewritten. This is tough for those who are now forced to modify old software, -but every feature and extension that was once available can be rebuilt easily -using ANSI/ISO standard conforming I/O. Not all of these reimplementations can -be covered in this chapter, as many reimplementations rely on inheritance and -polymorphism, which topics are formally covered by chapters ref(INHERITANCE) -and ref(POLYMORPHISM). Selected reimplementations are provided in chapter -ref(CONCRETE), and in this chapter references to particular sections in other -chapters are given where appropriate. +The i(ANSI/ISO) standard specifies architecture independent I/O. Not all of +the standard's specifications are covered in this chapter, as they often rely +on inheritance and polymorphism, which topics are formally covered by chapters +ref(INHERITANCE) and ref(POLYMORPHISM). Some examples are +offered in chapter ref(CONCRETE), and in this chapter references to +specific sections in other chapters are given where appropriate. figure(iostreams/ioclasses)(Central I/O Classes)(IOCLASSESFIG) This chapter is organized as follows (see also fig(IOCLASSESFIG)): itemization( - it() The tt(class) ti(ios_base) is the foundation upon which the -iostreams I/O library was built. It defines the core of all I/O operations and + it() The class ti(ios_base) is the foundation upon which the +iostream I/O library was built. It defines the core of all I/O operations and offers, among other things, facilities for inspecting the - i(state of I/O streams) and for i(output formatting). - it() The class ti(ios) was directly derived from tt(ios_base). Every -class of the I/O library doing input or output is itself em(derived) from this -tt(ios) class, and so em(inherits) its (and, by implication, tt(ios_base)'s) -capabilities. The reader is urged to keep this in mind while reading this -chapter. The concept of inheritance is not discussed here, but rather -in chapter ref(INHERITANCE). + i(state of I/O streams) and facilities for i(output formatting). -The class tt(ios) is important in that it implements the communication with a -em(buffer) that is used by streams. This buffer is a ti(streambuf) object -which is responsible for the actual I/O to/from the underlying -em(device). Consequently tt(iostream) objects do not perform I/O -operations themselves, but leave these to the (stream)buffer objects with + it() The class ti(ios) is directly em(derived) from +tt(ios_base). Every class of the I/O library doing input or output is itself +derived from this tt(ios) class, and therefore em(inherits) its (and, by +implication: tt(ios_base)'s) capabilities. The reader is urged to keep this in +mind while reading this chapter. The concept of inheritance is not discussed +here, but rather in chapter ref(INHERITANCE).nl() + The class tt(ios) is important because it implements communication with a +em(buffer) which is used by streams. This buffer is a ti(streambuf) object +which is responsible for the actual I/O to/from the actually used em(device), +which might be a file, a keyboard, a screen, an Internet connection, etc., +etc.. Consequently tt(iostream) objects do not perform I/O operations +themselves, but leave these operations to the (stream)buffer objects with which they are associated. + it() Next, basic bf(C++) output facilities are discussed. The basic class used for output operations is ti(ostream), defining the i(insertion operator) as well as other facilities writing information to @@ -116,16 +112,24 @@ facilities defined in the tt(ios) class, but it is also possible to em(insert) emi(formatting commands) directly into streams using hi(manipulator)em(manipulators). This aspect of bf(C++) output is discussed as well. + it() Basic bf(C++) input facilities are implemented by the ti(istream) class. This class defines the i(extraction operator) and related input facilities. Comparably to inserting information into memory buffers (using tt(ostringstream)) a class ti(istringstream) is available to extract information from memory buffers. - it() Finally, several advanced I/O-related topics are discussed. E.g., -i(reading and writing) from the same stream and - i(mixing bf(C) and bf(C++) I/O) using ti(filebuf) objects. Other I/O -related topics are covered elsewhere in the annotations() (cf. section -ref(OSYNC) and chapter ref(CONCRETE)). + + it() The class ti(iostream) combines the facilities offered by +tt(istream) and tt(ostream). Thus, tt(iostream) objects can be used to read +em(and) write from the same object. + + it() The class tt(fstream) is a frequently encountered example of an +tt(iostream) class: tt(fstream) objects are used to read and write from the +same file, which is often used in programs processing data bases. In this +chapter topics like i(reading and writing) from the same stream and + i(mixing bf(C) and bf(C++) I/O) using ti(filebuf) objects are also +covered. Other I/O related topics are covered elsewhere in the annotations() +(cf. section ref(OSYNC) and chapter ref(CONCRETE)). ) Stream objects have a limited but important role: they are the interface diff --git a/annotations/yo/iostreams/readwrite.yo b/annotations/yo/iostreams/readwrite.yo index f47993b6..c06e51cc 100644 --- a/annotations/yo/iostreams/readwrite.yo +++ b/annotations/yo/iostreams/readwrite.yo @@ -1,7 +1,13 @@ Streams can be read em(and) written - hi(stream: read and write) using hi(fstream)tt(std::fstream) objects. As -with tt(ifstream) and tt(ofstream) objects, its constructor expects the name -of the file to be opened: + hi(stream: read and write) using hi(iostream)tt(std::iostream) +objects. Commonly encountered are hi(fstream)tt(std::fstream) objects and +sometimes hi(stringstream)tt(std::stringstream) objects. Other types of +readable and writable streams can be defined, by deriving such streams from +the tt(std::iostream) class (cf. chapter ref(POLYMORPHISM)). + +In this section we concentrate on the tt(std::fstream) class. As with +tt(ifstream) and tt(ofstream) objects, the tt(fstream) constructor expects the +name of the file to be opened: verb( fstream inout("iofile", ios::in | ios::out);) Note the use of the constants hi(in)tt(ios::in) and hi(out)tt(ios::out),