C++ Programming

Ideally, none. Base classes should have no knowledge whatsoever of their derived classes and therefore should have no access to any members declared in the derived classes. However, derived class methods are accessible via virtual functions declared in the base class. The correct methods (overrides) are called via the virtual table, but the base class itself requires no specific knowledge of the derived class in order to call these methods. This makes sense since a base class cannot know in advance all the classes that may or may not derive from it in the future.

If a method must be guaranteed to be implemented by a derived class, a pure-virtual method can be declared in the base class instead. This renders the base class abstract, meaning you cannot instantiate an object from the base class, only from a derivative that fully implements (or inherits) all the pure-virtual methods.

Conversely, a derived class can access all the public and protected members of its base class.

Yes. Examples can be found in stdio.h

#include<iostream>

#include<list>

struct item

{

item(const char ch):chr(ch), count(1){}

char chr;

size_t count;

};

int main()

{

const size_t size=50;

size_t idx;

std::list<item> freq;

std::list<item>::iterator iter;

std::string test;

for(idx=0; idx<size; ++idx)

test.push_back('a'+rand()%26);

for(idx=0; idx<size; ++idx)

{

for(iter=freq.begin(); iter!=freq.end() && (*iter).chr!=test[idx]; ++iter);

if( iter!=freq.end() )

++(*iter).count;

else

freq.push_back(item(test[idx]));

}

std::cout<<"Frequency table of the string:\n""<<test.c_str()<<""\n"<<std::endl;

for(iter=freq.begin(); iter!=freq.end(); ++iter)

{

item& itm=*iter;

std::cout<<itm.chr<<" = "<<itm.count<<std::endl;

}

std::cout<<std::endl;

}

Remember that derived classes can access the public and protected members of their base class, but none of the private members. If the member variable in the base class is protected (rather than private), then the derived class can assign it directly. However, this is bad style in OOP as it undermines data-hiding. A protected mutator (set accessor) would be a better option.

The following function performs a non-recursive linear search of the given vector, returning a constant iterator to the element containing the given value. If the value does not exist, the "one-past-the-end" iterator is returned instead.

std::vector<int>::const_iterator find (int val, const std::vector<int>& v){

for (std::vector<int>::const_iterator it=v.begin(); it!=v.end(); ++it)

if (*it==val) return it;

return v.end();

}

Wahen we say scope we're referring to the enclosing context of a member. In C++, the scope or context of a member is defined by its enclosing namespace. A namespace allows us to completely separate all the enclosed members from all the members of all other namespaces. Namespaces can also enclose other namespaces. Members that do not have an enclosing namespace of their own are said to exist within the global namespace -- effectively a namespace with no name. However, the global namespace also provides the enclosing context for all other namespaces. That is, namespaces create a hierarchy or "family-tree" where the global namespace serves as the root.

Note that although namespaces are typically created by using the namespace keyword, we also create namespaces whenever we declare a class, struct, union or enum. That is, a class name is a namespace in its own right. If that class is not defined within the context of any other namespace then it implicitly exists within the global namespace.

Namespaces literally allow us to separate names (variable names, function names and class names, etc) into separate "spaces". That is, two namespaces can share the same name provided they exist within separate namespaces. However, it is often necessary for the members of one namespace to refer to the members of another namespace. This is achieved by using the scope resolution operator. If we do not use scope resolution, the compiler will search for the name within the current namespace and if no such name exists, it will search the global namespace. If the name cannot be found in either, a coimpiler error occurs.

With regards to global variables, we do not need to use scope resolution unless the global variable has a name that also exists within the current namespace. But since the global namespace has no name, we simply omit the namespace that would normally preceed the scope resolution operator. For instance, if the global variable were named matrix and the current namespace also happened to contain the same name, we can refer to the global instance as ::matrix.

Of course we could easily avoid such problems by choosing more appropriate names. Variables in the global namespace should always be given the prefix "g_", thus our global matrix becomes g_matrix. By the same token, member variables should be given the prefix "m_", thus our namespace's matrix becomes m_matrix.

While this resolves any potential name-clashes or ambiguity with regards member data and global data, prefixing global functions and member functions in this way would be considered quite unsatisfactory. In these cases scope resolution is the ideal solution.

Of course, it would be better to avoid global data altogether, but that's a different topic entirely.

The one that most commonly causes a foul odor is vaginal trichomoniasis.
mostly bacteria infections- and U T I's

Separated queue for every possible priority value.

When a piece of software running for an extended time uses more and more memory. The software is not releasing its resources correctly! And so the machine cannot recoup memory.

It is possible that eventually the machine will crash, or the offending software will need restarted.

An abstract class is a class that has a pure virtual function.

A pure virtual function can be used in a base class if the function that is virtualised contains parameters that can and should be interchangeable, but the function should remain intact.

For example, there is a base class Object in a game that will contain movement for simple objects, but the movement function may need to use different parameters per object.

No. Java is 100% OOP while C++ supports the concept of primitives (which it inherited from C). Thus C++ supports far more features than Java, but it does not support any more OOP features than Java. Note that there are only four primary OOP features: encapsulation, abstraction, inheritance and polymorphism. Anything beyond that is implementation-specific and outwith the scope of OOP.

Design, flowchart, encode, compile, test and debug.

struct SClass{

int iNumber;

int (*fpgetValue)();

int (*fpsetValue)();

}Sc;

int m_Func(){

printf("\n\n Hello How are you doing,i called by function pointer");

getchar();

return 1;

}

int _tmain(int argc, _TCHAR* argv[])

{

Sc.fpgetValue=m_Func;

Sc.fpgetValue();

return 0;

}

Any name that is not a reserved word can be a legal variable, function or type name. All names must be alphanumeric, but they cannot begin with a digit. The C++ standard recommends that all user-defined names be written entirely in lower case with underscores for spaces. Some programmers prefer 'camel case' (such as PrintObject and MaxNumber), which was a popular convention amongst the Pascal programming community, however print_object and max_number are the C++ conventions. Names in all caps are typically reserved for macro definitions (which is effectively a separate language from C++ itself), while names with leading underscores should generally be avoided as this convention is utilised extensively within the standard library.

Data abstraction is a design concept, whereby interfaces and implementations are kept separate. That is, it should not be necessary to know how an object works in order to use it. The interface provides all you need to know.

This reflects much of real life. When watching TV, you have a remote control which allows you to select a channel, but it is not necessary to know how the TV receives and processes radio signals, nor how it separates one channel from another. Those are implementation details that are only of concern to TV engineers.

In C++, there are no statements as such to implement data abstraction. You achieve it by designing a public interface which is accessible to normal users, and a private interface that is only accessible to the class designer.

Starting with a pointer to the pointer to the first element (p1**), verify the first pointer is not null (*p1 != null), retrieve the pointer to the second element (*p2 = *p1.next) and verify it is also not null (*p2 != null), and then retrieve the pointer to the third element (*p3 = *p2.next). Note that *p3 might be null, but *p1 and *p2 must not be null, or the swap can not be performed. Note that using pointer to pointer syntax allows you to treat pointer to first element the same as pointer to subsequent element, i.e. to not need to handle the special case. Also, since you do need to modify the pointer, you need a pointer to the pointer. Set *p1 = *p2, *p3 = *p1, and *p2 = *p3. Note that these assignments must be done using the original values, not the intermediate value, so you will need some temp pointers. The end result is that **p1 will be ordered after **p2.

Here is the C code for DDA line drawing...

#include<stdio.h>

#include<conio.h>

#include<graphics.h>

#include<math.h>

void main()

{

int gd, gm;

float x, y, dx, dy, len;

int x1, y1, x2, y2, i;

detectgraph(&gd, &gm);

initgraph(&gd, &gm,"");

printf("\n Enter the coordinates of line : ");

scanf("%d %d %d %d", &x1, &y1, &x2, &y2);

dx = abs(x2-x1);

dy = abs(y2-y1);

if (dx >= dy) len = dx;

else len = dy;

dx = (x2-x1)/len;

dy = (y2-y1)/len;

x = x1 + 0.5;

y = y1 + 0.5;

i = 1;

while (i <= len)

{

putpixel(x, y, 6);

x = x+dx;

y = y+dy;

i++;

}

getch();

}

-Suraj.

Actually, there is not that much attention today paid to object-oriented programming. It is not a new technology. It is more than 15 years old, and the design paradigm of object-oriented design and object-oriented programming is relatively well established.

Where the attention today is focused is more on multi-threaded programming. The reason for this is that today's processors are approaching the point where Moore's Law is starting to flatten out, i.e. we are approaching the limits of performance gains in a single processor as technology advances.

Many modern computers solve this problem by having more than one processor. Some have many, even thousands or more, such as in a modern supercomputer. The problem is that it is very difficult to write algorithm's that can adequately take advantage of that parallelism. We tend to think linearly, and our algorithms follow that thinking. Such a linear process, however, can only use one processor at a time. We need to work on algorithms that can utilize all of the available processors in a computer at the same time.

Two "yesterdays" ago, the challenge was Block Structured Programming. One "yesterday" ago, the challenge was Object Orientation. "Today", the challenge is Multi-Threading.

It's a bit difficult to show a class hierarchy using unformatted text alone, so I'll use the scope resolution operator to show the relationships instead.

Note: [] denotes multiple inheritance

ios_base

ios_base::ios

ios_base::ios::istream

ios_base::ios::ostream:

ios_base::ios::istream::ifstream

ios_base::ios::ostream::ofstream

ios_base::ios::[istream/ostream]::iostream

ios_base::ios::[istream/ostream]::iostream::fstream

ios_base::ios::[istream/ostream]::iostream::stdiostream

ios_base::ios::[istream/ostream]::iostream::stringstream

streambuf

streambuf::filebuf

streambuf::stdiobuf

Anything that you can't put whitespace between. The indivisible elements of a program.

Example: printf("Sup world %d",variable);

Tokens: (7 total)

printf

(

"Sup World %d"

,

variable

)

;