Topical Information

The purpose of this quiz is to give you a chance to focus your knowledge of libraries in C++.

Quiz Information

Questions

1. Show the preprocessor directives needed in ANY library interface (.h) file.

   
           #ifndef UNIQUE_SYMBOL_FOR_LIBRARY
           #define UNIQUE_SYMBOL_FOR_LIBRARY
   
           // consts, typedefs, inline funcs, func prototypes
   
           #endif
   
   

   What is the symbol and why must it be unique?

   
           UNIQUE_SYMBOL_FOR_LIBRARY is defined when the library is first
           seen by the pre-processor and later used to skip re-inclusion
           of the interface file if it is accidentally/on purpose pulled
           in again.
   
           If it weren't unique, one library's inclusion would preclude
           the inclusion of a second library using the same symbol —
           as it would already be defined.
   
   

2. An interface file for a library normally contains _____, _____, and _____.

   1. prototypes, definitions, main NO
   2. constants, typedefinitions, prototypes YES
   3. cake, coffee, ice cream NO
   4. classes, structures, enumerations NO
   5. functions, arrays, ADTs NO

   Special circumstances (_____ functions) also warrant the inclusion of _____ and any support _____ they may need access to.

   1. void, references, local variables NO
   2. default, initialization, overloading NO
   3. class, private data, utility functions NO
   4. inline, function definitions, library headers YES
   5. constructor, classes, data NO
3.  

   TRUE ✗		FALSE ✓		When I extract functions to a library, I must leave their prototypes in the 'main' application.
   TRUE ✗		FALSE ✓		A library is typically designed to be used with just a single application.
   TRUE ✗		FALSE ✓		I can only place string processing functions in a library.
   TRUE ✓		FALSE ✗		C libraries work exactly the same as C++ libraries.

4. When compiling a program which uses libraries, you must remember to place the names of the C++ source files after the CPP command — separated by spacing, of course. (In a Windows-style environment you would normally create a project and insert all of the .C/.cpp files in it.)

   We don't have to ever mention the interface (.h) files in the compilation process because they are #include'd in any source file which needs them. (Unless, of course, you are using a 'Visual' — *ahem Microsux* — environment. There you'll have to insert these files into the project along with the others mentioned above.)

5. What possible problem are we trying to eliminate with the multiple preprocessor directives in a library interface file? (Hint: There are actually two related problems — one causes the other.)

   
           Multiple inclusion is one.  It can cause warnings or even
           errors from duplicated definitions/declarations of the
           library parts listed in the interface file.
   
           The very worst case of multiple inclusion is arguably circular
           inclusion — where two or more interface files include
           one another in a cycle.  This can cause an infinite loop in
           your compiler or even cause it to crash.
   
   

6. Why do we #include the interface of a library in its implementation file? (Hint: It is not just to see the prototypes of the functions we are defining. What else is in there?)

   
           The functions we are defining might need to be declared in a
           particular order were it not for our having included their
           prototypes, but this is not the only reason to include our
           interface file.
   
           In addition, this inclusion gives our functions access to the
           constants and type definitions we placed in our interface
           file.
   
           Heck, we might even want to call our inline brethren to help
           us out!  We couldn't do that if we didn't include our
           interface file, now could we?
   
   

7.  

   TRUE ✓		FALSE ✗		We surround a local header file in double quotes ("") for #include'ing.
   TRUE ✓		FALSE ✗		We can also surround a standard header file in double quotes ("") for #include'ing.
   TRUE ✓		FALSE ✗		However, we usually surround a standard header file in angle brackets (<>) for #include'ing.

8. If you need to #include a standard library in your library's interface file, you should not place using namespace std there, too. Why not?

   
           Placing a using directive in an interface file would cause
           anyone including that file to be using the indicated
           namespace — whether they wanted to or not!  Not
           everyone wants to use the standard namespace — believe
           it or not.
   
   

   What should you do instead?

   
           Instead of a using directive at file scope in the interface
           file, we can place using directives inside inline functions
           (if we like).  Or, we could just place the scope resolution
           operation in front of all standard namespace symbols like
           this:  std::sqrt.  (Be careful, of course, not to place the
           scope resolution in front of those all-caps constants from
           our ancestral C libraries as these are not proper namespace
           symbols.)