C++ Workshop II The next chapter of the C++ book gives a whirlwind tour of the basics of the C++ syntax that are necessary for object oriented programming. This section is almost like jumping into the pool and hope you get acclimated to the water. C++ is not a good language for a beginner, and this section makes it clear why. To really get a handle on this section without prior programing experience is a very tall order. In parsing this chapter, keep a few things in mind. Much of the code snippets given as an example in this section would be written outside of your main program, as library files and header files. While we discussed the preprocessor directive previously in both the C and C++ workshops, we hadn't looked at them in detail. For those not familiar with these construction, which are core to C programing, a few words are in order about them. There are two different external file types that your compiler uses to build your program, aside from the file that your main program code is stored in. They are called header files or libraries. Most normally, there is a header file for each library. They also share part of their name according to a naming convention. Standardized libraries, such as iostream have header files. The libraries can be static or shared. Either type is unlinked C bitcode, or objects files in C language parlance. A group of object files archived together, usually with the 'ar' program, form these libraries. Thee files normally exist in /usr/lib or /lib and might have a suffix of '.so'. It is sometimes necessary to compile a program with the -I option to tell the compiler to include a library, even though the preprocessor include line is designating the header file. Usually if the header file is math.h then the library is libmath. Declaration of variable types, function names, and preprocessor constants which apply to the library files are header files. These are what is referred to within your program, such as or . In C these are .h files such as /usr/include/strings.h. In C++ they might not, as in /usr/include/g++/iostream. Take a peek and look at some of your header files. Becoming familiar with their syntax will greatly improve your hacking skills. The reason to discuss this, and we should really talk even more about this, is that the examples in the C++ text implicitly and explicitly imply that the code being written is for library objects, and written in external files. When we discuss making classes, the most logical place to make a new class is in an external file, compiled to an C object for use later by someone else's program. Calling class objects is not a problem. A simple explanation of the “new” keyword and type defining the class structures puts you on your way. But once we discuss Constructors, Destructors, data hiding, public interface design, private data and implementation design, operator overloading, and function overloading and polymorphism, then we are talking writing modules for others to use, or even for us to use concurrently to the main code we are writing. Section 2.1 is a big section which walks through much of the C++ basic design, and I will go over it piece by piece over the next couple of days. -- http://www.mrbrklyn.com - Interesting Stuff http://www.nylxs.com - Leadership Development in Free Software So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://fairuse.nylxs.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 "Yeah - I write Free Software...so SUE ME" "The tremendous problem we face is that we are becoming sharecroppers to our own cultural heritage -- we need the ability to participate in our own society." "> I'm an engineer. I choose the best tool for the job, politics be damned.< You must be a stupid engineer then, because politcs and technology have been attached at the hip since the 1st dynasty in Ancient Egypt. I guess you missed that one." © Copyright for the Digital Millennium