C++ Programming

If you mean the original name of C++, it was originally called "C with Classes". However, after the introduction of template metaprogramming, it was renamed C++ which meant "the successor to C".

Yes. Children can be born with them if they have parents who are infected, and they can be transmitted through fluids through other means.

Well done to the student in question but what exactly is your question?

Overload extraction is a meaningless term. However you don't need overloaded functions for this.

class PhoneCall {

std::string _phone_no;

unsigned _duration; // in minutes

double _rpm; // rate per minute

public:

PhoneCall (std::string, unsigned, double); PhoneCall (const PhoneCall&) = default;

PhoneCall (PhoneCall&&) = default;

PhoneCall& operator= (const PhoneCall&) = default;

PhoneCall& operator= (PhoneCall&&) = default;

~PhoneCall (void) = default;

};

PhoneCall::PhoneCall (const std::string& phone_no, const unsigned duration, const double rpm):

_phone_no {phone_no}, _duration {duration}, _rpm {rpm}

{}

Usage:

std::vector<PhoneCall> calls;

v.push_back ({"01315554284", 6, 0.10}); // 6-minute call at 10p per minute

v.push_back ({"01315554292", 5, 0.15}); // 5-minute call at 15p per minute

A vector is a class template that encapsulates a dynamic array along with its current size, treating both as a single entity. Since the allocated memory and its size are kept in sync internally by the vector, there is no need to manually keep track of the array size or the memory allocation as you would with a C-style array. This makes it much easier to work with arrays in C++.

To understand the difference, consider the following:

#include<iostream>

#include<vector>

int main()

{

unsigned int i;

std::cout<<"C-style array:\n"<<std::endl;

unsigned int size=10;

int* a=(int*)malloc(size*sizeof(int));

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

a[i]=i*2;

++size;

a = (int*)realloc(a,size*sizeof(int));

a[size-1]=42;

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

std::cout<<a[i]<<std::endl;

free(a);

a=NULL;

std::cout<<"\nC++ vector:\n"<<std::endl;

std::vector<int> v (10);

for(i=0; i<v.size(); ++i)

v[i]=i*2;

v.push_back(42);

for(i=0; i<v.size(); ++i)

std::cout<<v[i]<<std::endl;

}

With the C-style array, we must keep track of the size separately from the array. Thus when we reallocate to accommodate the new element (42), we must increase the size accordingly. The equivalent C++ code is much simpler because the size is updated internally by the vector itself, and we don't need to worry about the memory allocation. When the vector falls from scope, the memory is freed automatically. Note how we can use the subscript operator [] to access the individual elements of the vector just as we would with a C-style array.

As well as encapsulating the array and its size as a single entity, vectors provide member methods to make it easier to work with the array. In the above example we used the vector::push_back method to add the new element (42) to the end of the array. We can also extract elements from the end of the array using the vector::pop_back() method. Thus a vector can emulate a stack structure (last-in, first-out). However, keep in mind that just as arrays are unsuitable for stacks due to the reallocations required to keep the memory contiguous, the same is true of vectors. the reallocations may be hidden from you but they still occur in the background. However, anywhere you would normally use a dynamic array, a vector can be used instead.

Another advantage of vectors over arrays is when passing arrays to functions. Normally, the function will expect a reference to the array along with the number of elements in the array. Since vectors encapsulate the size you need only pass a reference to the vector itself. Although you could overload the function to accept either a vector or an array, given the simpler nature of a vector it is better to avoid dynamic arrays altogether. Static arrays are usually fine for small allocations on the stack, but you can also use vectors for larger static arrays on the heap. The array is actually dynamic, of course, but if you don't change the size then it is effectively static. The only real difference is that the allocation is on the heap rather than the stack.

Static variables are allocated upon the stack and exist from compile time. Dynamic variables are created on the heap and only exist at runtime. Since the stack exists within the program's data segment, the more static variables you declare the larger your executable needs to be to cater for them. For that reason it's best to keep static variables to a minimum. Large and complex structures are best allocated dynamically, particularly if the size of the structure is not of fixed size. The heap is effectively unlimited* in size thus can easily accommodate extremely large structures as and when they are required, destroying them when they are no longer needed, rather than keeping them in memory at all times.

*32-bit systems have a maximum limit of 4GB virtual memory (including the paging file), which includes graphics card memory and peripheral memory, all of which must be mapped within the 4GB address space (thus reducing available memory accordingly). 64-bit systems have no such limitations and will use as much virtual memory (disk space) as is required to meet memory requirements. Although there is effectively no limit to the amount of physical memory that can be addressed, 64-bit systems still have an upper limit due to physical constraints. Indeed, there isn't enough RAM in the world to fill just one 64-bit system to its maximum capacity, never mind all of them.

A class is a type. Classes don't do anything except define the type. You have to instantiate an object of the type in order to actually do anything, including initialising data members. However, the class can define how a data member is initialised. The most efficient method of initialising class members if via the class constructor initialisation list.

You cannot arbitrarily determine what is passed to a function from outside of the function. If the function expects a reference, then the memory address of the variable will be automatically passed to the function. If the function expects a value, then a copy of the variable's value is automatically passed instead. In other words, it is the function signature that determines what is passed, not how you call the function.

No. Return statements can only appear within a function body, but they can be placed anywhere within that body. If the function returns a value, then the return statement must also return a value of the same type.

To derive a new class from an existing class, your new class must inherit from the existing class. This is achieved in the declaration of the class:

class oldclass{};
class newclass : public oldclass {};

In the above example, newclass inherits publicly from oldclass. What this means is that the public and protected members of oldclass are public and protected members of newclass. If you specify protected inheritance, the public members of oldclass become protected members of newclass. If you specify private inheritance, the public and protected members of oldclass become private members of newclass. Regardless of the type of inheritance specified at this point, you can still override the access of individually inherited members. In most cases you will use public inheritance unless there is a specific need to alter access rights to the base class members. Note that this does not affect the base class itself; only objects derived from the base class are affected.

Having inherited the base class and all its public and protected members, you can then override the base class behaviour to provide more specific methods and data members for your derivative. However, note that only virtual methods are expected to be overridden. If you override a non-virtual method, you will effectively hide the base class method along with any and all overloads of that method. Thus it is important to ensure the base class has a virtual destructor. If it doesn't, this will only lead to problems when your derived class falls from scope because derived classes must be destroyed in sequence, from the most-derived to the least-derived. This can only be achieved when all destructors other than the most-derived destructor are declared virtual.

It should also be noted that there's no point in having a base class with no virtual methods other than the destructor. The only reason for having a virtual destructor in the first place is because the base class has one or more virtual methods.

Abstract base classes are similar to normal classes except they also contain one or more pure-virtual methods. This means that you must provide an implementation for all the pure-virtual methods inherited from the base class (with normal virtual methods, overriding is optional) otherwise your derivative becomes an abstract base class itself. However, derived classes can inherit implementations of pure-virtual methods from other intermediate base classes, other than the one that initially declared the method pure-virtual, which itself may or may not provide an implementation.

It's often the case that, where an implementation is provided by a base class virtual method, you are expected to call that method from your derived class override. However some implementations may be expected to be completely overridden. The documentation for the base class will determine if and when to call the base class implementation.

In some cases, you may wish to derive a class from two or more base classes, known as multiple inheritance. To do so, you simply provide a comma-separated list, like so:

class base1{};
class base2{};
class derived : public base1, public base2 {};

When you combine multiple inheritance with multi-level inheritance, be aware that this may result in two or more instances of a common base class:

class base {};
class inter1 : public base {};
class inter2 : public base {};
class derived : public inter1, inter2 {};

This creates an ambiguity because derived inherits two separate instances of base, one from inter1 and the other from inter2. There are various ways to remove the ambiguity, however the preferred method is to make base a virtual base class, like so:


class base {};
class inter1 : virtual public base {};
class inter2 : public virtual base {};
class derived : public inter1, inter2 {};

Note that the virtual keyword can be placed before or after the inheritance specifier, it makes no difference. Now derived will inherit directly from base, and that one instance is shared with both inter1 and inter2. There may still be ambiguity where both inter1 and inter2 override the same virtual method of base, but this can be easily dealt with by providing a more specific override in the derived class.

You do nothing!

A sequence of numbers will contain no X and so nothing needs doing!

They both do pretty much the same thing: they both generate code. However, macros are not type-safe, they aren't even type-aware. So if a function body has to generate a type from its argument, then you cannot use a macro, you must use a template. Even if that is not an issue, the lack of type-safety is a major drawback in a strongly-typed language like C++. Remember, macros are not part of the language itself, they simply exist to augment the language by providing simple text replacements, ultimately making code easier to read and understand. Using them in place of function or class templates is never a good idea no matter how simple the function or class. A bit of extra typing can save a mountain of headaches.

The biggest problem with macros (besides their lack of type awareness) is that they are extremely difficult to debug because they are inline expanded by the preprocessor. This means that if the compiler detects and error, it can only do so in the expanded code which simply doesn't exist in your source code. This also means you cannot set breakpoints in a macro because the macro won't physically exist in the preprocessed code.

Macros can be used to generate any code except the definition of another macro. This can be extremely useful and is extremely powerful when used appropriately. However, templates can only generate explicit dynamic data types and explicit function overloads. A macro that merely emulates a template is therefore not a particularly useful macro, it is an abhorrent abuse of the language and its compiler. The compiler is there to help you so you are encouraged to enlist it as much as possible.

The min/max macros are often quoted as being simpler and easier to use and understand than their equivalent template functions. However, they actually demonstrate why macro functions are so bad in the first place. Calling max(++a, b++) will quickly dispel any myths about macros being easier to work with.

Macros completely ignore namespaces and scope, which can result in name clashes that will produce some really funky code. By contrast, templates are fully namespace and scope aware.

Outline is the opposite of inline. An inline expanded function is any function or class method where the declaration also provides the definition (the implementation). This is known as implicit inline expansion. Where the definition is kept separate from the declaration, you may use the inline keyword to specifiy that the function should be inline. This is known as explicit inline expansion.

Inline expanded functions (whether implied or explicit) does NOT mean the function will in fact be inline expanded. It is merely a suggestion to the compiler. If the compiler's optimisers determine that there is no advantage to be gained by inline expanding a particular function, then that function becomes an outline function.

Inline expansion simply means that the body of the function is inserted in place of the function call. Function calls are expensive in terms of memory and performance, so by eliminating the function call completely, your code performs faster and uses less memory. However, functions that are called many times throughout your code will result in a much larger code size, and large code runs slower than small code. Thus the benefit of eliminating a function call has to be weighed against the increased code size. Although some compilers do allow you to override the compiler's inline expansion optimisers, this is strictly non-standard. The best judge of what to expand and what not to expand is best left in the hands of the compiler, and indiscriminate use of the inline keyword should generally be avoided.

Inheritance allows a new class to automatically pick up all the protected and public data and methods of an existing class. To do so, the new class must be derived from the existing class. Private data and methods remain private to the existing class, the base class.

Use the median-of-three algorithm:

int min (int a, int b) { return a<b?a:b; }

int max (int a, int b) { return a<b?b:a; }

int median_of_three (int a, int b, int c) { return max (min (a, b), min (max (a, b), c)); }

Note that the algorithm does not cater for equal values which creates a problem when any two values are equal, because there are only two values to play with, neither of which can be regarded as being the middle value. If the equal value is the lower of the two values, the largest value is returned if and only if it is the last of the three values, otherwise the lowest value is returned. But when the equal value is the larger of the two values, the largest value is always returned.

Lowest value is equal:

Input: 0, 0, 1 = max (min (0, 0), min (max (0, 0), 1)) = max (0, min (0, 1)) = max (0, 1) = 1

Input: 0, 1, 0 = max (min (0, 1), min (max (0, 1), 0)) = max (0, min (1, 0)) = max (0, 0) = 0

Input: 1, 0, 0 = max (min (1, 0), min (max (1, 0), 0)) = max (0, min (1, 0)) = max (0, 0) = 0

Highest value is equal:

Input: 0, 1, 1 = max (min (0, 1), min (max (0, 1), 1)) = max (0, min (1, 1)) = max (0, 1) = 1

Input: 1, 0, 1 = max (min (1, 0), min (max (1, 0), 1)) = max (0, min (1, 1)) = max (0, 1) = 1

Input: 1, 1, 0 = max (min (1, 1), min (max (1, 1), 0)) = max (1, min (1, 0)) = max (1, 0) = 1

The only way to resolve this problem and produce a consistent result is to sum all three inputs then subtract the minimum and maximum values:

int median_of_three (int a, int b, int c) { return a + b + c - min (min (a, b), c) - max (max (a, b), c)); }

Lowest value is equal:

Input: 0, 0, 1 = 0 + 0 + 1 - min (min (0, 0), 1) - max (max (0, 0), 1) = 1 - 0 - 1 = 0

Input: 0, 1, 0 = 0 + 1 + 0 - min (min (0, 1), 0) - max (max (0, 1), 0) = 1 - 0 - 1 = 0

Input: 1, 0, 0 = 1 + 0 + 0 - min (min (1, 0), 0) - max (max (1, 0), 0) = 1 - 0 - 1 = 0

Highest value is equal:

Input: 0, 1, 1 = 0 + 1 + 1 - min (min (0, 1), 1) - max (max (0, 1), 1) = 2 - 0 - 1 = 1

Input: 1, 0, 1 = 1 + 0 + 1 - min (min (1, 0), 1) - max (max (1, 0), 1) = 2 - 0 - 1 = 1

Input: 1, 1, 0 = 1 + 1 + 0 - min (min (1, 1), 0) - max (max (1, 1), 0) = 2 - 0 - 1 = 1

This makes sense because when we sort 0, 0, 1 in ascending order, 0 is in the middle, while 0, 1, 1 puts 1 in the middle.

C and C++ do it for ease of parsing. This way, when they hit a comment start of /*, the parser can trivially scan to the end. Otherwise, it would have to set up and maintain a stack, and then report errors if the comment tokens are unmatched.

As to why Java does it, the answer is simple - Java's syntax was designed to emulate C and C++, to trick people into thinking it was just as fast (in the beginning, Java was purely interpreted, so this trick WAS necessary to get traction). If nested comments were allowed, it might trip up some C programmers, and many angry blog posts would be written!

A priority queue not only requires insertion of a new element at the end of the queue, but may require insertion at the head or somewhere in the middle, subject to the priority of the new item.

This can be implemented efficiently using a list, but would generally require more expensive operations when implemented using an array, such as moving existing elements of lower priorities "one down" to make room for the new element.

Having said that, many other implementations of priority queues are possible, which might be perfectly suited for implementation with an array. For example, if the number of different priority levels is finite and small (three levels for low, middle and high, for example), one might consider implementing three queues instead, one for each priority level. This would allow for efficient implementation with statically allocated and sized arrays, which is often the preferred approach in embedded programming.

The semi-colon converts a C++ expression into a statement.

To delete an array element you must create a new array with one less element, then traverse both arrays, copying elements from one to the other, but skipping over the element you want to delete. Once all elements are copied, you can release the original array. A slightly more efficient method would be to move the empty element to the end of the array and then re-allocate the entire array with one less element, using the realloc() command.

To insert a new element, create a new array with one additional element. Then traverse both arrays, copying elements from one to the other. The original array can then be deleted, and the new data can be placed at the end of the new array. Again, the realloc() command is the most efficient method of doing so. However, if the array must be sorted, you must compare the new data with each element prior to copying, and insert at the appropriate point. Once inserted, the remaining elements can be copied into place and then the original array can be released.

Due to the reallocation and copying of elements, this approach is highly inefficient. You can alleviate some of the re-allocations by allocating several empty elements at a time, and keeping track of how many empty elements there are available for insertions. This can be achieved by keeping all empty elements at the end of the array, and maintaining a count of those elements. To delete an existing element, shunt data to the right one place to the left to remove the gap. And if the number of empty elements exceeds a given minimum, re-allocate the array to remove redundancy.

Although this is a better approach, it is still quite inefficient, particularly if the array is large. If the array is small and there are few insertions and deletions, then it probably won't matter too much, but for larger arrays with many insertions and deletions to cater for, a far better approach would be to use a linked list. This makes better use of memory, as the list can expand and contract dynamically without the need to copy any elements (or nodes) whatsoever. Some additional memory is required to maintain the links between the nodes but, unlike an array, no memory is ever wasted.

constant pointer and character pointer

When creating linked lists (singly- or doubly-linked), the elements in the list are known as nodes. A node class defines how these nodes work. Generally, a node will contain a member pointer to the data it represents (which is typically an abstract data type rather than a concrete data class), as well as a pointer to the next node in the list, and the previous node if it is doubly-linked. The list itself maintains a member pointer to the head node in the list, and the tail node if doubly-linked.

In this way, the list is only concerned with the nodes, not the data within those nodes. By the same token the nodes are only concerned with their nearest neighbouring nodes, not the list, nor the data they contain. Similarly, the data is only concerned with itself and other data, it is not concerned with the fact it may be part of a list or a node.

All work concerning nodes can then be delegated to the nodes themselves, while any work relating to the data can be delegated to the data. Thus each class plays a small but clearly defined role within the list; no class does any more than it has to, which greatly simplifies the list interface.

Too many errors possible to say. Please elaborate.

Computers in general are important to geomatics, primarily as a means of storing and organising the large amount of data involved in typical geomatic fields, which includes GPS navigation. Ultimately, your in-car GPS would simply not work without programming. But geomatics is relatively new (circa 1969) and computers capable of presenting the data visually, in real-time, have only recently begun to appear. The technology is constantly evolving, finding new uses in more and more fields of study, and computer programming is naturally at the forefront of that evolution.