Monday, November 29, 2010
Abstract Classes and Pure Virtual Functions
Think of the shape class in the multshap program in Chapter 9. We’ll never make an object of
the shape class; we’ll only make specific shapes such as circles and triangles. When we will
never want to instantiate objects of a base class, we call it an abstract class. Such a class exists
only to act as a parent of derived classes that will be used to instantiate objects. It may also
provide an interface for the class hierarchy.
How can we make it clear to someone using our family of classes that we don’t want anyone to
instantiate objects of the base class? We could just say this in the documentation, and count on
the users of the class to remember it, but of course it’s much better to write our classes so that
such instantiation is impossible. How can we can do that? By placing at least one pure virtual
function in the base class. A pure virtual function is one with the expression =0 added to the
declaration
the shape class; we’ll only make specific shapes such as circles and triangles. When we will
never want to instantiate objects of a base class, we call it an abstract class. Such a class exists
only to act as a parent of derived classes that will be used to instantiate objects. It may also
provide an interface for the class hierarchy.
How can we make it clear to someone using our family of classes that we don’t want anyone to
instantiate objects of the base class? We could just say this in the documentation, and count on
the users of the class to remember it, but of course it’s much better to write our classes so that
such instantiation is impossible. How can we can do that? By placing at least one pure virtual
function in the base class. A pure virtual function is one with the expression =0 added to the
declaration
Late Binding
The astute reader may wonder how the compiler knows what function to compile. In NOTVIRT
the compiler has no problem with the expression
ptr->show();
It always compiles a call to the show() function in the base class. But in VIRT the compiler
doesn’t know what class the contents of ptr may contain. It could be the address of an object
of the Derv1 class or of the Derv2 class. Which version of draw() does the compiler call? In
fact the compiler doesn’t know what to do, so it arranges for the decision to be deferred until
the program is running. At runtime, when it is known what class is pointed to by ptr, the
appropriate version of draw will be called. This is called late binding or dynamic binding.
(Choosing functions in the normal way, during compilation, is called early binding or
static binding.) Late binding requires some overhead but provides increased power and
flexibility.
We’ll put these ideas to use in a moment, but first let’s consider a refinement to the idea of
virtual functions.
the compiler has no problem with the expression
ptr->show();
It always compiles a call to the show() function in the base class. But in VIRT the compiler
doesn’t know what class the contents of ptr may contain. It could be the address of an object
of the Derv1 class or of the Derv2 class. Which version of draw() does the compiler call? In
fact the compiler doesn’t know what to do, so it arranges for the decision to be deferred until
the program is running. At runtime, when it is known what class is pointed to by ptr, the
appropriate version of draw will be called. This is called late binding or dynamic binding.
(Choosing functions in the normal way, during compilation, is called early binding or
static binding.) Late binding requires some overhead but provides increased power and
flexibility.
We’ll put these ideas to use in a moment, but first let’s consider a refinement to the idea of
virtual functions.
Characteristics of Object-Oriented Languages
Let’s briefly examine a few of the major elements of object-oriented languages in
general, and C++ in particular.
Objects
When you approach a programming problem in an object-oriented language, you no
longer ask how the problem will be divided into functions, but how it will be divided
into objects. Thinking in terms of objects, rather than functions, has a surprisingly
helpful effect on how easily programs can be designed. This results from the close
match between objects in the programming sense and objects in the real world. This
process is described in detail in Chapter 16, “Object-Oriented Software
Development.”
What kinds of things become objects in object-oriented programs? The answer to this is limited
only by your imagination, but here are some typical categories to start you thinking:
• Physical objects
Automobiles in a traffic-flow simulation
Electrical components in a circuit-design program
Countries in an economics model
Aircraft in an air traffic control system
• Elements of the computer-user environment
Windows
Menus
Graphics objects (lines, rectangles, circles)
The mouse, keyboard, disk drives, printer
• Data-storage constructs
Customized arrays
Stacks
Linked lists
Binary trees
• Human entities
Employees
Students
Customers
Salespeople
• Collections of data
An inventory
A personnel file
A dictionary
A table of the latitudes and longitudes of world cities
• User-defined data types
Time
Angles
Complex numbers
Points on the plane
The Big Picture
• Components in computer games
Cars in an auto race
Positions in a board game (chess, checkers)
Animals in an ecological simulation
Opponents and friends in adventure games
The match between programming objects and real-world objects is the happy result of combining
data and functions: The resulting objects offer a revolution in program design. No such
close match between programming constructs and the items being modeled exists in a
procedural language.
Classes
In OOP we say that objects are members of classes. What does this mean? Let’s look
at an analogy. Almost all computer languages have built-in data types. For instance, a
data type int, meaning integer, is predefined in C++ (as we’ll see in Chapter 3,
“Loops and Decisions”). You can declare as many variables of type int as you need in
your program:
int day;
int count;
int divisor;
int answer;
In a similar way, you can define many objects of the same class, as shown in Figure 1.5. A
class serves as a plan, or blueprint. It specifies what data and what functions will be included
in objects of that class. Defining the class doesn’t create any objects, just as the mere existence
of data type int doesn’t create any variables.
A class is thus a description of a number of similar objects. This fits our non-technical understanding
of the word class. Prince, Sting, and Madonna are members of the rock musician
class. There is no one person called “rock musician,” but specific people with specific names
are members of this class if they possess certain characteristics. An object is often called an
“instance” of a class.
Inheritance
The idea of classes leads to the idea of inheritance. In our daily lives, we use the concept
of classes divided into subclasses. We know that the animal class is divided into
mammals, amphibians, insects, birds, and so on. The vehicle class is divided into cars,
trucks, buses, motorcycles, and so on.
Reusability
Once a class has been written, created, and debugged, it can be distributed to other
programmers for use in their own programs. This is called reusability. It is similar to
the way a library of functions in a procedural language can be incorporated into different
programs.
However, in OOP, the concept of inheritance provides an important extension to the idea of
reusability. A programmer can take an existing class and, without modifying it, add additional
features and capabilities to it. This is done by deriving a new class from the existing one. The
new class will inherit the capabilities of the old one, but is free to add new features of its own.
For example, you might have written (or purchased from someone else) a class that creates a
menu system, such as that used in Windows or other Graphic User Interfaces (GUIs). This
class works fine, and you don’t want to change it, but you want to add the capability to make
some menu entries flash on and off. To do this, you simply create a new class that inherits all
the capabilities of the existing one but adds flashing menu entries.
The ease with which existing software can be reused is an important benefit of OOP. Many
companies find that being able to reuse classes on a second project provides an increased
return on their original programming investment. We’ll have more to say about this in later
chapters.
Creating New Data Types
One of the benefits of objects is that they give the programmer a convenient way to
construct new data types. Suppose you work with two-dimensional positions (such as
x and y coordinates, or latitude and longitude) in your program. You would like to
express operations on these positional values with normal arithmetic operations,
such as
position1 = position2 + origin
where the variables position1, position2, and origin each represent a pair of independent
numerical quantities. By creating a class that incorporates these two values,
and declaring position1, position2, and origin to be objects of this class, we can,
in effect, create a new data type. Many features of C++ are intended to facilitate the
creation of new data types in this manner.
Polymorphism and Overloading
Note that the = (equal) and + (plus) operators, used in the position arithmetic shown
above, don’t act the same way they do in operations on built-in types such as int. The
objects position1 and so on are not predefined in C++, but are programmer-defined
objects of class Position. How do the = and + operators know how to operate on
objects? The answer is that we can define new behaviors for these operators. These
operations will be member functions of the Position class.
Using operators or functions in different ways, depending on what they are operating on, is
called polymorphism (one thing with several distinct forms). When an existing operator, such
as + or =, is given the capability to operate on a new data type, it is said to be overloaded.
Overloading is a kind of polymorphism; it is also an important feature of OOP
Problems with Structured Programming
As programs grow ever larger and more complex, even the structured programming
approach begins to show signs of strain. You may have heard about, or been involved
in, horror stories of program development. The project is too complex, the schedule
slips, more programmers are added, complexity increases, costs skyrocket, the schedule
slips further, and disaster ensues. (See The Mythical Man-Month by Frederick P.
Brooks, Jr. [Addison Wesley, 1982] for a vivid description of this process.)
Analyzing the reasons for these failures reveals that there are weaknesses in the procedural
paradigm itself. No matter how well the structured programming approach is implemented,
large programs become excessively complex.
What are the reasons for these problems with procedural languages? There are two related
problems. First, functions have unrestricted access to global data. Second, unrelated functions
and data, the basis of the procedural paradigm, provide a poor model of the real world.
Let’s examine these problems in the context of an inventory program. One important global
data item in such a program is the collection of items in the inventory. Various functions access
this data to input a new item, display an item, modify an item, and so on.
approach begins to show signs of strain. You may have heard about, or been involved
in, horror stories of program development. The project is too complex, the schedule
slips, more programmers are added, complexity increases, costs skyrocket, the schedule
slips further, and disaster ensues. (See The Mythical Man-Month by Frederick P.
Brooks, Jr. [Addison Wesley, 1982] for a vivid description of this process.)
Analyzing the reasons for these failures reveals that there are weaknesses in the procedural
paradigm itself. No matter how well the structured programming approach is implemented,
large programs become excessively complex.
What are the reasons for these problems with procedural languages? There are two related
problems. First, functions have unrestricted access to global data. Second, unrelated functions
and data, the basis of the procedural paradigm, provide a poor model of the real world.
Let’s examine these problems in the context of an inventory program. One important global
data item in such a program is the collection of items in the inventory. Various functions access
this data to input a new item, display an item, modify an item, and so on.
Calling the Function in c++
The function is called (or invoked, or executed) three times from main(). Each of the three
calls looks like this:
starline();
This is all we need to call the function: the function name, followed by parentheses. The syntax
of the call is very similar to that of the declaration, except that the return type is not used.
The call is terminated by a semicolon. Executing the call statement causes the function to execute;
that is, control is transferred to the function, the statements in the function definition
(which we’ll examine in a moment) are executed, and then control returns to the statement following
the function call.
calls looks like this:
starline();
This is all we need to call the function: the function name, followed by parentheses. The syntax
of the call is very similar to that of the declaration, except that the return type is not used.
The call is terminated by a semicolon. Executing the call statement causes the function to execute;
that is, control is transferred to the function, the statements in the function definition
(which we’ll examine in a moment) are executed, and then control returns to the statement following
the function call.
The operator Keyword
How do we teach a normal C++ operator to act on a user-defined operand? The keyword
operator is used to overload the ++ operator in this declarator:
void operator ++ ()
The return type (void in this case) comes first, followed by the keyword operator, followed
by the operator itself (++), and finally the argument list enclosed in parentheses (which are
empty here). This declarator syntax tells the compiler to call this member function whenever
the ++ operator is encountered, provided the operand (the variable operated on by the ++) is of
type Counter.
We saw in Chapter 5, “Functions,” that the only way the compiler can distinguish between
overloaded functions is by looking at the data types and the number of their arguments. In the
same way, the only way it can distinguish between overloaded operators is by looking at the
data type of their operands. If the operand is a basic type such as an int, as in
++intvar;
then the compiler will use its built-in routine to increment an int. But if the operand is a
Counter variable, the compiler will know to use our user-written operator++() instead.
operator is used to overload the ++ operator in this declarator:
void operator ++ ()
The return type (void in this case) comes first, followed by the keyword operator, followed
by the operator itself (++), and finally the argument list enclosed in parentheses (which are
empty here). This declarator syntax tells the compiler to call this member function whenever
the ++ operator is encountered, provided the operand (the variable operated on by the ++) is of
type Counter.
We saw in Chapter 5, “Functions,” that the only way the compiler can distinguish between
overloaded functions is by looking at the data types and the number of their arguments. In the
same way, the only way it can distinguish between overloaded operators is by looking at the
data type of their operands. If the operand is a basic type such as an int, as in
++intvar;
then the compiler will use its built-in routine to increment an int. But if the operand is a
Counter variable, the compiler will know to use our user-written operator++() instead.
Virtual function
Virtual Functions
Virtual means existing in appearance but not in reality. When virtual functions are used, a program
that appears to be calling a function of one class may in reality be calling a function of a
different class. Why are virtual functions needed? Suppose you have a number of objects of
different classes but you want to put them all in an array and perform a particular operation on
them using the same function call. For example, suppose a graphics program includes several
different shapes: a triangle, a ball, a square, and so on, as in the MULTSHAP program in Chapter
9, “Inheritance.” Each of these classes has a member function draw() that causes the object to
be drawn on the screen.
Now suppose you plan to make a picture by grouping a number of these elements together, and
you want to draw the picture in a convenient way. One approach is to create an array that holds
pointers to all the different objects in the picture. The array might be defined like this:
shape* ptrarr[100]; // array of 100 pointers to shapes
If you insert pointers to all the shapes into this array, you can then draw an entire picture using
a simple loop:
for(int j=0; j<N; j++)
ptrarr[j]->draw();
This is an amazing capability: Completely different functions are executed by the same function
call. If the pointer in ptrarr points to a ball, the function that draws a ball is called; if it
points to a triangle, the triangle-drawing function is called. This is called polymorphism, which
means different forms. The functions have the same appearance, the draw() expression, but different
actual functions are called, depending on the contents of ptrarr[j]. Polymorphism is
one of the key features of object-oriented programming, after classes and inheritance.
For the polymorphic approach to work, several conditions must be met. First, all the different
classes of shapes, such as balls and triangles, must be descended from a single base class
(called shape in MULTSHAP). Second, the draw() function must be declared to be virtual in
the base class.
Virtual means existing in appearance but not in reality. When virtual functions are used, a program
that appears to be calling a function of one class may in reality be calling a function of a
different class. Why are virtual functions needed? Suppose you have a number of objects of
different classes but you want to put them all in an array and perform a particular operation on
them using the same function call. For example, suppose a graphics program includes several
different shapes: a triangle, a ball, a square, and so on, as in the MULTSHAP program in Chapter
9, “Inheritance.” Each of these classes has a member function draw() that causes the object to
be drawn on the screen.
Now suppose you plan to make a picture by grouping a number of these elements together, and
you want to draw the picture in a convenient way. One approach is to create an array that holds
pointers to all the different objects in the picture. The array might be defined like this:
shape* ptrarr[100]; // array of 100 pointers to shapes
If you insert pointers to all the shapes into this array, you can then draw an entire picture using
a simple loop:
for(int j=0; j<N; j++)
ptrarr[j]->draw();
This is an amazing capability: Completely different functions are executed by the same function
call. If the pointer in ptrarr points to a ball, the function that draws a ball is called; if it
points to a triangle, the triangle-drawing function is called. This is called polymorphism, which
means different forms. The functions have the same appearance, the draw() expression, but different
actual functions are called, depending on the contents of ptrarr[j]. Polymorphism is
one of the key features of object-oriented programming, after classes and inheritance.
For the polymorphic approach to work, several conditions must be met. First, all the different
classes of shapes, such as balls and triangles, must be descended from a single base class
(called shape in MULTSHAP). Second, the draw() function must be declared to be virtual in
the base class.
Structure in c++
Structures
A structure is a collection of simple variables. The variables in a structure can be of different
types: Some can be int, some can be float, and so on. (This is unlike the array, which we’ll
meet later, in which all the variables must be the same type.) The data items in a structure are
called the members of the structure.
In books on C programming, structures are often considered an advanced feature and are introduced
toward the end of the book. However, for C++ programmers, structures are one of the
two important building blocks in the understanding of objects and classes. In fact, the syntax of
a structure is almost identical to that of a class. A structure (as typically used) is a collection of
data, while a class is a collection of both data and functions. So by learning about structures
we’ll be paving the way for an understanding of classes and objects. Structures in C++ (and C)
serve a similar purpose to records in some other languages such as Pascal.
A Simple Structure
Let’s start off with a structure that contains three variables: two integers and a floating-point
number. This structure represents an item in a widget company’s parts inventory. The structure
is a kind of blueprint specifying what information is necessary for a single part. The company
makes several kinds of widgets, so the widget model number is the first member of the structure.
The number of the part itself is the next member, and the final member is the part’s cost.
(Those of you who consider part numbers unexciting need to open your eyes to the romance of
commerce.)
The program PARTS defines the structure part, defines a structure variable of that type called
part1, assigns values to its members, and then displays these values.
// parts.cpp
// uses parts inventory to demonstrate structures
#include <iostream>
using namespace std;
////////////////////////////////////////////////////////////////
struct part //declare a structure
{
int modelnumber; //ID number of widget
int partnumber; //ID number of widget part
float cost; //cost of part
};
////////////////////////////////////////////////////////////////
int main()
{
part part1; //define a structure variable
part1.modelnumber = 6244; //give values to structure members
part1.partnumber = 373;
part1.cost = 217.55F;
//display structure members
cout << “Model “ << part1.modelnumber;
cout << “, part “ << part1.partnumber;
cout << “, costs $” << part1.cost << endl;
return 0;
}
The program’s output looks like this:
Model 6244, part 373, costs $217.55
The PARTS program has three main aspects: defining the structure, defining a structure variable,
and accessing the members of the structure. Let’s look at each of these.
Defining the Structure
The structure definition tells how the structure is organized: It specifies what members the
structure will have. Here it is:
struct part
{
int modelnumber;
int partnumber;
float cost;
};
Syntax of the Structure Definition
The keyword struct introduces the structure definition. Next comes the structure name or tag,
which is part. The declarations of the structure members—modelnumber, partnumber, and
cost—are enclosed in braces. A semicolon follows the closing brace, terminating the entire
Structures
Use of the Structure Definition
The structure definitiondefinition serves only as a blueprint for the creation of variables of type
part. It does not itself create any structure variables; that is, it does not set aside any space in
memory or even name any variables. This is unlike the definition of a simple variable, which
does set aside memory. A structure definition is merely a specification for how structure variables
will look when they are defined. This is shown in Figure 4.2.
It’s not accidental that this description sounds like the distinction we noted between classes
and objects in Chapter 1, “The Big Picture.” As we’ll see, an object has the same relationship
to its class that a variable of a structure type has to the structure definition.
Defining a Structure Variable
The first statement in main()
part part1;
defines a variable, called part1, of type structure part. This definition reserves space in
memory for part1. How much space? Enough to hold all the members of part1—namely
modelnumber, partnumber, and cost. In this case there will be 4 bytes for each of the two ints
(assuming a 32-bit system), and 4 bytes for the float. Figure 4.3 shows how part1 looks in
memory. (The figure shows 2-byte integers.)
Initializing Structure Members
The next example shows how structure members can be initialized when the structure variable
is defined. It also demonstrates that you can have more than one variable of a given structure
type (we hope you suspected this all along).
Here’s the listing for PARTINIT:
// partinit.cpp
// shows initialization of structure variables
#include <iostream>
using namespace std;
////////////////////////////////////////////////////////////////
struct part //specify a structure
{
int modelnumber; //ID number of widget
int partnumber; //ID number of widget part
float cost; //cost of part
};
////////////////////////////////////////////////////////////////
int main()
{ //initialize variable
part part1 = { 6244, 373, 217.55F };
part part2; //define variable
//display first variable
cout << “Model “ << part1.modelnumber;
cout << “, part “ << part1.partnumber;
cout << “, costs $” << part1.cost << endl;
part2 = part1; //assign first variable to second
//display second variable
cout << “Model “ << part2.modelnumber;
cout << “, part “ << part2.partnumber;
cout << “, costs $” << part2.cost << endl;
return 0;
}
This program defines two variables of type part: part1 and part2. It initializes part1, prints
out the values of its members, assigns part1 to part2, and prints out its members.
Here’s the output:
Model 6244, part 373, costs $217.55
Model 6244, part 373, costs $217.55
Not surprisingly, the same output is repeated since one variable is made equal to the other.
The part1 structure variable’s members are initialized when the variable is defined:
part part1 = { 6244, 373, 217.55 };
A structure is a collection of simple variables. The variables in a structure can be of different
types: Some can be int, some can be float, and so on. (This is unlike the array, which we’ll
meet later, in which all the variables must be the same type.) The data items in a structure are
called the members of the structure.
In books on C programming, structures are often considered an advanced feature and are introduced
toward the end of the book. However, for C++ programmers, structures are one of the
two important building blocks in the understanding of objects and classes. In fact, the syntax of
a structure is almost identical to that of a class. A structure (as typically used) is a collection of
data, while a class is a collection of both data and functions. So by learning about structures
we’ll be paving the way for an understanding of classes and objects. Structures in C++ (and C)
serve a similar purpose to records in some other languages such as Pascal.
A Simple Structure
Let’s start off with a structure that contains three variables: two integers and a floating-point
number. This structure represents an item in a widget company’s parts inventory. The structure
is a kind of blueprint specifying what information is necessary for a single part. The company
makes several kinds of widgets, so the widget model number is the first member of the structure.
The number of the part itself is the next member, and the final member is the part’s cost.
(Those of you who consider part numbers unexciting need to open your eyes to the romance of
commerce.)
The program PARTS defines the structure part, defines a structure variable of that type called
part1, assigns values to its members, and then displays these values.
// parts.cpp
// uses parts inventory to demonstrate structures
#include <iostream>
using namespace std;
////////////////////////////////////////////////////////////////
struct part //declare a structure
{
int modelnumber; //ID number of widget
int partnumber; //ID number of widget part
float cost; //cost of part
};
////////////////////////////////////////////////////////////////
int main()
{
part part1; //define a structure variable
part1.modelnumber = 6244; //give values to structure members
part1.partnumber = 373;
part1.cost = 217.55F;
//display structure members
cout << “Model “ << part1.modelnumber;
cout << “, part “ << part1.partnumber;
cout << “, costs $” << part1.cost << endl;
return 0;
}
The program’s output looks like this:
Model 6244, part 373, costs $217.55
The PARTS program has three main aspects: defining the structure, defining a structure variable,
and accessing the members of the structure. Let’s look at each of these.
Defining the Structure
The structure definition tells how the structure is organized: It specifies what members the
structure will have. Here it is:
struct part
{
int modelnumber;
int partnumber;
float cost;
};
Syntax of the Structure Definition
The keyword struct introduces the structure definition. Next comes the structure name or tag,
which is part. The declarations of the structure members—modelnumber, partnumber, and
cost—are enclosed in braces. A semicolon follows the closing brace, terminating the entire
Structures
Use of the Structure Definition
The structure definitiondefinition serves only as a blueprint for the creation of variables of type
part. It does not itself create any structure variables; that is, it does not set aside any space in
memory or even name any variables. This is unlike the definition of a simple variable, which
does set aside memory. A structure definition is merely a specification for how structure variables
will look when they are defined. This is shown in Figure 4.2.
It’s not accidental that this description sounds like the distinction we noted between classes
and objects in Chapter 1, “The Big Picture.” As we’ll see, an object has the same relationship
to its class that a variable of a structure type has to the structure definition.
Defining a Structure Variable
The first statement in main()
part part1;
defines a variable, called part1, of type structure part. This definition reserves space in
memory for part1. How much space? Enough to hold all the members of part1—namely
modelnumber, partnumber, and cost. In this case there will be 4 bytes for each of the two ints
(assuming a 32-bit system), and 4 bytes for the float. Figure 4.3 shows how part1 looks in
memory. (The figure shows 2-byte integers.)
Initializing Structure Members
The next example shows how structure members can be initialized when the structure variable
is defined. It also demonstrates that you can have more than one variable of a given structure
type (we hope you suspected this all along).
Here’s the listing for PARTINIT:
// partinit.cpp
// shows initialization of structure variables
#include <iostream>
using namespace std;
////////////////////////////////////////////////////////////////
struct part //specify a structure
{
int modelnumber; //ID number of widget
int partnumber; //ID number of widget part
float cost; //cost of part
};
////////////////////////////////////////////////////////////////
int main()
{ //initialize variable
part part1 = { 6244, 373, 217.55F };
part part2; //define variable
//display first variable
cout << “Model “ << part1.modelnumber;
cout << “, part “ << part1.partnumber;
cout << “, costs $” << part1.cost << endl;
part2 = part1; //assign first variable to second
//display second variable
cout << “Model “ << part2.modelnumber;
cout << “, part “ << part2.partnumber;
cout << “, costs $” << part2.cost << endl;
return 0;
}
This program defines two variables of type part: part1 and part2. It initializes part1, prints
out the values of its members, assigns part1 to part2, and prints out its members.
Here’s the output:
Model 6244, part 373, costs $217.55
Model 6244, part 373, costs $217.55
Not surprisingly, the same output is repeated since one variable is made equal to the other.
The part1 structure variable’s members are initialized when the variable is defined:
part part1 = { 6244, 373, 217.55 };
Basic Program Construction of c++
Basic Program Construction
Let’s look at a very simple C++ program. This program is called FIRST, so its source file is
FIRST.CPP. It simply prints a sentence on the screen. Here it is:
#include <iostream>
using namespace std;
int main()
{
cout << “Every age has a language of its own\n”;
return 0;
}
Despite its small size, this program demonstrates a great deal about the construction of C++
programs
Functions
Functions are one of the fundamental building blocks of C++. The FIRST program consists
almost entirely of a single function called main(). The only parts of this program that are not
part of the function are the first two lines—the ones that start with #include
Always Start with main()
When you run a C++ program, the first statement executed will be at the beginning of a function
called main(). (At least that’s true of the console mode programs in this book.) The program
may consist of many functions, classes, and other program elements, but on startup,
control always goes to main(). If there is no function called main() in your program, an error
will be reported when you run the program
Directives
The two lines that begin the FIRST program are directives. The first is a preprocessor directive,
and the second is a using directive. They occupy a sort of gray area: They’re not part of the
basic C++ language, but they’re necessary anyway
Preprocessor Directives
The first line of the FIRST program
#include <iostream>
might look like a program statement, but it’s not. It isn’t part of a function body and doesn’t
end with a semicolon, as program statements must. Instead, it starts with a number sign (#).
It’s called a preprocessor directive. Recall that program statements are instructions to the computer
to do something, such as adding two numbers or printing a sentence. A preprocessor
directive, on the other hand, is an instruction to the compiler. A part of the compiler called the
preprocessor deals with these directives before it begins the real compilation process.
The preprocessor directive #include tells the compiler to insert another file into your source
file. In effect, the #include directive is replaced by the contents of the file indicated. Using an
#include directive to insert another file into your source file is similar to pasting a block of
text into a document with your word processor.
#include is only one of many preprocessor directives, all of which can be identified by the initial
# sign. The use of preprocessor directives is not as common in C++ as it is in C, but we’ll
look at a few additional examples as we go along. The type file usually included by #include
is called a header file.
Header Files
In the FIRST example, the preprocessor directive #include tells the compiler to add the source
file IOSTREAM to the FIRST.CPP source file before compiling. Why do this? IOSTREAM is an example
of a header file (sometimes called an include file). It’s concerned with basic input/output
operations, and contains declarations that are needed by the cout identifier and the << operator.
Without these declarations, the compiler won’t recognize cout and will think << is being used
incorrectly. There are many such include files. The newer Standard C++ header files don’t have
a file extension, but some older header files, left over from the days of the C language, have
the extension .H.
C++ Programming Basics
2
C++
PROGRAMMING
BASICS
Let’s look at a very simple C++ program. This program is called FIRST, so its source file is
FIRST.CPP. It simply prints a sentence on the screen. Here it is:
#include <iostream>
using namespace std;
int main()
{
cout << “Every age has a language of its own\n”;
return 0;
}
Despite its small size, this program demonstrates a great deal about the construction of C++
programs
Functions
Functions are one of the fundamental building blocks of C++. The FIRST program consists
almost entirely of a single function called main(). The only parts of this program that are not
part of the function are the first two lines—the ones that start with #include
Always Start with main()
When you run a C++ program, the first statement executed will be at the beginning of a function
called main(). (At least that’s true of the console mode programs in this book.) The program
may consist of many functions, classes, and other program elements, but on startup,
control always goes to main(). If there is no function called main() in your program, an error
will be reported when you run the program
Directives
The two lines that begin the FIRST program are directives. The first is a preprocessor directive,
and the second is a using directive. They occupy a sort of gray area: They’re not part of the
basic C++ language, but they’re necessary anyway
Preprocessor Directives
The first line of the FIRST program
#include <iostream>
might look like a program statement, but it’s not. It isn’t part of a function body and doesn’t
end with a semicolon, as program statements must. Instead, it starts with a number sign (#).
It’s called a preprocessor directive. Recall that program statements are instructions to the computer
to do something, such as adding two numbers or printing a sentence. A preprocessor
directive, on the other hand, is an instruction to the compiler. A part of the compiler called the
preprocessor deals with these directives before it begins the real compilation process.
The preprocessor directive #include tells the compiler to insert another file into your source
file. In effect, the #include directive is replaced by the contents of the file indicated. Using an
#include directive to insert another file into your source file is similar to pasting a block of
text into a document with your word processor.
#include is only one of many preprocessor directives, all of which can be identified by the initial
# sign. The use of preprocessor directives is not as common in C++ as it is in C, but we’ll
look at a few additional examples as we go along. The type file usually included by #include
is called a header file.
Header Files
In the FIRST example, the preprocessor directive #include tells the compiler to add the source
file IOSTREAM to the FIRST.CPP source file before compiling. Why do this? IOSTREAM is an example
of a header file (sometimes called an include file). It’s concerned with basic input/output
operations, and contains declarations that are needed by the cout identifier and the << operator.
Without these declarations, the compiler won’t recognize cout and will think << is being used
incorrectly. There are many such include files. The newer Standard C++ header files don’t have
a file extension, but some older header files, left over from the days of the C language, have
the extension .H.
C++ Programming Basics
2
C++
PROGRAMMING
BASICS
CUSAT B-tech degree third semester computer science branch syllabus
EB/EC/EE/EI/CE/CS/IT/ME/SE 301 ENGINEERING MATHEMATICS II
Module 1
Matrices and Vector spaces: Rank of matrix, Echelon and normal form, Solutions of
linear systems of algebraic equations, Eigen values and Eigen vectors, Cayley- Hamilton
theorem (no proof). Vector Spaces- Subspaces,-Linear Independence of vectors-Linear
span-Dimension and Basis. Linear transformations.
Module 2
Fourier series and Fourier integrals: Fourier series of Periodic functions-Euler formulae
for Fourier coefficients- functions having period 2Ï€ , arbitrary period- even and odd
functions-half range expansions, Fourier integral, Fourier cosine and sine
transformations, linearity property, transform of derivatives, convolution theorem (no
proof)
Module 3
Laplace transforms: Linearity property, transforms of elementary functions, Laplace
transforms of derivatives and integrals, differentiation and integration of transforms,
convolution theorm (no proof), use of Laplace transforms in the solution of initial value
problems, unit step function, impulse function - transform of step functions, transforms of
periodic functions.
Module 4
Vector calculus : Scalar and Vector point functions-Gradient and directional derivative of
a scalar point functions.- Divergence and Curl of a vector point functions- their physical
meanings.
Evaluation of line integral, surface integral and volume integrals, Gauss’s divergence
theorem,. Stoke’s theorem (No Proof of these theorem), conservative force fields,
scalar potential.
Text books:
1. R.K. Jain, S.R.K Iyengar: Advanced Engineering Mathematics, Narosa
publishers.1991
2. C.R. Wilie & L.C. Barrett: Advanced Engineering Mathematics, MGH Co.
References
1. Larry C Andrews, Ronald C Philips: Mathematical Techniques for Engineers &
Scientists, PHI
2. M.C. Potter, J.L. Goldberg: Advanced Engineering Mathematics, Oxford university
press
3. B. S. Grewal: Higher Engineering Mathematics, Khanna publishers,1986
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
2
CS 302 LOGIC DESIGN
Module 1
Number Systems and codes: Binary ,Octal and Hexa decimal number Systems-Binary
arithematic ,binary code,Excess-3 code, Gray error detection and correction.
Boolean Algebra: Poslulates and theorems, representation of switching functions –SOP
and POS forms –Karnaugh map representation –Minimization using K-maps.
Module 2
Design of combinational circuits:-Tabular minimization:- Design of single output and
muti-output functions-Design using AND,OR,NOT ,NAND NOR and EX-OR gates,
Logic circuits from Boolean Expressions. Design using MSI and LSI devices-Digital
Multiplexer /Selector Decoder. Demultiplexer –Design of 4 bit adder, Carry look ahead
adder –BCD Convertor,Logic implementation using ROM,PAL and PLA.
Module 3
Introduction to Sequential Ckts: combinational Versus sequential Circuits,
Asymchronous Versus Synchronous circuits-Memory elements and their Excitation
function-Tff, Dff, RSff, JK ffs and their excitation requirements –Design of Sequential
Circuits- Shift Registers, Counters –Synchronous and Asynchronous counters, Up—
Down counters, Modular Counter, Ring Counter, Johnson counter ,Analysis of Sequential
circuits-State table and Diagrams.
Module 4
Logic Families: RTL ,DTL ,TTL,CMOS –Tristate logic –Specification and transfer
characteristics of basic TTL interfaces,-Standard logic levels-Current and voltage
parameters-fan in and fan out –Propagation delay, integrated circuit modules, noise
consideration-Interfacing of CMOS to TTL and interfacing of TTL to CMOS.
Text Book:
1. Yarbrough, “Digital Logic Apllications And Design” , Thomson Learning, India
References:
1. Taub & Schilling ,”Digital Integrated Electronics”, Mc Graw Hill
2. Samuel C Lee ,”Digital Circuits and logic Design”,Precentice Hall
3. A p Malvino , “ Digital Computer Electronics “, Tata Mc Graw Hill
4. Morris Miller ,”Design with TTL integrated Circuit”, Mc Graw hill
5. Peatman, ”Digital Hardware Design “,”, Mc Graw Hill
6. Ronald J Tocci ,”Digital Systems ,Principles and Applications”, Prentice Hall
7. Lloyd ,”Digital Fundamentals “, universal , N .Delhi
8. Mercins , “Switching Circuits “, Prentice Hall
9. MOS-LSI Circuits , Publication of Texas Instruments
10. Douglas v hall ,” Digital Circuits and Systems “, Mc Graw Hill
11. R P Jain , Principles of Digital Electronics
12. Mike Toolay, “Electronic Circuits – Fundamentals and Applications”, Elsevier, New
Delhi
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
3
CS/IT 303 DISCRETE COMPUTATIONAL STRUCTURES
Module 1
Logics and Proofs ,propositions, conditional propositions and logical equivalences,
quantifiers, proofs resolution, mathematical induction ,sets ,relations ,equivalence
relations ,functions.
Module 2
Algorithms introduction, notations, recursive algorithms, complexity of algorithm,
counting methods and pigeon hole principle, recurrence relations.
Module 3
Graph theory, paths and cycles, Hamiltonian cycles, representation of graphs, Eulerian
paths, traveling sales man problem, trees, characterization, spanning trees, game trees.
Module 4
Algebraic systems semi groups, monoid, subgroups, homomorphism, isomorphism
automorphism , rings, sub rings, posets, lattice, hasse diagrams
Text books:
1. Richard Johnsonbaugh - Discrete Mathematics Pearson Education fifth edition
2. Satinder Bal Gupta - Discrete mathematical structures Laxmi publications III
edition
References:
1. Malik D. S., Sen S. K - Discrete Mathematical Structures , Thomson Learning
2. Garry Haggard, John Schlipf, Sue Whitesides, Discrete Mathematics for Computer
Science, Thomson Learning
3. Bernard Kolman, Robert C Busby, Sharon Cutler Ross, Nadeem-ur-rehman Discrete
mathematical structures, Pearson Education
4. J P Tremblay and Manohar Mc Graw Hill - Discrete mathematical structures with
applications to computer science -
5. John Truss Addison Wesley- Discrete mathematical structures for Computer
science
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
4
CS/IT 304 OBJECT ORIENTED PROGRAMING USING C++
Module 1
Object oriented technology, comparison with procedural programming (C and C++),key
concepts of object programming, input and output in C++, declarations ,control
structures, functions
Module 2
Classes and Objects, declaring objects, accessing member variables, defining member
functions, inline functions, static member variables and functions, friend function,
overloading, constructors and destructors, overloading constructors, copy constructors
anonymous objects, dynamic initialization using constructors, dynamic operators and
constructors, recursive constructors encapsulation
Module 3
Inheritance, types of inheritance, virtual base class, abstract class, advantages and
disadvantages of inheritance, pointers and arrays, C++ and memory
Module 4
Binding, polymorphism and virtual functions, generic programming with templates,
exception handling, string handling and file handling
Text Books:
1. Ashok N Kamthane , Pearson education - Object oriented programming with ANSI
and TURBO C++ ,
2. Saurav Sahay - Object oriented programming with C++, Oxford
References:
1. Malik, Thomson Learning C++ Programming :From Problem Analysis To Program
Design,
2. Forouzan, Thomson Learning - Computer Science :A Structured Approach Using
C++,2nd Ed.,
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
5
CS305 PRINCIPLES OF PROGRAMING LANGUAGES
Module 1
Programming domains. Language Evaluation.Programming paradigms -Imperative
programming,Functional programming,Object oriented programming,Logic
programming. Formal methods of describing syntax and semantics - Backus Naur Form,
Attribute grammars. Describing semantics - Denotational semantics.
Module 2
Data types, Names, Variables, Bindings, Scope and lifetime, Referencing Environments-
Named Constants-Variable Initialization-Subprograms-Parameter Passing-Coroutines.
Module 3
Data abstraction and encapsulation. Polymorphism and inheritance. Features of objectoriented
languages - Smalltalk,C++ and Java.Design and implementation issues.
Exception handling.
Module 4
Functional programming languages - Lambda calculus - Introduction to pure LISP .
Application of functional programming languages. Logic programming languages - a
brief introduction to predicate calculus - Horn clauses - Logic programming.
Introduction to Prolog. Applications of Logic programming.
Text Books:
1. Robert W.Sebesta, "Concepts of Programming Languages".
2. Ravi Sethi, "Programming Languages-concepts and constructs”, Addison Wesley,
Second Edition , 1996.
References:
1. Michael L. Scott, “Programming Language Pragmatics – Elsevier, New Delhi
2. Thomson Learning, Kenneth.C.Louden, “Programming Languages:Principles And
Practices” ,2nd Ed.,.
3. Terence W. Pratt, "Programming Languages", Prentice Hall , Ninth edition1996.
4. Michael J Gordon, “Programming Language Theory and its implementation",
Prentice Hall ,1991
5. Bjarn Stroustrup, “Design and Evolution of C++”, Addison Wesley, 1991
6. “Symbolic Logic and Logic programming”, Learning Material Series, Indian Society
for Tech. Education, 1996
7. James Gosling “Java Programming Language”, Addison Wesley,
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
6
EB/EE/CS 306 ELECTRONIC DEVICES & CIRCUITS
Module I
DC power supplies - power transformers - rectification - half wave , full wave, bridge -
expression for ripple factor, efficiency, comparison, diode ratings. filters - capacitor - inductor
LC filters- use of bleeder resistor - voltage multipliers - dual power supplies - zener and
avalanche diodes - simple and series voltage regulator. Special semiconductor devices: Principles
and operation of photodiodes, PIN diodes, phototransistors, LED, UJT. MOSFET- basic
principles & characteristics.
Module II
Small Signal amplifiers: Bipolar junction transistor – configurations, characteristics - current
amplification factors - relations between alpha & beta – comparison. BJT amplifiers: Biasing
techniques of BJT- stabilization of operating point - h-parameters - CE RC coupled amplifier -
concept of load lines- frequency response of RC coupled amplifier - frequency analysis of R C
coupled amplifier - lower cut-off frequency - upper cut-off frequency - 3 db bandwidth.
FET Amplifiers: Principle of operation, characteristics, Common source amplifier- design,
frequency response-applications
Module III
Power amplifier - classification - class A, B, AB and C power amplifiers-tuned amplifier- pushpull
and complementary symmetry power amplifier –Harmonic distortion – Heat sinks.
Feed-back amplifiers: concept of Negative and positive feedback – Bark Hausen criteria -low
frequency sinusoidal oscillators
High frequency oscillators – types- LC, Crystal oscillators –circuit diagram-descriptionapplications
Module IV
Pulse Circuits:-Different types Pulse circuits - pulse characteristics - Pulse shaping using RC
circuits - Differentiating and integrating circuits –applications. Clipping and clamping circuits
using diodes - Transistor as a switch– simple sweep circuits-bootstrap sweep.
Multivibrators-astable, monostable and bistable ciruits using BJTs-applications
Text book:
1. Boylestead & Neshelsky, Electronic Devices & Circuit Theory, Prentice Hall of
India.2003
2. Millman & Halkias, Electronic Devices & Circuits, Tata McGraw Hill, New Delhi.1996
3. Taub &Schilling, Pulse,digital and Switching ciruits,Tata Mc Graw Hill 2002
References:
1. Bapat Y N, Electronic Devices & Circuits, Tata McGraw Hill, New Delhi.1995
2. Allan Mottorshed, Electronic Devices & Circuits, Prentice Hall of India, New
Delhi.2003
3. Schilling & Belove, Electronic Circuits, Discrete & Integrated, Tata McGraw Hill, New
Delhi 1989
4. Theodore F.Bogart, Electronic Devices & Circuits Universal Book Stall, New Delhi
1992
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
7
EE/CS 307 ELECTRONICS CIRCUITS LABORATORY
1. Study of - Multimeter, Signal generators, CRO etc. and measurement of
electrical quantities (Voltage, Current, FREQUENCY & PHASE)
1.
2. Characteristics of Active devices
• Forward and reverse characteristics of a diode - measurement of forward
resistance
• Common base characteristics of a transistor - measurement of current gain, input
resistance and output resistance, maximum ratings of the transistor.
• Common emitter characteristics of a transistor - measurement of current gain,
input resistance and output resistance, relation between and study of the effect of
leakag current, maximum ratings of the transistor.
• Common source characteristics of a JFET - measurement of transconductance gm
and
o drain to source resistance rds , use of FET as VVR.
3.Rectifying circuits
• HW rectifier
• FW rectifier
• FW Bridge rectifier
• Filter circuits - Capacitor filter, inductor filter and Pi section filter
(Measurement of ripple factor, maximum ratings of the devices)
4.Regulators –Simple zener voltage regulator,study of transistor series voltage regulator
5.RC coupled amplifier-Frequency response characteristics
6.Low frequency oscillators-RC phase shift or Wien Bridge oscillator
7.Differentiating and Integrating circuits
1. Clipping and clamping circuits
2. Astable multivibrator
Note: 50% Marks is earmarked for continuous evaluation and 50% marks for end
semester examination to be assessed by two examiners. A candidate shall secure a
minimum of 50% marks separately for the two components to be eligible for a pass
in that subject.
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
8
CS/IT 308 OBJECT ORIENTED PROGRAMMING LABORATORY
Exercises to make the students understand the following concepts
Difference between struct and class
Data abstraction
Data encapsulation and information hiding
Inheritance
Single inheritance
Multiple inheritance
Multilevel inheritance
Hierarchical inheritance
Abstract class
Operator overloading
Function overloading
Over-riding
Pointers and arrays
Files
Note: 50% Marks is earmarked for continuous evaluation and 50% marks for end
semester examination to be assessed by two examiners. A candidate shall secure a
minimum of 50% marks separately for the two components to be eligible for a pass
in that subject.
Module 1
Matrices and Vector spaces: Rank of matrix, Echelon and normal form, Solutions of
linear systems of algebraic equations, Eigen values and Eigen vectors, Cayley- Hamilton
theorem (no proof). Vector Spaces- Subspaces,-Linear Independence of vectors-Linear
span-Dimension and Basis. Linear transformations.
Module 2
Fourier series and Fourier integrals: Fourier series of Periodic functions-Euler formulae
for Fourier coefficients- functions having period 2Ï€ , arbitrary period- even and odd
functions-half range expansions, Fourier integral, Fourier cosine and sine
transformations, linearity property, transform of derivatives, convolution theorem (no
proof)
Module 3
Laplace transforms: Linearity property, transforms of elementary functions, Laplace
transforms of derivatives and integrals, differentiation and integration of transforms,
convolution theorm (no proof), use of Laplace transforms in the solution of initial value
problems, unit step function, impulse function - transform of step functions, transforms of
periodic functions.
Module 4
Vector calculus : Scalar and Vector point functions-Gradient and directional derivative of
a scalar point functions.- Divergence and Curl of a vector point functions- their physical
meanings.
Evaluation of line integral, surface integral and volume integrals, Gauss’s divergence
theorem,. Stoke’s theorem (No Proof of these theorem), conservative force fields,
scalar potential.
Text books:
1. R.K. Jain, S.R.K Iyengar: Advanced Engineering Mathematics, Narosa
publishers.1991
2. C.R. Wilie & L.C. Barrett: Advanced Engineering Mathematics, MGH Co.
References
1. Larry C Andrews, Ronald C Philips: Mathematical Techniques for Engineers &
Scientists, PHI
2. M.C. Potter, J.L. Goldberg: Advanced Engineering Mathematics, Oxford university
press
3. B. S. Grewal: Higher Engineering Mathematics, Khanna publishers,1986
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
2
CS 302 LOGIC DESIGN
Module 1
Number Systems and codes: Binary ,Octal and Hexa decimal number Systems-Binary
arithematic ,binary code,Excess-3 code, Gray error detection and correction.
Boolean Algebra: Poslulates and theorems, representation of switching functions –SOP
and POS forms –Karnaugh map representation –Minimization using K-maps.
Module 2
Design of combinational circuits:-Tabular minimization:- Design of single output and
muti-output functions-Design using AND,OR,NOT ,NAND NOR and EX-OR gates,
Logic circuits from Boolean Expressions. Design using MSI and LSI devices-Digital
Multiplexer /Selector Decoder. Demultiplexer –Design of 4 bit adder, Carry look ahead
adder –BCD Convertor,Logic implementation using ROM,PAL and PLA.
Module 3
Introduction to Sequential Ckts: combinational Versus sequential Circuits,
Asymchronous Versus Synchronous circuits-Memory elements and their Excitation
function-Tff, Dff, RSff, JK ffs and their excitation requirements –Design of Sequential
Circuits- Shift Registers, Counters –Synchronous and Asynchronous counters, Up—
Down counters, Modular Counter, Ring Counter, Johnson counter ,Analysis of Sequential
circuits-State table and Diagrams.
Module 4
Logic Families: RTL ,DTL ,TTL,CMOS –Tristate logic –Specification and transfer
characteristics of basic TTL interfaces,-Standard logic levels-Current and voltage
parameters-fan in and fan out –Propagation delay, integrated circuit modules, noise
consideration-Interfacing of CMOS to TTL and interfacing of TTL to CMOS.
Text Book:
1. Yarbrough, “Digital Logic Apllications And Design” , Thomson Learning, India
References:
1. Taub & Schilling ,”Digital Integrated Electronics”, Mc Graw Hill
2. Samuel C Lee ,”Digital Circuits and logic Design”,Precentice Hall
3. A p Malvino , “ Digital Computer Electronics “, Tata Mc Graw Hill
4. Morris Miller ,”Design with TTL integrated Circuit”, Mc Graw hill
5. Peatman, ”Digital Hardware Design “,”, Mc Graw Hill
6. Ronald J Tocci ,”Digital Systems ,Principles and Applications”, Prentice Hall
7. Lloyd ,”Digital Fundamentals “, universal , N .Delhi
8. Mercins , “Switching Circuits “, Prentice Hall
9. MOS-LSI Circuits , Publication of Texas Instruments
10. Douglas v hall ,” Digital Circuits and Systems “, Mc Graw Hill
11. R P Jain , Principles of Digital Electronics
12. Mike Toolay, “Electronic Circuits – Fundamentals and Applications”, Elsevier, New
Delhi
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
3
CS/IT 303 DISCRETE COMPUTATIONAL STRUCTURES
Module 1
Logics and Proofs ,propositions, conditional propositions and logical equivalences,
quantifiers, proofs resolution, mathematical induction ,sets ,relations ,equivalence
relations ,functions.
Module 2
Algorithms introduction, notations, recursive algorithms, complexity of algorithm,
counting methods and pigeon hole principle, recurrence relations.
Module 3
Graph theory, paths and cycles, Hamiltonian cycles, representation of graphs, Eulerian
paths, traveling sales man problem, trees, characterization, spanning trees, game trees.
Module 4
Algebraic systems semi groups, monoid, subgroups, homomorphism, isomorphism
automorphism , rings, sub rings, posets, lattice, hasse diagrams
Text books:
1. Richard Johnsonbaugh - Discrete Mathematics Pearson Education fifth edition
2. Satinder Bal Gupta - Discrete mathematical structures Laxmi publications III
edition
References:
1. Malik D. S., Sen S. K - Discrete Mathematical Structures , Thomson Learning
2. Garry Haggard, John Schlipf, Sue Whitesides, Discrete Mathematics for Computer
Science, Thomson Learning
3. Bernard Kolman, Robert C Busby, Sharon Cutler Ross, Nadeem-ur-rehman Discrete
mathematical structures, Pearson Education
4. J P Tremblay and Manohar Mc Graw Hill - Discrete mathematical structures with
applications to computer science -
5. John Truss Addison Wesley- Discrete mathematical structures for Computer
science
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
4
CS/IT 304 OBJECT ORIENTED PROGRAMING USING C++
Module 1
Object oriented technology, comparison with procedural programming (C and C++),key
concepts of object programming, input and output in C++, declarations ,control
structures, functions
Module 2
Classes and Objects, declaring objects, accessing member variables, defining member
functions, inline functions, static member variables and functions, friend function,
overloading, constructors and destructors, overloading constructors, copy constructors
anonymous objects, dynamic initialization using constructors, dynamic operators and
constructors, recursive constructors encapsulation
Module 3
Inheritance, types of inheritance, virtual base class, abstract class, advantages and
disadvantages of inheritance, pointers and arrays, C++ and memory
Module 4
Binding, polymorphism and virtual functions, generic programming with templates,
exception handling, string handling and file handling
Text Books:
1. Ashok N Kamthane , Pearson education - Object oriented programming with ANSI
and TURBO C++ ,
2. Saurav Sahay - Object oriented programming with C++, Oxford
References:
1. Malik, Thomson Learning C++ Programming :From Problem Analysis To Program
Design,
2. Forouzan, Thomson Learning - Computer Science :A Structured Approach Using
C++,2nd Ed.,
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
5
CS305 PRINCIPLES OF PROGRAMING LANGUAGES
Module 1
Programming domains. Language Evaluation.Programming paradigms -Imperative
programming,Functional programming,Object oriented programming,Logic
programming. Formal methods of describing syntax and semantics - Backus Naur Form,
Attribute grammars. Describing semantics - Denotational semantics.
Module 2
Data types, Names, Variables, Bindings, Scope and lifetime, Referencing Environments-
Named Constants-Variable Initialization-Subprograms-Parameter Passing-Coroutines.
Module 3
Data abstraction and encapsulation. Polymorphism and inheritance. Features of objectoriented
languages - Smalltalk,C++ and Java.Design and implementation issues.
Exception handling.
Module 4
Functional programming languages - Lambda calculus - Introduction to pure LISP .
Application of functional programming languages. Logic programming languages - a
brief introduction to predicate calculus - Horn clauses - Logic programming.
Introduction to Prolog. Applications of Logic programming.
Text Books:
1. Robert W.Sebesta, "Concepts of Programming Languages".
2. Ravi Sethi, "Programming Languages-concepts and constructs”, Addison Wesley,
Second Edition , 1996.
References:
1. Michael L. Scott, “Programming Language Pragmatics – Elsevier, New Delhi
2. Thomson Learning, Kenneth.C.Louden, “Programming Languages:Principles And
Practices” ,2nd Ed.,.
3. Terence W. Pratt, "Programming Languages", Prentice Hall , Ninth edition1996.
4. Michael J Gordon, “Programming Language Theory and its implementation",
Prentice Hall ,1991
5. Bjarn Stroustrup, “Design and Evolution of C++”, Addison Wesley, 1991
6. “Symbolic Logic and Logic programming”, Learning Material Series, Indian Society
for Tech. Education, 1996
7. James Gosling “Java Programming Language”, Addison Wesley,
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
6
EB/EE/CS 306 ELECTRONIC DEVICES & CIRCUITS
Module I
DC power supplies - power transformers - rectification - half wave , full wave, bridge -
expression for ripple factor, efficiency, comparison, diode ratings. filters - capacitor - inductor
LC filters- use of bleeder resistor - voltage multipliers - dual power supplies - zener and
avalanche diodes - simple and series voltage regulator. Special semiconductor devices: Principles
and operation of photodiodes, PIN diodes, phototransistors, LED, UJT. MOSFET- basic
principles & characteristics.
Module II
Small Signal amplifiers: Bipolar junction transistor – configurations, characteristics - current
amplification factors - relations between alpha & beta – comparison. BJT amplifiers: Biasing
techniques of BJT- stabilization of operating point - h-parameters - CE RC coupled amplifier -
concept of load lines- frequency response of RC coupled amplifier - frequency analysis of R C
coupled amplifier - lower cut-off frequency - upper cut-off frequency - 3 db bandwidth.
FET Amplifiers: Principle of operation, characteristics, Common source amplifier- design,
frequency response-applications
Module III
Power amplifier - classification - class A, B, AB and C power amplifiers-tuned amplifier- pushpull
and complementary symmetry power amplifier –Harmonic distortion – Heat sinks.
Feed-back amplifiers: concept of Negative and positive feedback – Bark Hausen criteria -low
frequency sinusoidal oscillators
High frequency oscillators – types- LC, Crystal oscillators –circuit diagram-descriptionapplications
Module IV
Pulse Circuits:-Different types Pulse circuits - pulse characteristics - Pulse shaping using RC
circuits - Differentiating and integrating circuits –applications. Clipping and clamping circuits
using diodes - Transistor as a switch– simple sweep circuits-bootstrap sweep.
Multivibrators-astable, monostable and bistable ciruits using BJTs-applications
Text book:
1. Boylestead & Neshelsky, Electronic Devices & Circuit Theory, Prentice Hall of
India.2003
2. Millman & Halkias, Electronic Devices & Circuits, Tata McGraw Hill, New Delhi.1996
3. Taub &Schilling, Pulse,digital and Switching ciruits,Tata Mc Graw Hill 2002
References:
1. Bapat Y N, Electronic Devices & Circuits, Tata McGraw Hill, New Delhi.1995
2. Allan Mottorshed, Electronic Devices & Circuits, Prentice Hall of India, New
Delhi.2003
3. Schilling & Belove, Electronic Circuits, Discrete & Integrated, Tata McGraw Hill, New
Delhi 1989
4. Theodore F.Bogart, Electronic Devices & Circuits Universal Book Stall, New Delhi
1992
Type of questions for University Examination
Question 1 - 8 short answer questions of 5 marks each. 2 questions from each module
Question 2-5 – There will be two choices from each module .Answer one question from each module of
15 marks
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
7
EE/CS 307 ELECTRONICS CIRCUITS LABORATORY
1. Study of - Multimeter, Signal generators, CRO etc. and measurement of
electrical quantities (Voltage, Current, FREQUENCY & PHASE)
1.
2. Characteristics of Active devices
• Forward and reverse characteristics of a diode - measurement of forward
resistance
• Common base characteristics of a transistor - measurement of current gain, input
resistance and output resistance, maximum ratings of the transistor.
• Common emitter characteristics of a transistor - measurement of current gain,
input resistance and output resistance, relation between and study of the effect of
leakag current, maximum ratings of the transistor.
• Common source characteristics of a JFET - measurement of transconductance gm
and
o drain to source resistance rds , use of FET as VVR.
3.Rectifying circuits
• HW rectifier
• FW rectifier
• FW Bridge rectifier
• Filter circuits - Capacitor filter, inductor filter and Pi section filter
(Measurement of ripple factor, maximum ratings of the devices)
4.Regulators –Simple zener voltage regulator,study of transistor series voltage regulator
5.RC coupled amplifier-Frequency response characteristics
6.Low frequency oscillators-RC phase shift or Wien Bridge oscillator
7.Differentiating and Integrating circuits
1. Clipping and clamping circuits
2. Astable multivibrator
Note: 50% Marks is earmarked for continuous evaluation and 50% marks for end
semester examination to be assessed by two examiners. A candidate shall secure a
minimum of 50% marks separately for the two components to be eligible for a pass
in that subject.
CUSAT B.Tech Degree Course – Scheme of Examinations & Syllabus 2006 CS Sem III
8
CS/IT 308 OBJECT ORIENTED PROGRAMMING LABORATORY
Exercises to make the students understand the following concepts
Difference between struct and class
Data abstraction
Data encapsulation and information hiding
Inheritance
Single inheritance
Multiple inheritance
Multilevel inheritance
Hierarchical inheritance
Abstract class
Operator overloading
Function overloading
Over-riding
Pointers and arrays
Files
Note: 50% Marks is earmarked for continuous evaluation and 50% marks for end
semester examination to be assessed by two examiners. A candidate shall secure a
minimum of 50% marks separately for the two components to be eligible for a pass
in that subject.
Sunday, November 28, 2010
COMPUTER-ANIMATION LANGUAGES
COMPUTER-ANIMATION LANGUAGES
Design and control of animation sequences are handled with a set of animation
routines. A general-purpose language, such as C, Lisp, Pascal, or FORTRAN, is
often used to program the animation functions, but several specialized animation
languages have been developed. Animation functions include a graphics editor, a
key-frame generator, an in-between generator, and standard graphics routines.
The graphics editor allows us to design and modify object shapes, using spline
surfaces, constructive solid-geometry methods, or other representation schemes.
A typical task in an animation specilkation is scene description. This includes
the positioning of objects and light sources, defining the photometric parameters
(light-source intensities and surface-illumination properties), and setting the
camera parameters (position, orientation, and lens characteristics). Another standard
function is action specifimtion. This involves the layout of motion paths for
the objects and camera. And we need the usual graphics routines: viewing and
perspective transformations, geometric transformations to generate object movements
as a function of accelerations or kinematic path specif~cations,v isible-surface
identification, and the surface-rendering operations.
Key-frame systems are specialized animation languages designed simply
to generate the in-betweens from the user-specified key frames. Usually, each object
in the scene is defined as a set of rigid bodies connected at the joints and with
a limited number of degrees of freedom. As an example, the single-arr.1 robot in
Fig. 16-4 has six degrees of freedom, which are called arm sweep, shoulder
swivel, elbow extension, pitch, yaw, and roll. We can extend the number of degrees
of freedom for this robot arm to nine by allowing three-dimensional translations
for the base (Fig. 16-51. If we also allow base rotations, the robot arm can
have a total of 12 degrees of freedom. The human body, in comparison, has over
200 degrees of freedom.
Parameterized systems allow object-motion characteristics to be specified
as part of the object definitions. The adjustable parameters control such object
characteristics as degrees of freedom, motion limitations, and allowable shape
changes.
Computer-Anmalion
Scripting systems allow object specifications and aninlation sequences to
be defined with a user-input script. From the script, a library of various objects
and motions can be constructed
COCOMO MODEL
In his classic book on “software engineering economics,” Barry Boehm [BOE81] introduced
a hierarchy of software estimation models bearing the name COCOMO, for
COnstructive COst MOdel. The original COCOMO model became one of the most widely
used and discussed software cost estimation models in the industry. It has evolved
into a more comprehensive estimation model, called COCOMO II [BOE96, BOE00].
Like its predecessor, COCOMO II is actually a hierarchy of estimation models that
address the following areas:
Application composition model. Used during the early stages of software
engineering, when prototyping of user interfaces, consideration of software
and system interaction, assessment of performance, and evaluation of technology
maturity are paramount.
Early design stage model. Used once requirements have been stabilized
and basic software architecture has been established.
Post-architecture-stage model. Used during the construction of the
software.
Like all estimation models for software, the COCOMO II models require sizing information.
Three different sizing options are available as part of the model hierarchy:
object points, function points, and lines of source code.
The COCOMO II application composition model uses object points and is
illustrated in the following paragraphs. It should be noted that other, more
sophisticated estimation models (using FP and KLOC) are also available as part of
COCOMO II.
Like function points (Chapter 4), the object point is an indirect software measure
that is computed using counts of the number of (1) screens (at the user interface), (2)
reports, and (3) components likely to be required to build the application. Each object
instance (e.g., a screen or report) is classified into one of three complexity levels (i.e.,
simple, medium, or difficult) using criteria suggested by Boehm [BOE96]. In essence,
complexity is a function of the number and source of the client and server data tables
that are required to generate the screen or report and the number of views or sections
presented as part of the screen or report.
Once complexity is determined, the number of screens, reports, and components
are weighted according to Table 5.1. The object point count is then determined by
multiplying the original number of object instances by the weighting factor in Table
5.1 and summing to obtain a total object point count. When component-based development
or general software reuse is to be applied, the percent of reuse (%reuse) is
estimated and the object point count is adjusted:
NOP = (object points) x [(100 %reuse)/100]
where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, a “productivity
rate” must be derived. Table 5.2 presents the productivity rate
PROD = NOP/person-month
for different levels of developer experience and development environment maturity.
Once the productivity rate has been determined, an estimate of project effort can be
derived as
estimated effort = NOP/PROD
In more advanced COCOMO II models,15 a variety of scale factors, cost drivers,
and adjustment procedures are required. A complete discussion of these is beyond
the scope of this book. The interested reader should see [BOE00] or visit the COCOMO
II Web site.
a hierarchy of software estimation models bearing the name COCOMO, for
COnstructive COst MOdel. The original COCOMO model became one of the most widely
used and discussed software cost estimation models in the industry. It has evolved
into a more comprehensive estimation model, called COCOMO II [BOE96, BOE00].
Like its predecessor, COCOMO II is actually a hierarchy of estimation models that
address the following areas:
Application composition model. Used during the early stages of software
engineering, when prototyping of user interfaces, consideration of software
and system interaction, assessment of performance, and evaluation of technology
maturity are paramount.
Early design stage model. Used once requirements have been stabilized
and basic software architecture has been established.
Post-architecture-stage model. Used during the construction of the
software.
Like all estimation models for software, the COCOMO II models require sizing information.
Three different sizing options are available as part of the model hierarchy:
object points, function points, and lines of source code.
The COCOMO II application composition model uses object points and is
illustrated in the following paragraphs. It should be noted that other, more
sophisticated estimation models (using FP and KLOC) are also available as part of
COCOMO II.
Like function points (Chapter 4), the object point is an indirect software measure
that is computed using counts of the number of (1) screens (at the user interface), (2)
reports, and (3) components likely to be required to build the application. Each object
instance (e.g., a screen or report) is classified into one of three complexity levels (i.e.,
simple, medium, or difficult) using criteria suggested by Boehm [BOE96]. In essence,
complexity is a function of the number and source of the client and server data tables
that are required to generate the screen or report and the number of views or sections
presented as part of the screen or report.
Once complexity is determined, the number of screens, reports, and components
are weighted according to Table 5.1. The object point count is then determined by
multiplying the original number of object instances by the weighting factor in Table
5.1 and summing to obtain a total object point count. When component-based development
or general software reuse is to be applied, the percent of reuse (%reuse) is
estimated and the object point count is adjusted:
NOP = (object points) x [(100 %reuse)/100]
where NOP is defined as new object points.
To derive an estimate of effort based on the computed NOP value, a “productivity
rate” must be derived. Table 5.2 presents the productivity rate
PROD = NOP/person-month
for different levels of developer experience and development environment maturity.
Once the productivity rate has been determined, an estimate of project effort can be
derived as
estimated effort = NOP/PROD
In more advanced COCOMO II models,15 a variety of scale factors, cost drivers,
and adjustment procedures are required. A complete discussion of these is beyond
the scope of this book. The interested reader should see [BOE00] or visit the COCOMO
II Web site.
Nokia c7
GENERAL | 2G Network | GSM 850 / 900 / 1800 / 1900 |
|---|---|---|
| 3G Network | HSDPA 850 / 900 / 1700 / 1900 / 2100 | |
| Announced | 2010, September | |
| Status | Available. Released 2010, October |
| SIZE | Dimensions | 117.3 x 56.8 x 10.5 mm, 64 cc |
|---|---|---|
| Weight | 130 g |
| DISPLAY | Type | AMOLED capacitive touchscreen, 16M colors |
|---|---|---|
| Size | 360 x 640 pixels, 3.5 inches | |
| - Proximity sensor for auto turn-off - Accelerometer sensor for UI auto-rotate |
| SOUND | Alert types | Vibration; MP3, WAV ringtones |
|---|---|---|
| Speakerphone | Yes | |
| - 3.5 mm audio jack |
| MEMORY | Phonebook | Practically unlimited entries and fields, Photocall |
|---|---|---|
| Call records | Detailed, max 30 days | |
| Internal | 8 GB storage, 256 MB RAM, 1 GB ROM | |
| Card slot | microSD, up to 32GB, buy memory |
| DATA | GPRS | Class 32 |
|---|---|---|
| EDGE | Class 32 | |
| 3G | HSDPA, 10.2 Mbps; HSUPA, 2 Mbps | |
| WLAN | Wi-Fi 802.11 b/g/n | |
| Bluetooth | Yes, v3.0 with A2DP | |
| Infrared port | No | |
| USB | Yes, microUSB v2.0, USB On-the-go support |
| CAMERA | Primary | 8 MP, 3264x2448 pixels, fixed focus, dual-LED flash |
|---|---|---|
| Features | Geo-tagging, face detection | |
| Video | Yes, 720p@25fps, video stabilization | |
| Secondary | Yes, VGA |
| FEATURES | OS | Symbian^3 OS |
|---|---|---|
| CPU | ARM 11 680 MHz processor, 3D Graphics HW accelerator | |
| Messaging | SMS, MMS, Email, Push Email, IM | |
| Browser | WAP 2.0/xHTML, HTML, RSS feeds | |
| Radio | Stereo FM radio, FM transmitter | |
| Games | Yes + downloadable | |
| Colors | Charcoal black, Frosty metal, Mahogany brown | |
| GPS | Yes, with A-GPS support; Ovi Maps 3.0 | |
| Java | Yes, MIDP 2.1 | |
| - Web TV - TV-out - Digital compass - Active noise cancellation with dedicated mic - MP3/WMA/WAV/eAAC+ player - DivX/XviD/MP4/H.264/H.263/WMV player - Quickoffice document viewer (Word, Excel, PowerPoint, PDF) - Adobe Reader - Flash Lite 4.0 - Voice memo/dial/command - T9 |
| BATTERY | Standard battery, Li-Ion 1200 mAh (BL-5K) | |
|---|---|---|
| Stand-by | Up to 552 h (2G) / Up to 648 h (3G) | |
| Talk time | Up to 9 h 30 min (2G) / Up to 5 h (3G) | |
| Music play | Up to 54 h |
| MISC | SAR US | 1.03 W/kg (head) 0.83 W/kg (body) |
|---|---|---|
| SAR EU | 0.73 W/kg (head) |
Subscribe to:
Posts (Atom)