C++ Programming

There are four modifiers in C++: long, short, signed and unsigned. They are used to modify primitive types (int, char, float and double) to change their behaviour. If no type is specified, int is assumed. Thus a long long turns a 32-bit integer into a 64-bit integer while unsigned ensures an integer is always in the positive range.

Inline expansion relates to the way in which a function call is replaced with the function body in your compiled code. The idea is that by eliminating the function call, your code will be faster because you eliminate the overhead of the function call (which requires a lot of unnecessary pushing and popping from the call stack). However, if the function is large and is called many times throughout your code, the extra speed gained by eliminating the function calls might be outweighed by the performance lost due to the increased code size.

Thus you will make a function inline when you know that there will be an advantage in doing so. In reality, however, marking a function for inline expansion merely states to the compiler that inline expansion is desired but is not required. The compiler is free to ignore the request when it can find no advantage in doing so. Some compilers may provide alternative methods that allow the programmer to overrule the compiler, but these should generally be avoided unless you can be absolutely certain there is an advantage to be gained (which will require an intimate understanding of your compiler's optimisers). In most cases it is best to let the compiler decide when inline expansion should occur, because what may be suitable for one program may not be suitable for all programs.

Aside from implementation-specific methods, there are essentially two ways to mark a function as a candidate for inline expansion: implicitly and explicitly. Implicit inline expansion occurs automatically whenever you define a function within its own declaration. Explicit expansion occurs when the declaration and definition are separate, but the definition is explicitly marked inline and appears in the same translation unit as the declaration. Where there is only one .cpp file, the definition may appear in that .cpp file (the declaration should always be placed in a header), but in all other cases this would result in an "unresolved external symbol" error from the linker. Thus the definition must appear in a header.

Note that although a definition is also a declaration, for the purpose of this answer a definition provides implementation while a declaration does not (a declaration in this sense simply means a forward declaration that will be implemented elsewhere).

The problem with inline expansion (whether implicit or explicit) is that the implementation may be visible to the caller, because it must also be visible to the linker. Whether this is desirable or not depends upon the function's purpose. However, the recommended method is to use explicit inline expansion, particularly with class methods. Although you cannot hide implementations within headers, you can limit the exposure by keeping the implementation physically separate. Consumers are only interested in the interface, so there's little point in confusing them with non-essential information within the declaration, which includes the use of the inline keyword (only the definition should be explicitly marked for inline expansion).

In most cases, inline expansion should be limited to functions that contain very simple statements or expressions. These can often result in reducing code size as well as improving performance. However, the same can be said of more complex functions where the compiler's optimisers can eliminate redundant code through procedural integration (making large functions smaller). Increased code size is not necessarily a bad thing unless the application is CPU-bound and the increased code size would result in increased paging (commonly known as thrashing). For non-CPU-bound applications inline expansion is largely irrelevant because overall performance would ultimately be determined by the bottlenecks elsewhere, such as file systems, databases or networks.

When a function is declared static at file scope, this means the function has internal linkage only. That is, the function is only accessible to the translation unit in which it is declared. This applies to both C and C++. However, we can achieve the same thing in C++ by declaring a (non-static) function in an un-named (anonymous) namespace. Whether this better represents internal linkage or not is merely a matter of taste.

In C++ we can also declare static functions inside a class. Static member functions differ from non-static member functions in that they do not have access to a 'this' pointer; they are local to the class, not to objects (instances) of the class. As such, they can be invoked without having to instantiate an object from the class.

1) first you have to find the reverse of an integer..

code is given below,

#include<stdio.h>

void main()

{

int a,b,m,s=0;

printf("enter the value of a");

scanf("%d",&a);

b=a;

while(a!= 0)

{

m=a%10;

s=s*10+m;

a=a/10;

}

if(s == b)

{

printf("original number is equal to the reversed number");

}

else

{

printf("original number is not equal to the reversed number");

As many as required. The only practical limits are those imposed by the hardware. For instance, 32-bit systems can only address a maximum of 4GB, but only 2GB is actually available to applications. On 64-bit systems there is no practical limit other than hard-drive space (for the virtual memory paging file).

Remember that every class of object requires memory to store its member variables (plus padding for alignment), which has to be multiplied up by the number of instances of those classes. Thus the more complex the hierarchy, the fewer instances you can create overall. Since alignment padding can add a substantial overhead, it's best to declare member variables from largest to smallest within each class because memory is allocated in the same order the members are declared. If a v-table is required (which it typically will be in a multi-level hierarchy) this will consume additional memory: essentially one function pointer per virtual function per override.

That said, it is difficult to imagine any hierarchy so large that you will hit a memory limitation, even on a 32-bit system, unless you happen to embed a particularly large member variable in your class, such as a hi-resolution image or video, rather than use a disk-based file stream. Aside from that the main concern is in how many instances of that hierarchy can you physically construct at one time. However, you need only look at some of the hierarchies within the Microsoft Foundation Classes to realise that your probably just scratching the surface of what is actually possible.

Very! C++ isn't the best language out there, it certainly has its issues, but it's very powerful. It's also fairly low-level, as far as modern languages are concerned. Python has all the power with few of the costs. If you already know how to program, you should be able to pick it up in less than two hours. Most the concepts you learned in C++ (inheritance, polymorphism, etc) still apply, too. Python has the advantage of plenty of super easy-to-use libraries for many thing (such as downloading a web page). It can't hurt to try, so give Python a spin and see if it benefits you.

see related link below

The advantages of recursion tend to revolve around the fact that there are quite a few algorithms which lend themselves to recursion (tree traversal, binary searches, quick sort, etc.)

The disadvantages of recursion include:

* finite number of recursive steps (limited heap space) * speed/efficiency (easier to increment a loop counter than call a function)

#include <stdio.h>

#include <conio.h>

void main()

{

float p, r, si;

int t;

clrscr();

printf("Enter the values of p,r and t\n");

scanf ("%f %f %d", &p, &r, &t);

si = (p * r * t)/ 100.0;

printf ("Amount = Rs. %5.2f\n", p);

printf ("Rate = Rs. %5.2f%\n", r);

printf ("Time = %d years\n", t);

printf ("Simple interest = %5.2f\n", si);

}

There are no statements as such. Encapsulation is a design concept. The basic principal of encapsulation is that an object should contain all the information necessary to use the object, nothing more and nothing less. In other words, an object is a self-contained entity.

An overloaded function is a function that has several implementations, the only difference being the number and type of parameters, including usage of the const keyword. Overloads cannot differ by return type alone. The following is a trivial example of function overloading.

const int & max(const int & lhs, const int & rhs){return( lhs>rhs ? lhs : rhs );}

const char & max(const char & lhs, const char & rhs){return( lhs>rhs ? lhs : rhs );}

Since the implementation is exactly the same, regardless of the type of parameters, it would make more sense to enlist the compiler to generate all the possible variants of this overloaded function using a template function. The compiler then generates all the overloads as required, and you only have one function to maintain.

Overloads are better suited to functions that have completely different signatures with a different number of parameters. For instance:

typedef struct rect_tag

{

float width;

float height;

} rect;

const float & Area( const rect & rc ){ return( rc.width * rc.height ); }

const int & Area( const int & width, const int & height ){ return( width * height ); }

const float & Area( const int & width, const float & height ){ return((float) width * height ); } const float & Area( const float & width, const int & height ){ return( width * (float) height ); }

The point of overloading functions is increased flexibility.You don't have to worry about which version of a function you call, nor is there any need to cast parameters to a specific type, since the compiler can work out which version of a function to call simply from the type of parameters you supply. If no suitable overload exists, the compiler will warn you so that you may either provide one, or explicitly cast your variables to a suitable version.

Mixing overloads with default parameter values increases the flexibility further, provided there is no ambiguity regarding which version of the overload is being called.

If you are talking "far pointer", then you are probably talking about real mode in a 16 bit environment such as DOS or Windows 3.1, or in Virtual 8086 mode in Windows 95 or higher. In this mode, addressing is segmented into 65536 segments of 65536 bytes each, but each segment overlaps the next by only a 16 byte offset. This gives you addressability to 1048576 bytes. A far pointer is a 32 bit object, containing a 16 bit segment and a 16 bit offset. int __far *p; /* a far pointer called p which points to an int */

For gcc there's a non-standard solution. Declare the function with __attribute__((constructor)) (note the double parentheses).

Like this:

void init(void) __attribute__ ((constructor));

void init(void) {

// your code goes here

}

Starting with gcc 4.3 there's even a possibility to assign a priority to the "constructor". See http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Function-Attributes.html for details.

The access privileges in c++ are

1.public

2.private

3.protected

and by default its private

A data type tends to mean a primitive data type. Primitive data are built-in data types, such as integers, characters and Booleans. They are basic constructs of the language (that is, they are built into the language).

Primitive data also tends to be of a strict data type, meaning you can't treat characters like integers or Booleans like integers, etc., although some languages will support implicit casting of primitive data types (for example, will treat Booleans like integers if you use a Boolean in an arithmetic operation).

Abstract data types are generally constructed by the user or by a higher level language. For example, you might create a currency data type, which generally acts like a float but always has a precision of 2 decimal places and implements special rules about how to round off fractions of a cent.

Abstract data types also often contain the ability to either be treated as a specific type of primitive data in certain circumstances (for example, many languages allow you to treat strings as character arrays); or contain certain rules / methods to manipulate their data (such as a programming language allowing you to cast a float as an integer).

A data structure is a gathering together of many different data types. For example, objects and arrays are data structures. Data structures usually can contain information of many different types (such as strings, integers, Booleans) at the same time, and in more complex structures -- namely, classes -- can contain specific methods, properties and events to manipulate that data, change its type, etc.

The main drawback to structured programming is that the data and the methods that operate upon that data are completely separate. This means that any code with access to the data can modify that data. In and of itself that is not a major problem, but it places the onus upon the programmer to ensure that all data is modified in a consistent and highly predictable manner, which may require additional verifications and assurances within the code to ensure that is always the case. For instance, if a variable must have a limited range of 0 to 100, then the programmer may be forced to ensure that is the case before he can use the data, and may need to perform that same check every time the data is used.

Object oriented programming combines the data and the methods that operate upon that data into a single entity, presenting the data to the outside world in a more abstract form, limiting its exposure and protecting its integrity. Mutators that modify the internal data act as gatekeepers, assuring that any and all modifications to the data are consistent. The programmer no longer needs to continually check the state of the data before using the data, as the onus is now upon the object to ensure that data integrity is maintained at all times.

By delegating the workload to the objects themselves, highly-complex data models can be created simply by embedding objects within objects, where each individual object is solely responsible for its own data integrity. The programmer can then manipulate these highly complex structures as a single entity, rather than through a series of separate functions and data that could very easily be corrupted by a single errant statement that would be difficult to trace.

You don't need to write a program to do this. Each character (char) is actually an int. If you want to see the ASCII value of a char you can simply:

char c = 'a';

System.out.print( (int)c );

#include<iostream>

int main()

{

int x=0, y=1;

std::cout<<x<<" ";

std::cout<<y<<" ";

while( y<1000000 )

{

std::cout<<(y+=x)<<" ";

x=y-x;

}

std::cout<<std::endl;

return(0);

}

Declaring a function to be a friend of a class allows the friend function to gain private (and protected) access to that class, just as it would if it were declared a static member function of the class. Most of the time you will want to use static functions rather than friend functions, but sometimes it is necessary for a member method of another class or an external function to be permitted private access. Although some will tell you this undermines the encapsulation of the class, it does not. If anything, it reinforces that encapsulation, by only allowing the specified function to gain private access. Although the friend function is not physically a member of the class, it automatically becomes tightly bound to the class. That is not necessarily a bad thing when you're only dealing with a limited number of friends, but a class that has many friends can often be an indication of poor class design. Thus it is important to limit friendship and to only use it when it is absolutely required, whenever possible.

By way of an example, suppose you have designed a parent and child class. Even without friend functions, the two are implicitly bound to each other: the parent object is a container for child objects, while child objects refer to their parents. All work is delegated and coordinated between the two classes accordingly; they work together as one. Most of the work can be encapsulated without the need to explicitly bind the classes together, however child objects typically refer to their parent object (via a member pointer) and might also be permitted to change their parent, but we wouldn't want to expose that pointer outside of the class, nor would we want to expose any mutators such as child::set_parent() outside of the class. But since the two classes are imlicitly bound to each other, we can declare specific methods of the parent class to be friends of the child class, such as parent::add_child(). In this way we can be sure that whenever we add a child to a parent, the parent not only attaches the child to itself, but also detaches the child from any existing parent beforehand. Far from undermining the encapsulation, this friendship reinforces it, assuring us that both classes are tightly bound.

The need for function overloading is to allow the same function call to accept different parameter types and/or a different number of parameters. The function signature differentiates the functions. The return type is also part of the signature, and needn't be the same for every overload.

Where the function signature is largely the same, with the same count of parameters but a different parameter type and return type, template functions can provide an alternative method of creating the function overloads. The compiler generates the necessary code for you, on an as-required basis, so you only need to write the function once, rather than once for each type.

There are essentially just two types of inheritance: single inheritance and multiple inheritance. Single inheritance simply means that one class derives directly from another class. Multiple inheritance means one class is directly derived from two or more classes.

However, since base classes can (and often are) be derived from other base classes, you can think of this type of inheritance as being multi-level. In addition, two or more base classes that share a common base class can use virtual inheritance. What this means is that the common base class becomes a direct base class of the most-derived class, and this one instance is shared, virtually, by all the base classes that would otherwise inherit directly from it. in other words, there is only one instance of the common base class, rather than one instance per class that inherits from it. This is useful in the so-called "dreaded diamond" formation, where a derived class inherits from two base classes, both of which inherit from a common base class.