CareerCup

pointer vs reference
----------------------
when using pointers, the address must be dereferenced using the *, whereas,when using references, the address is dereferenced without using any operators at all!

The main effect of this is that the address can directly be manipulated if it is a pointer.We can do things such as: pi++;
to increment to the next address. This is not possible using references. Therefore, to summarize, a pointer can point to many different objects during its lifetime, a reference can refer to only one object during its lifetime.

References are the preferred way of indirectly accessing a variable. They are also a little
safer than pointers and, in some cases, are the only way to achieve a particular result such
as overloading certain operators. Consider the following:
enum day
{
Sunday, Monday, ...
};
If we define a variable;
day x;
pi
i
ri
addr
addr addr
and we wanted to write a method to overload the ++ operator such that the statement
++x;
increments x to the next day, we could write the following:
day &operator++(day &d)
{
d = (day)(d + 1);
return d;
}
Using pointers, we may think that the following declaration would work:
day *operator++(day *d);
However, this statement will not even compile because every overloaded operator function must either be a member of a class, or have a parameter of type T, T &, or T const &, where T is a class or enumeration type. So in this particular case, using a reference is the only way to do it.

Copy Constructor
------------------------


When copies of objects are made
A copy constructor is called whenever a new variable is created from an object. This happens in the following cases (but not in assignment).

A variable is declared which is initialized from another object, eg,

Person q("Mickey"); // constructor is used to build q.
Person r(p);        // copy constructor is used to build r.
Person p = q;       // copy constructor is used to initialize in declaration.
p = q;              // Assignment operator, no constructor or copy constructor.A value parameter is initialized from its corresponding argument. 
f(p);               // copy constructor initializes formal value parameter.An object is returned by a function.

C++ calls a copy constructor to make a copy of an object in each of the above cases. If there is no copy constructor defined for the class, C++ uses the default copy constructor which copies each field, ie, makes a shallow copy.

Don't write a copy constructor if shallow copies are ok
If the object has no pointers to dynamically allocated memory, a shallow copy is probably sufficient. Therefore the default copy constructor, default assignment operator, and default destructor are ok and you don't need to write your own.

If you need a copy constructor, you also need a destructor and operator=
If you need a copy constructor, it's because you need something like a deep copy, or some other management of resources. Thus is is almost certain that you will need a destructor and override the assignment operator.

2)

Copy constructor is
a constructor function with the same name as the class
used to make deep copy of objects.
There are 3 important places where a copy constructor is called.

When an object is created from another object of the same type
When an object is passed by value as a parameter to a function
When an object is returned from a function
If a copy constructor is not defined in a class, the compiler itself defines one. This will ensure a shallow copy. If the class does not have pointer variables with dynamically allocated memory, then one need not worry about defining a copy constructor. It can be left to the compiler's discretion.

But if the class has pointer variables and has some dynamic memory allocations, then it is a must to have a copy constructor.





--------------------------------------------------------------------------------
For ex:

class A   //Without copy constructor
      {
           private:
           int x;
           public:
           A() {A = 10;}
           ~A() {}
      }

--------------------------------------------------------------------------------

class B    //With copy constructor
      {
           private:
           char *name;
           public:
           B()
           {
           name = new char[20];
           }
           ~B()
           {
           delete name[];
           }
     //Copy constructor
           B(const B &b)
           {
           name = new char[20];
           strcpy(name, b.name);
           }
      };

--------------------------------------------------------------------------------

Let us Imagine if you don't have a copy constructor for the class B. At the first place, if an object is created from some existing object, we cannot be sure that the memory is allocated. Also, if the memory is deleted in destructor, the delete operator might be called twice for the same memory location.

virtual destructors
------------------------


void function()
{
Sample* p = new Derived;
delete p;
}
Since Sample does not have a virtual destructor, the delete p invokes the destructor of the class of the pointer (Sample::~Sample()), rather than the destructor of the most derived type (Derived::~Derived()). And as you can see, this is the wrong thing to do in the above scenario.

Armed with this information, you can now answer the question.

A class must have a virtual destructor if it meets both of the following criteria:

You do a delete p.
It is possible that p actually points to a derived class.

Should Pointers always be initialized?


Notice that in the above example, pointer is initialized to point to a specific memory address before it is used. If this was not the case, it could be pointing to anything. This can lead to extremely unpleasant consequences to the program. For instance, the operating system will probably prevent you from accessing memory that it knows your program doesn't own: this will cause your program to crash. If it let you use the memory, you could mess with the memory of any running program--for instance, if you had a document opened in Word, you could change the text! Fortunately, Windows and other modern operating systems will stop you from accessing that memory and cause your program to crash. To avoid crashing your program, you should always initialize pointers before you use them.

Race Condition :
-----------------------

A race condition occurs when multiple processes access and manipulate the same data concurrently, and the outcome of the execution depends on the particular order in which the access takes place.

A race condition is of interest to a hacker when the race condition can be utilized to gain privileged system access.

Consider the following code snippet which illustrates a race condition:

if(access("/tmp/datafile",R_OK)==0){
	fd=open("/tmp/datafile
        process(fd);
        close(fd);

This code creates the temporary file /tmp/datafile and then opens it.

The potential race condition occurs between the call to access() and the call to open().

If an attacker can replace the contents of /tmp/datafile between the access() and open() functions, he can manipulate the actions of the program which uses that datafile. This is the race.

It can be difficult to exploit a race condition, because you may have to "run the race" many times before you "win." You may have to run the vulnerable program and the vulnerability testing tool thousands of times before you get the expolit code to execute after the vulnerability opens and before the vulnerability closes. It is sometimes possible to give the attack an extra edge by using `nice` to lower the priority of the legitimate suid program.

Improper use of the function calls access(), chown(), chgrp(), chmod(), mktemp(), tempnam(), tmpfile(), and tmpnam() are the normal causes of a race condition.

Process V/S threads:
----------------------------

Both threads and processes are methods of parallelizing an application. However, processes are independent execution units that contain their own state information, use their own address spaces, and only interact with each other via interprocess communication mechanisms (generally managed by the operating system). Applications are typically divided into processes during the design phase, and a master process explicitly spawns sub-processes when it makes sense to logically separate significant application functionality. Processes, in other words, are an architectural construct.

By contrast, a thread is a coding construct that doesn't affect the architecture of an application. A single process might contains multiple threads; all threads within a process share the same state and same memory space, and can communicate with each other directly, because they share the same variables.

Threads typically are spawned for a short-term benefit that is usually visualized as a serial task, but which doesn't have to be performed in a linear manner (such as performing a complex mathematical computation using parallelism, or initializing a large matrix), and then are absorbed when no longer required. The scope of a thread is within a specific code module—which is why we can bolt-on threading without affecting the broader application.


Processes
– Inter-process communication is expensive: need to
context switch
– Secure: one process cannot corrupt another process

• Threads
– Inter-thread communication cheap: can use process
memory and may not need to context switch
– Not secure: a thread can write the memory used by
another thread

Thread safe functions:
---------------------------


In C language, local variables are dynamically allocated on the stack. Therefore, any function that does not use static data or other shared resources is trivially thread-safe, as in the following example:

/* thread-safe function */
int diff(int x, int y)
{
        int delta;

        delta = y - x;
        if (delta < 0)
                delta = -delta;

        return delta;
}

The use of global data is thread-unsafe. Global data should be maintained per thread or encapsulated, so that its access can be serialized.

Symbolic links:
-----------------


A symbolic link, also termed a soft link, is a special kind of file that points to another file, much like a shortcut in Windows or a Macintosh alias. Unlike a hard link, a symbolic link does not contain the data in the target file. It simply points to another entry somewhere in the file system. This difference gives symbolic links certain qualities that hard links do not have, such as the ability to link to directories, or to files on remote computers networked through NFS. Also, when you delete a target file, symbolic links to that file become unusable, whereas hard links preserve the contents of the file.

To create a symbolic link in Unix, at the Unix prompt, enter the following command:
ln -s source_file myfile Replace source_file with the name of the existing file for which you want to create the symbolic link (this file can be any existing file or directory across the file systems). Replace myfile with the name of the symbolic link. The ln command then creates the symbolic link. After you've made the symbolic link, you can perform an operation on or execute myfile, just as you could with the source_file. You can use normal file management commands (e.g., cp, rm) on the symbolic link.

Note: If you delete the source file or move it to a different location, your symbolic file will not function properly. You should either delete or move it. If you try to use it for other purposes (e.g., if you try to edit or execute it), the system will send a "file nonexistent" message.


How it works:

Early implementations of symbolic links would store the symbolic link information in standard disk blocks, much like regular files. The file contained the textual reference to the link’s target, and an indicator denoting it as a symbolic link.

This arrangement proved somewhat slow, and could waste disk-space on small systems. An innovation called fast symlinks allowed storage of the link-text within the standard data structures used for storing file information on disk (inodes). This space generally serves to store the chain of disk blocks composing a file (60 bytes on the Unix File System). This simply means that users can reference shorter symbolic links quickly. Systems with fast symlinks often fall back to using the older method if the path and filename stored in symlink exceeds the available space in the inode, or for disk compatibility with other or older versions of the operating system. The original style has become retroactively termed slow symlinks.

Although storing the link value inside the inode saves a disk block and a disk read, the operating system still needs to parse the pathname information in the link, which always requires reading an additional inode and generally requires reading other — potentially many — directories, processing both the list of files and the inodes of each of them until it finds a match with the link pathname components. Only when a link points to a file inside the same directory do fast symlinks provide significant gains in performance.

Vector vs Arrays:
-------------------


A vector, as hinted above, is a rescaleable array. This is a data structure where all of the functions to resize when elements are added are already built in so that the programmer does not have to worry about them. Luckily, Java has Vector as a datatype for us to use. Another thing that vectors can do that arrays can not is hold multiple datatypes within one structure. A vector's first element can be a character and it's second can be an int. There is no type definition needed. To declare a Vector, we do it the same way as normal objects.
Vector example = new Vector();

If we declare the Vector in this way, all of its elements will be Objects that can be of whatever type we want. You will have to cast the objects when you retrieve them from the vector to use them in different ways (no fun). If you know before hand that you want your vector to hold only strings or ints or another datatype, you can declare a templated vector like this.
Vector<String> example = new Vector<String>(); Vector<Integer> example = new Vector<Integer>();

Now, if we want to add the word "bob" to the end of our vector, we simply use the add() function.

example.add("bob");

Java Coder, I guess you are a fucking idiot ...

lol, all java coders are

Yes, initializing a pointer will allow you to safely do a check like:

if(stringPtr) { doSomething(); }

If you forget to initialize it to 0/nullptr then this check will succeed accidentally-- it will be pointing at some random part of memory!