C++ Programming

#include

#include

void main()

{

int rev num=0;

while(num>0)

{

rev num=rev num*10+num%10;

num=num%10;

}

return rev_num;

}

int main();

{

int num=4562;

printf("reverse of number is%d",reverse digit(num));

getch();

return o;

}

++a (plus plus a) is pre-incrementing operator to a
a=10;
printf("%d",++a); /* it will print 11 as ++a increment first a by 1 then prints it */

printf("%d",a++); /*it will printf 10 as it is post _ increment operator , it prints the value a first then increment it by 1 */

A function requires an include directive whenever it makes use of a data type or function that cannot be forward declared, or where a forward declaration would be undesirable, and where a complete declaration of that type or function exists in another file.

That may sound far more complex than intended, but it's really quite simple. The include directive is a signal to the compiler that the specified file is to be inserted into your file in its entirety, just as if you'd typed all the code it contains by hand. This is clearly a huge time saver when it comes to common data types and functions, but how do you decide if an include directive is actually required or not? Simple: comment out the directive and attempt to compile. If it fails, the directive is required. The errors raised will indicate exactly what types or functions it exposes and where they are used.

Most C/C++ programmers split their declarations from their definitions. Declarations of functions and data types (including class declarations) are usually placed in a header file (.h), while the definitions of the functions are safely tucked away in a separate source file (.cpp). Programmers are rarely interested in the implementations -- the header should contain all the information necessary to make use of the functions and data types contained therein. But in order to compile, the source file must include the header file. And if the two files must include other files, then we generally place those directives in the header file thus ensuring that the header contains all the necessary information to allow it to be included in other files.

Turbo C++ pre-dates the earliest C++ standard, ISO/IEC 14882:1998 (informally known as C++98). As such it is impossible to write standards-conforming C++ programs in Turbo C++. In particular, it lacks template metaprogramming and exception handling both of which are central to C++., and there is no standard template library because it didn't exist at the time. It's also 16-bit which limits its memory usage to 64KB, although DPMI can extend that limit to some degree.

Development of Turbo C++ effectively ceased in 1994. It was later revived in 2006 with two separate releases, Explorer (the free version) and Professional, but none of its inherent problems were resolved and no further development took place. Embarcadero acquired the software from Borland in 2008 and support was discontinued in 2009.

Today, the free version of Turbo C++ still finds uses in educational institutes (primarily in Asia) despite the fact it's of no practical use in learning C++ let alone writing C++ programs.

Turbo C++ was succeeded by C++ Builder. The current stable release is v10.1 Berlin, released in 2016.

Yes, you can use, and often you should, use more than one constructor in a class in C++.

Normally, there is a default constructor, a copy constructor, and one or more conversion constructors. Sometimes, there are also other constructors, overloaded based on argument signature, if there are complex situations.

You always should define default constructor for your class. You must also define a copy constructor for your class if there are any pointers in the class.

While it is not mandatory, failure to provide a default constructor can result in bad behavior, and failure to provide a copy constructor when you have pointers in the class will result in bad behavior.

For example, without a default constructor, the compiler will not fully initialize the attributes of the class. It will initialize the virtual function table, and call base class constructors, but that is all - the attributes could be random garbage.

For another example, without a copy constructor, the compiler will generate one that simply makes a bit wise copy of the attributes. If these attributes contain pointers, then you have two pointers to the same object, not necessarily a good thing, especially if one of them get "deleted".

You might as well compare apples and oranges. The only thing they have in common is that they are both base classes (just as apples and oranges are both fruit).

An abstract base class is an abstract data type (ADT). An ADT is defined as any class that declares one or more pure virtual functions. This prevents anyone from instantiating objects from the class other than through derivation. The derivative must implement all pure-virtual methods declared in its base class, otherwise it becomes an ADT itself. Once a derivative overrides a pure-virtual method, that method becomes virtual with respect to all subsequent derivatives. However, only derivatives that provide or inherit a complete implementation for the sum of all pure-virtual methods can physically be instantiated.

A virtual base class is a base class that is inherited virtually. That is, if class A is declared a virtual base class of class B, then any derivative of B will automatically inherit directly from A. This is useful in multiple inheritance where two or more intermediate classes are themselves derived from a common base class. Normally, the most-derived class will inherit one instance of the common base class from each of the intermediate base classes. By declaring the common base class to be virtual in the intermediate classes, the most-derived class inherits just one instance of the common base class, which is then shared amongst the intermediate classes.

Thus if class A inherits from classes B and C and they each inherit from D, then there will be two instances of D in the hierarchy (A::B::D and A::C::D). This introduces ambiguity when referring directly to A::D. But if B and C inherit from D virtually, then there is only one instance of D (A::D), and both B and C derive from this one, shared instance, virtually. This removes any ambiguity and reduces the overall footprint of the hierarchy by eliminating redundant instances of the shared base class.

Ideally, virtual base classes should have little or no data members.

No. Classes can only have one destructor, whether you define one yourself or allow the compiler to generate one for you. The compiler-generated destructor is public by default, does not release any memory allocated to any class' member pointers, and is non-virtual, which are the three main reasons for defining your own.

The assignment operator overload is a typical example of operator overloading. Every class of object has an assignment operator by default, which simply assigns the value of the members of an existing class to the members of another existing class. The two classes may even be the same class. However, the default implementation is not suitable for classes that contain pointers to memory that cannot be shared with other classes. Assigning the value of one pointer to another simply copies the pointer's value (a shallow copy) but not what it points at (a deep copy). Thus the assignment operator must be overloaded to perform a deep-copy, as per the following example:

struct X {

// destructor

~X(){ delete( m_pointer ); }

// default constructor

X(): m_pointer( new int(100) ){}

// copy constructor

X( const X& x): m_pointer( x.m_pointer ? new int( *x.m_pointer) : NULL ) {}

// assignment operator overload

X& operator= ( const X& x );

int* m_pointer;

};

X& X::operator= ( const X& x )

{

if( this != &x ) // test for self-reference

{delete( m_pointer );m_pointer = x.m_pointer ? new int(*x.m_pointer) : NULL;}

return( *this );

}

In the above example, the assignment operator overload first checks to ensure that the incoming object is not a self-reference. If it is not, then we release the current allocation and create a new allocation, copying the incoming object's memory by value. If we had not checked for a self-reference, then we could easily end up deleting the very memory we wished to copy, such as in the following example:

X x;

X* y = &x;

x = *y; // self-assignment

In the above example, x and *y are obviously references to the same object, but it may not be quite so obvious if the assignment occurred elsewhere in our code. Therefore the object's assignment operator overload must cater for this eventuality and veto the assignment -- thus leaving the original object unchanged.

The assignment operator can also be overloaded in order to prevent assignment. You would do this if the object were intended to act as a singleton, for instance. In this case we simply need to declare the operator as private to the class but do not need to provide any implementation. Alternatively, we can simply return a reference to the current instance:

X& operator= ( const X& x ) { return( *this ); }

No other operator has a default implementation when applied to classes, therefore if we want to make use of other operators upon our classes, such as +, ++ or +=, then we must overload them in the class declaration. Again, each overload must test for self-references and act accordingly. However, while there's nothing to prevent you from providing a completely unique implementation of these operators, common sense dictates that all such implementations must be intuitive and predictable. While it may be fun to implement the plus operator as a minus operation, it has no practical value in the real world -- it is neither intuitive nor predictable.

The stream insertion (<<) and extraction (>>) operators are another typical example of operator overloading. These cannot be implemented within the class itself because the l-value of these operators must be a stream, while internal class operator overloads use the current instance of the class as the l-value. Therefore these operators must be implemented outside of the class.

Many programmers implement these "external" operators as friend functions. While some do have valid reasons for doing so, if the public class interface provides everything required of these operators then there is no need to declare the operator as a friend function. Although some programmers continually claim friendship undermines encapsulation this is not the case at all. Friends simply extend the class interface, nothing more. However, if the underlying class implementation is altered, all friend functions may need to be updated to cater for these changes -- which increases the maintenance cost. Therefore, if operator overloads can be implemented with friend access, then your class becomes that much easier to maintain.

Here's a typical example of an external operator implemented as a friend function:

struc X

{

friend ostream& operator<<( const X& x );

private:

int m_data;

};

ostream& operator<<( ostream& os, const X& x )

{

os << x.m_data;

return( os );

}

Now here's the same operator overload implemented without a friend function:

struc X

{

int GetData() const { return( m_data ); }

private:

int m_data;

};

ostream& operator<<( ostream& os, const X& x )

{

os << x.GetData();

return( os );

}

While there's clearly the need for an extra function call, that call is completely eliminated by virtue of the fact X::GetData() will be inline expanded by the compiler. Thus the latter will not affect performance in any way. However, the main advantage of the non-friend function comes when you later decide to alter the implementation of the class:

struc X

{

int GetData() const { return(( int ) m_data ); }

private:

double m_data;

};

Here we've changed the member variable to a double, but the GetData() accessor method still returns an int. The accessor is therefore an abstraction, thus the insertion operator overload is left unaffected by the internal change to the class. However, had we made this same change in the earlier example employing the friend function, there is no abstraction and the extraction operator will insert a double into the output stream. If this were undesirable then we'd have to alter the friend function as well. Not only have we increased the maintenance, we've completely undermined the abstraction of our class. Note that we have not undermined the encapsulation (as some would claim), only the abstraction has been undermined. Thus if you want to retain the abstraction, do not use a friend function. Friend functions should only be used when abstraction is not an issue, and the function genuinely requires access to the private members of the class.

C++ doesn't have versions, it has standards. The implementations of those standards have versions, but the version numbering differs from one implementation to another. The current standard (as of 6th February 2017) is ISO/IEC 14882:2014.

Macros are not actually part of the C++ language; they are nothing more than a simple text-replacement system intended to simplify your coding. Macros do not adhere to C++ type safety and cannot be debugged because macros are preprocessed, prior to compilation. Your compiler can only see the preprocessed code, not the original source code, and therefore cannot debug macros because the macros no longer exist at that point.

Inline functions are functions that can be debugged like any other function, but the compiler is able to eliminate the overhead of function calla by replacing those calls with inline expanded code. This is not unlike a macro, which is by definition inline expanded, but retains the built-in type safety and debugging capabilities of the C++ language itself.

Typically, if you can use an inline function (or C++ is general) then that is always the preferred option. But if a macro can achieve more than can be achieved with C++ alone, or can otherwise simplify the equivalent C++ code, then use a macro. Just keep in mind that macros are not type-safe and cannot be debugged by the C++ compiler.

Your question is unclear. C++ IS a programming language. SQL is not (it is a specialized language for defining relational databases, inserting/retrieving/modifying data and specifying user access.)

CODING

Implementation

Repeat until loops run until a condition is true. They repeat at the end of the loop and they will always run at least once.

While do loops will only run while a condition is true. They may not run at all.

The most optimal form is as follows:

void bubble_sort( int* arr, size_t len )

{

do{

int n = 0; // used to record the last swap position

for( int i=1; i<len; ++i )

{

if( arr[i-1]>arr[i] )

{

// swap without a temporary...

arr[i-1]^=arr[i]^=arr[i-1]^=arr[i];

n = i;

}

}

len = n;

} while( len );

}

Note that while this form is the most optimal, nobody ever uses bubble sort in the real world, even for small sets of data (which is all it can really handle). Indeed, it has very little value even in the classroom. Its only true value is that it is an example of how not to write an algorithm. Insertion sort is a much better algorithm and is every bit as efficient, just as simple to understand and, paradoxically, much simpler to implement. It can even be used to sort smaller subsets of a much larger subset when combined with the more complex quicksort, heap sort or merge sort.

Static member variables are local to the class. That is, there is only one instance of a static member variable, regardless of how many objects are instantiated from the class. As such, they must be declared inside the class, and defined outside of the class.

Because when have varialbles var1 and Var1, they are actually different variables. The same ides with operators, data and so on .

#include

using std::cout;

int main()
{
int a = 0;
while (a != 11) //While a does not equal 11
{
a++; //add 1 to a
cout << a << "\n"; //print a and add newline
}
cout<<"The loop has ended";
return 0;
}

void Decimal_to_Octal()
{
int n,r[10],i;
cout<<"Enter a number to find it's octal equivalent";
cin>>n;
cout<<"The octal equivalent of "<for(i=0;n!=0;i++)
{
r[i]=n%8;
n=n/8;
}
i--;
for(;i>=0;i--)
cout<count<}

Abstraction is a process by which higher concepts are derived from the usage and classification of literal ("real" or "concrete") concepts, first principles and/or other abstractions.

Graphic chars have nothing whatsoever to do with C++. Graphic chars are better known as ASCII box-drawing characters. They first appeared in the extended ASCII character set of the original IBM PC (now referred to as code page 437), long before C++ was conceived. The extended ASCII character set varies according to which code page is currently active. UNICODE contains the full range of 128 box-drawing characters (from U+2500 to U+257F, inclusive) including all variants of the single-line, double-line and single/double hybrid characters, as well us quarter-arcs (for rounded corners) and diagonals. The extended ASCII character sets contain a small subset of the UNICODE range. Code page 437 provides the largest subset with 40 characters and is the preferred code page for all ASCII box-drawing. Code page 850 reduces the subset to just 22 by eliminating the hybrid characters and should generally be avoided. If you must use box-drawing characters, prefer UNICODE or UTF encodings over the ASCII encodings. They are typically only required within plain-text files or when printing such files to a console/terminal.

Note that the entire C++ programming language is represented using only the standard 7-bit ASCII character set (characters 0x00 through 0x7F) as specified in ISO-8559-1. The extended ASCII character sets play no part in any C++ standard (the high-order bit in all 8-bit encodings is always zero). Although you may include literal box-drawing characters within C-style strings and all std::string types, it's best to use UNICODE or UTF encodings because the literal characters cannot be interpreted consistently across all systems.