C++ Syntax Interview Preparation Guide

New Data types:
- bool
- wchar_t

New operators
- const_cast
- static_cast
- dynamic_cast
- reinterpret_cast
- typeid

Class implementation
- Explicit constructors
- Mutable members

Namespace scope
Operator keywords
New keywords
New headers

Following table is with respect to a 16-bit word machine:

Type Bytes Range
char 1 -128 to 127
unsigned char 1 0 to 255
signed char 1 -128 to 127
int 2 -32768 to 32767
unsigned int 2 0 to 65535
signed int 2 2 -32768 to 32767
short int 2 2 -32768 to 32767
unsigned short int 2 0 to 65535
signed short int 2 -32768 to 32767
long int 4 4 -2147483648 to 2147483647
signed long int 4 -2147483648 to 2147483647
unsigned long int 4 0 to 4294967295
float 4 4 3.4E-38 to 3.4E+38
double 8 8 1.7E-308 to 1.7E+308
long double 10 3.4E-4932 to 1.1E+4932

C++ extends the variable declaration syntax from built-in types (e.g., int
i;) to objects of user-defined types. The syntax is the same: TypeName VariableName.
For example, if the header file “Car.hpp” defines a user-defined type called Car,
objects (variables) of class (type) Car can be created:
#include "Car.hpp" // Define class Car
void f()
{
Car a; // 1: Create an object
a.startEngine(); // 2: Call a member function
a.tuneRadioTo("AM", 770); // 3: Call another member function
} // 4. Destroy the object
int main()
{
f();
}
When control flows over the line labeled 1: Create an object, the runtime
system creates a local (auto) object of class Car. The object is called a and can
be accessed from the point where it is created to the } labeled 4: Destroy the
object.
When control flows over the line labeled 2: Call a member function, the
startEngine() member function (a.k.a. method) is called for object a. The
compiler knows that a is of class Car so there is no need to indicate that the
proper startEngine() member function is the one from the Car class. For
example, there could be other classes that also have a startEngine() member
function (Airplane, LawnMower, and so on), but the compiler will never get
confused and call a member function from the wrong class.

Unnecessary complexity — the plague of OO technology.
Complexity, like risk, is a fact of life that can’t be avoided. Some software
systems have to be complex because the business processes they represent are
complex. But unfortunately many intermediate developers try to “make things
better” by adding generalization and flexibility that no one has asked for or will
ever need. The customer wants a cup of tea, and the developers build a system
that can boil the ocean [thanks to John Vlissides for this quip]. The result
is unnecessary complexity, which increases the risk of failure. The intentions
might be good but the result can be deadly.
Here are a few guidelines.
• Don’t solve problems that don’t need to be solved.
• Don’t worry about the future until you’re sure you can survive the present.
39
• Don’t build things for the fun of it.
• The organization’s health is more important than the developer’s desire
to play with the latest whiz-bang tool or technique.
• Don’t add risk without a compelling and measurable benefit to the project.
• Don’t invest in the future if your current project is in trouble.
Avoid the “death by one thousands cut” syndrome by avoiding unnecessary
complexity.

The Software Peter Principle is in operation when unwise developers “improve” and “generalize” the software until they themselves can no longer understand it, then the project slowly dies.
The Software Peter Principle can ruin projects. The insidious thing about the Software Peter Principle is that it’s a silent killer — by the time the symptoms are visible, the problem has spread throughout every line of code in the project.
Foolish managers deal with symptoms rather than prevention, and they think
everything is okay unless there are visible bugs. Yet the problem isn’t bugs, at least initially. The problem is that the project is collapsing under its own weight.
The best way to avoid this problem is to build to the skill level of the maintainers, not of the developers. If the typical maintainer won’t understand the software then it’s simply too complex for the organization to maintain. This means avoiding tricky, sophisticated, subtle, clever techniques unless there is a compelling reason for them. Cleverness is evil; use it only when necessary.
Shown concern for the long-term health of the system being developed.

Whichever one works best for the organization.
We believe in honesty, not advocacy, and the honest answer is that there
is no single answer. What is the organization’s policy regarding languages?
Must there be one and only one official language? What is the skill level of
the staff? Are they gung-ho developers with advanced degrees in computer
science/engineering or people who understand the business and have survival
skills in software? Do they already have OO skills? In which language(s)? What
sort of software development is being done: extending someone else’s framework
or building from scratch for resale? What sort of performance constraints does
the software have? Is it space constrained or speed constrained? If speed, is it
typically bound by I/O, network, or CPU? Regarding libraries and tools, are
there licensing considerations? Are there strategic partnership relationships that
affect the choice of languages? Many of these questions are nontechnical, but
they are the kind of questions that need to be answered the “which language”
issue can be addressed.
Regarding the choice between C++ and Java, java is a simpler language and
thus it is generally easier to use. However C++ is more established and allows
finer control over resources (for example, memory management), and this is required
for some applications. Also, C++ has language features such as destructors

i want to say Global scope(int i = 111;),Local scope (int i = 333;), and function scope (int i = 222;) but now, i\'m confused. I really don\'t understand what is this question asking me. Can somebody help me break it down

for( unsigned int i = 1; i < = 100; i++ )
if( i & 0x00000001 )
cout << i << ",";

To declare a variable you use the syntax "type <name>". Here are some variable declaration examples:
1- int x;
2- char letter;
3- float the_float;
It is permissible to declare multiple variables of the same type on the same line; each one should be separated by a comma.
1- int a, b, c, d;
If you were watching closely, you might have seen that declaration of a variable is always followed by a semicolon (note that this is the same procedure used when you call a function).</name>

Here is a sample program demonstrating the use of a variable:

#include <iostream>

using namespace std;

int main()
{
int thisisanumber;

cout<<"Please enter a number: ";
cin>> thisisanumber;
cin.ignore();
cout<<"You entered: "<< thisisanumber <<"n";
cin.get();
}</iostream>