Tag Archives: Cplusplus

overloading, functions vs. methods, and rule of three

As we progress through the semester, and a fast approaching third test we find ourselves focusing on overloading, functions(symmetric operations) vs methods(asymmetric), and the rule of three.

    when overloading functions or methods in C++ there are several values that can be overridden. for functions we have: the types of the arguments and if the function is not an operator then we can also override on the number of arguments. Likewise with methods we can override on the type of the arguments and the const-ness of the method, if the method happens to not be an operator then we can also override on the number of arguments as well.

   In designing a class one of the questions that should be asked is whether the function could/should belong to the class which members it would need to take as an argument. To answer this question we can look at the constructor and if it is not marked explicit(as such allowing implicit conversion from the type of argument it accepts) then we should allow the function to remain outside of the scope of the class, this way we can have the implicit conversion for its arguments happen on either side. In addition to the last mentioned sided-ness argument one should also consider if the left hand side of the function needs to be of another class (for example the input/output streams) if this is the case then we again want to keep the function outside the scope of any class as we cant modify the stream class directly, so we let the globally scoped function do the work for us. Otherwise it might be appropriate to declare the function as a method instead.

 The rule of three was another topic covered and it quite simply says that if we need to override any of the destructor, copy constructor, or the copy assignment operations then we will likely need to override the other two of the ones mentioned above. To do this without repeating code we could create helper methods or we could define the copy constructor in terms of assignment or the assignment in terms of the copy constructor, the latter if probably more favorable as it leads to a three line solution involving calling swap.

Advertisements

templating vs pointers, array object vs primitive storage, and the glory of STL vectors in C++

This post shall be rather short in its nature as it is already past due and I am still trying to finish up my workload that I had on my “break”. Two weeks ago in OOP we took some time to observe the nuances of array initialization with a high point being demonstrated by quiz 20, namely showing that an array of type A instantiated with Bs would create the invocation pattern: B constructor, A constructor, A copy Constructor, B destructor and lastly when the Array exited the function scope of invocation A destructor would be called.We also looked at templating examples and pointers. The high point there being that templating allowed for more types of iterators than pointers, but that some iterators imposed restrictions on the order in which their functions were called, namely the read iterator, and the * and == operators. We also briefly discussed why the STL was nice, and the fact that vectors are similar but much faster than java ArrayLists. The high points being attempt to use STL or Boost to save some troubles and a reference to the fact that C++ vectors subscript([]) operator did not suffer from the linear time look-up like java’s List interface does, however there is some overhead on the .at operator.

 

Arrays and Pointers galore

This week in OOP, we spent most of our time iterating over the different types of pointers in C++ and motivating some examples, the discussion stems from the fact that there are 4 varients of pointers in c++ which can be summed up by the following code and comments:

int c;

int* b; // read/write, many locations

cont int* pc; // read only, many locations

int* const cp = &c; // read/write one location (same as doing int& cp = c;)

const int* const cpc = &c; // read only, one location

We took some time later on to discuss the fact that in java arrays are allocations of values only if the data members are primitive types and for all non-primitives the array holds references to the type, unlike in c++ where the arrays contain the values themselves and can either be stack allocated or heap allocated, unlike java where all stack values reside on the heap.We finished up the week by looking at pointers vs. arrays in c++ noting that pointers are rvalues where arrays seem to be lvalues.

Heap Emulation

This week in OOP we began focusing on type casting in C++ as well as allocation strategies and data storage strategies.

The type casting of C++ is a bit more verbose than it is in most other languages, the reason being is that often when typecasting data is truncated and latter we find that this data was needed, so since errors sometimes result C++ has taken to making typecasting easy to spot by giving it an overly verbose form. An example of this is the following:

int& view(char& c) const{
return *reinterpret_cast<int*>(&c);
}
 

The allocation and data storage strategies we reviewed were the following:

  • in C++ most systems interpret a char as 1 byte, as such it is a lightweight way to store general byte data.
  • to denote free space in a heap we can create sentinel values as int values(aka: 4 bytes), often these values might get overwritten accidentally, so to provide some minor error checking store two copies of each sentinel required.
  • to denote active/taken blocks use a negative value to distinguish between free blocks(positive values)

By using this information as well as some unit tests developed on the native heap manager we hope to achieve a similar heap manager that allows us more granular control of the data it has allocated, this is stricly for educational purposes of course.