Chapter05 -...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
Viewing Hints  ] [  Exercise Solutions  ] [  Volume 2  ] [  Free Newsletter  ]  Seminars  ] [  Seminars on CD ROM  ] [  Consulting  ]  Thinking in C++, 2nd ed. Volume 1 ©2000 by Bruce Eckel Previous Chapter  ] [  Table of Contents  ] [  Index  ] [  Next Chapter  ]  5: Hiding the Implementation A typical C library contains a  struct  and some  associated functions to act on that  struct . So far,  you've seen how C++ takes functions that are  conceptually  associated and makes  them  literally  associated by  putting the function declarations inside the scope of the  struct , changing the way functions are  called for the  struct , eliminating the passing of the structure address as the first argument, and  adding a new type name to the program (so you don’t have to create a  typedef  for the  struct  tag). These are all convenient – they help you organize your code and make it easier to write and read.  However, there are other important issues when making libraries easier in C++, especially the  issues of safety and control. This chapter looks at the subject of boundaries in structures. Setting limits In any relationship it’s important to have boundaries that are respected by all parties involved.  When you create a library, you establish a relationship with the  client programmer  who uses that  library to build an application or another library. In a C  struct , as with most things in C, there are no rules. Client programmers can do anything they  want with that  struct , and there’s no way to force any particular behaviors. For example, even  though you saw in the last chapter the importance of the functions named  initialize( )  and  cleanup( ) , the client programmer has the option not to call those functions. (We’ll look at a better  approach in the next chapter.) And even though you would really prefer that the client programmer  not directly manipulate some of the members of your  struct , in C there’s no way to prevent it.  Everything’s naked to the world. There are two reasons for controlling access to members. The first is to keep the client programmer’s  hands off tools they shouldn’t touch, tools that are necessary for the internal machinations of the 
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
data type, but not part of the interface the client programmer needs to solve their particular  problems. This is actually a service to client programmers because they can easily see what’s  important to them and what they can ignore. The second reason for access control is to allow the library designer to change the internal workings 
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

This note was uploaded on 08/10/2011 for the course IT 331 taught by Professor Nevermind during the Spring '11 term at King Abdulaziz University.

Page1 / 17

Chapter05 -...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online