COMP6771 Week 3.1

Object-Oriented Programming

Scope

The scope of a variable is the part of the program where it is accessible
- Scope starts at variable definition
- Scope (usually) ends at next "}"
- You're probably familiar with this even if you've never seen the term
Define variables as close to first usage as possible
This is the opposite of what you were taught in first year undergrad
- Defining all variables at the top is especially bad in C++

Object Lifetimes

An object is a piece of memory of a specific type that holds some data
- All variables are objects
- Unlike many other languages, this does not add overhead
Object lifetime starts when it comes in scope
- "Constructs" the object
- Each type has 1 or more constructor that says how to construct it
Object lifetime ends when it goes out of scope
- "Destructs" the object
- Each type has a different "destructor" which tells the compiler how to destroy it

Construction

Eg. https://en.cppreference.com/w/cpp/container/vector/vector
Generally use () to call functions, and {} to construct objects
- () can only be used for functions, and {} can be used for either
- There are some rare occasions these are different
  - Sometimes it is ambiguous between a constructor and an initialize list

int main() {
  std::vector<int> v11; // Calls 0-argument constructor. Creates empty vector.
  // There's no difference between these:
  // T variable = T{arg1, arg2, ...}
  // T variable{arg1, arg2, ...}
  std::vector<int> v12{}; // No different to first
  std::vector<int> v13 = std::vector<int>(); // No different to the first
  std::vector<int> v14 = std::vector<int>{}; // No different to the first

  std::vector<int> v3{v2.begin(), v2.end()}; // constructed with an iterator
  std::vector<int> v4{v3}; // Constructed off another vector

  std::vector<int> v51{5, 2}; // Initialiser-list constructor {5, 2}
  std::vector<int> v52(5, 2); // Count + value constructor (5 * 2 => {2, 2, 2, 2, 2})
}

Construction

Also works for your basic types
- But the default constructor has to be manually called
  - This potential bug can be hard to detect due to how function stacks work (variable may happen to be 0)
  - Can be especially problematic with pointers

int main() {
  int n; // not constructed (memory contains previous value)
  int n2{}; // Default constructor (memory contains 0)
  int n3{5};

  // This version is nice because it gives us an error.
  int n4{5.5};
  // You need to explictly tell it you want this.
  int n6{static_cast<int>(5.5)};

  // Not so nice. No error
  int n5 = 5.5;
}

Why are object lifetimes useful?

Can you think of a thing where you always have to remember to do something when you're done?

void ReadWords(const std::string& filename) {
  std::ifstream f{filename};
  std::vector<std::string> words;
  std::copy(std::istream_iterator<std::string>{f}, {}, std::back_inserter{words});
  f.close();
}

What happens if we omit f.close() here (assume similar behavior to c/java/python)?
How easy to spot is the mistake
How easy would it be for a compiler to spot this mistake for us?
- How would it know where to put the f.close()?

RAII

Resource acquisition is initialisation
A concept where we encapsulate resources inside objects
- Acquire the resource in the constructor
- Release the resource in the destructor
- eg. Memory, locks, files
Every resource should be owned by either:
- Another resource (eg. smart pointer, data member)
- The stack
- A nameless temporary variable

Noexcept

Exceptions will be covered in week 5, but the short version is that they are recoverable, but critical errors
A noexcept-specified function tells the compiler not to generate recovery code
An exception thrown in a noexcept function will terminate your program
Use noexcept to guarantee that callers needn't worry about exception-handling.
You can use noexcept to say that you don't mind your whole program ending if something goes wrong in this function.

Destructors

Call when the object goes out of scope
- What might this be handy for?
- Does not occur for reference objects (why?)
Marked noexcept (why?)
Why might destructors be handy?

Destructors

Called when the object goes out of scope
- What might this be handy for?
- Does not occur for reference objects (why?)
Marked noexcept (why?)
Why might destructors be handy?
- Freeing pointers
- Closing files
- Unlocking mutexes (from multithreading)
- Aborting database transactions

class MyClass {
  ~MyClass() noexcept;
};

MyClass::~MyClass() noexcept {
  // Definition here
}

What is OOP

A class uses data abstraction and encapsulation to define an abstract data type:
- Interface: the operations used by the user (an API)
- Implementation: the data members the bodies of the functions in the interface and any other functions not intended for general use
- Abstraction: separation of interface from implementation
- Encapsulation: enforcement of this via information hiding
- Example: Bookstore - bookstore.h (interface), bookstore.cpp (implementation), user code (knows the interface).

C++ classes

A class:
- Defines a new type
- Is created using the keywords class or struct
- May define some members (functions, data)
- Contains zero or more public and private sections
- Is instantiated through a constructor
A member function:
- must be declared inside the class
- may be defined inside the class (it is then inline by default)
- may be declared const, when it doesn’t modify the data members
The data members should be private, representing the state of an object.

Abstraction and encapsulation

Abstraction is separating the interface from the implementation
Encapsulation is hiding details about class representation and implementation
- An object’s state can only be accessed/modified via the public interface

Advantages:

Object state is protected from user-level errors
- Users can't break invariants by changing something
Class implementation may evolve over time
- If you change a variable or a private function, users don't need to change anything

Incomplete types

An incomplete type may only be used to define pointers and references, and in function declarations (but not definitions)
Because of the restriction on incomplete types, a class cannot have data members of its own type.

But the following is legal, since a class is considered declared once its class name has been seen:

struct Node {
  int data;
  // Node is incomplete - this is invalid
  // This would also make no sense. What is sizeof(Node)
  Node next;
};

struct Node {
  int data;
  Node* next;
};

Member access control

This is how we support encapsulation and information hiding in C++

class Foo {
 public:
  // Members accessible by everyone
  Foo();

 protected:
  // Members accessible by members, friends, and subclasses
  // Will discuss this when we do advanced OOP in future weeks.

 private:
  // Accessible only by members and friends
  void PrivateMemberFunction();

  int private_data_member_;

 public:
  // May define multiple sections of the same name
};

Classes and structs in C++

A class and a struct in C++ are almost exactly the same
The only difference is that:
- All members of a struct are public by default
- All members of a class are private by default
- People have all sorts of funny ideas about this. This is the only difference
We use structs only when we want a simple type with little or no methods and direct access to the data members (as a matter of style)
- This is a semantic difference, not a technical one
- A std::pair or std::tuple may be what you want, though

Friends

A class may declare friend functions or classes
- Those functions / classes are non-member functions that may access private parts of the class
- This is, in general, a bad idea, but there are a few cases where it may be required
  - Nonmember operator overloads (will be discussing soon)
  - Related classes
    - A Window class might have WindowManager as a friend
    - A TreeNode class might have a Tree as a friend
    - Container could have iterator_t<Container> as a friend
      - Though a nested class may be more appropriate
- Use friends when:
  - The data should not be available to everyone
  - There is a piece of code very related to this particular class

Class Scope

Anything declared inside the class needs to be accessed through the scope of the class
- Scopes are accessed using "::" in C++

// foo.h

class Foo {
 public:
  // Equiv to typedef int Age
  using Age = int;

  Foo();
  Foo(std::istream& is);
  ~Foo();

  void MemberFunction();
};

// foo.cpp
#include "foo.h"

Foo::Foo() {
}

Foo::Foo(std::istream& is) {
}

Foo::~Foo() {
}

void Foo::MemberFunction() {
  Foo::Age age;
}

This pointer

A member function has an extra implicit parameter, named this
- This is a pointer to the object on behalf of which the function is called
- A member function does not explicitly define it, but may explicitly use it
- The compiler treats an unqualified reference to a class member as being made through the this pointer.
- The this pointer always has top-level const
For the next few slides, we'll be taking a look at the BookSale example in the course repo

This pointer

A member function has an extra implicit parameter, named this
- This is a pointer to the object on behalf of which the function is called
- A member function does not explicitly define it, but may explicitly use it
- The compiler treats an unqualified reference to a class member as being made through the this pointer.
- The this pointer always has top-level const
For the next few slides, we'll be taking a look at the BookSale example in the course repo

Const objects

Member functions are by default only be possible on non-const objects
- You can declare a const member function which is valid on const objects
- A const member function may only modify mutable members
  - A mutable member should mean that the state of the member can change without the state of the object changing
  - Good uses of mutable members are rare
  - Mutable is not something you should set lightly
  - One example where it might be useful is a cache
Let's make the BookSale class const correct

Are the following correct

Are the following correct?

Sales_data a{"Harry Potter"};
Sales_data b{"Harry Potter"};

a.combine(b).print(std::cout);
a.print(std::cout).combine(b);

Are the following correct

Are the following correct?

The combine/print is fine
The print/combine fails since print returns a const reference through which we cannot call a nonconst member
Four possible ways to get it to compile. Discuss.
- Make combine a const function
- Make print a non-const function
- Add an overload to print for non-const
- Change the user code

Sales_data a{"Harry Potter"};
Sales_data b{"Harry Potter"};

a.combine(b).print(std::cout);
a.print(std::cout).combine(b);

Constructors

Constructors define how class data members are initalised
A constructor has the same name as the class and no return type
Default initalisation is handled through the default constructor
Unless we define our own constructors the compile will declare a default constructor
- This is known as the synthesized default constructor

for each data member in declaration order
  if it has an in-class initialiser
    Initialise it using the in-class initialiser
  else if it is of a built-in type (numeric, pointer, bool, char, etc.)
    do nothing (leave it as whatever was in memory before)
  else
    Initialise it using its default constructor

The synthesized default constructor

Is generated for a class only if it declares no constructors
For each member, calls the in-class initialiser if present
- Otherwise calls the default constructor (except for trivial types like int)
Cannot be generated when any data members are missing both in-class initialisers and default constructors

class C {
  int i{0}; // in-class initialiser
  int j; // Untouched memory
  A a;
  // This stops default constructor
  // from being synthesized.
  B b;
};

class A {
  int a_;
};

class B {
  B(int b): b_{b} {}
  int b_;
};

Constructor initialiser list

The initialisation phase occurs before the body of the constructor is executed, regardless of whether the initialiser list is supplied
A constructor will:
1. Construct all data members in order of member declaration (using the same rules as those used to initialise variables)
2. Execute the body of constructor: the code may assign values to the data members to override the initial values

Constructor initialiser list

class NoDefault {
  NoDefault(int i);
}

class B {
  // Constructs s_ with value "Hello world"
  B(int& i): s_{"Hello world"}, const_{5}, no_default{i}, ref_{i} {}
  // Doesn't work - constructed in order of member declaration.
  B(int& i): s_{"Hello world"}, const_{5}, ref_{i}, no_default{ref_} {}
  B(int& i) {
    // Constructs s_ with an empty string, then reassigns it to "Hello world"
    // Extra work done (but may be optimised out).
    s_ = "Hello world";

    // Fails to compile
    const_string_ = "Goodbye world";
    ref_ = i;
    // This is fine, but it can't construct it initially.
    no_default_ = NoDefault{1};
  }

  std::string s_;
  // All of these will break compilation if you attempt to put them in the body.
  const int const_;
  NoDefault no_default_;
  int& ref_;
};

Delegating constructors

A constructor may call another constructor inside the initialiser list
- Since the other constructor must construct all the data members, do not specify anything else in the constructor initialiser list
- The other constructor is called completely before this one.
- This is one of the few good uses for default values in C++
  - Default values may be used instead of overloading and delegating constructors

Static members

Both data and function members may be declared static
These are essentially globals defined inside the scope of the class
- Use static members when something is associated with a class, but not a particular instance
- Static data has global lifetime (program start to program end)

// For use with a database
class User {
  static std::string table_name;
  static std::optional<User> query(const std::string& username);
  
  void commit();
  std::string username;
}

User user = *User::query("Alice");
user.username = "Bob"
User::commit(); // fails to compile (commit is not static)
user.commit();

std::cout << User::table_name;
std::cout << User::username; // Fails to compile

Explicit type conversions

If a constructor for a class has 1 parameter, the compiler will create an implicit type conversion from the parameter to the class
This may be the behaviour you want

class Age {
  Age(int age);
};

// Explicitly calling the constructor
Age age{20};
// Attempts to use an integer
// where an age is expected.
// Implicit conversion done.
// This seems reasonable.
Age age = 20;

class IntVec {
  // This one allows the implicit conversion
  IntVec(int length): vec_(length, 0);

  This one disallows it.
  explicit IntVec(int length): vec_(length, 0);

  std::vector<int> vec_;
};

// Explictly calling the constructor.
IntVec container{20};

// Implicit conversion.
// Probably not what we want.
IntVec container = 20;

OOP design

There are several special functions that we must consider when designing classes
For each of these functions, ask yourself:
- Is it sane to be able to do this?
- Does it have a well-defined, obvious implementation
If the answer to either of these is no, write "<function declaration> = delete;"
Then ask yourself "is this the behaviour of the compiler-synthesized one"
- If so, write "<function declaration> = default;"
- If not, write your own definition
Let's discuss these questions for these types over the next few slides:
- std::vector
- Mutex
- Pointer

Copying constructor

Constructs one object to be a copy of another
The compiler-generated copy-constructor just calls each member's copy constructor in order of declaration

class T {
  T(const T&);
};

Copying assignment

Like a copy constructor, but the destination is already constructed
Requires destroying the old data, and constructing the new data
Copy-and-swap idiom is an elegant way of doing this
- It constructs then destructs. Since construction might fail, it should go first
- Requires move assignment to be defined
Takes in an lvalue
Compiler-generated one performs memberwise copy-assignment operator

class T {
  // A copy-assignment operator
  T& operator=(const T& original);

  // The copy-and-swap idiom
  // This is also a copy-assignment operator
  T& operator=(T copy) {
    std::swap(*this, copy);
    return *this;
  }
};

MyClass base;
MyClass copy_constructed = base;

MyClass copy_assigned;
copy_assigned = base;

Rvalue references

Rvalue references look like T&& (lvalue is T&)
An lvalue denotes an object whose resource cannot be reused
- Most objects (eg. variable, variable[0])
- Once the lvalue reference goes out of scope, it may still be needed
An rvalue denotes an object whose resources can be reused
- eg. Temporaries (MyClass object in f(MyClass{}))
- When someone passes it to you, they don't care about it once you're done with it

“The object that x binds to is YOURS. Do whatever you like with it, no one will care anyway”
Like giving a copy to f… but without making a copy.

void f(MyClass&& x);

Rvalue references

void inner(int&& value) {
  ++value;
  std::cout << value << '\n';
}

void outer(int&& value) {
  inner(value); // This fails? Why?
  std::cout << value << '\n';
}

int main() {
  f1(1); // This works fine.
  int i;
  f2(i); // This fails because i is an lvalue.
}

An rvalue reference formal parameter means that the value was disposable from the caller of the function
- If outer modified value, who would notice / care?
  - The caller (main) has promised that it won't be used anymore
- If inner modified value, who would notice / care?
  - The caller (outer) has never made such a promise.
  - An rvalue reference parameter is an lvalue inside the function

std::move

// Looks something like this.
T&& move(T& value) {
  return static_cast<T&&>(value);
}

Simply converts it to an rvalue
- This says "I don't care about this anymore"
- All this does is allow the compiler to use rvalue reference overloads

void inner(int&& value) {
  ++value;
  std::cout << value << '\n';
}

void outer(int&& value) {
  inner(std::move(value));
  // Value is now in a valid but unspecified state.
  // Although this isn't a compiler error, this is bad code.
  // Don't access variables that were moved from, except to reconstruct them.
  std::cout << value << '\n';
}

int main() {
  f1(1); // This works fine.
  int i;
  f2(std::move(i));
}

Move constructor

Always should be declared noexcept
Unless otherwise specified, objects that have been moved from are in a valid but unspecified state
Will likely be faster than the copy constructor
Compiler-generated one performs memberwise move-construction

class T {
  T(T&&) noexcept;
};

Move assignment

Always should be declared noexcept
Like the move constructor, but the destination is already constructed
Compiler-generated one performs memberwise move-assignment

class T {
  T& operator=(T&&) noexcept;
};

Object lifetimes

To create safe object lifetimes in C++, we always attach the lifetime of one object to that of something else

A variable in a function is tied to its scope
A data member is tied to the lifetime of the class instance
An element in a std::vector is tied to the lifetime of the vector
A heap object should be tied to the lifetime of whatever object created it
Examples of bad programming practice
- An owning raw pointer is tied to nothing
- A C-style array is tied to nothing
Strongly recommend watching the first 44 minutes of Herb Sutter's cppcon talk "Leak freedom in C++... By Default"

Constructing wrapper types

class MyClass {
  MyClass();
  MyClass(int);
  MyClass(const MyClass&);
  MyClass(MyClass&&);
  int GetValue();
};

// calls default constructor
std::optional<MyClass> opt1 = std::make_optional<MyClass>();
// calls int constructor
std::optional<MyClass> opt2 = std::make_optional<MyClass>(5);
// calls copy constructor
std::optional<MyClass> opt3 = *opt1;
// calls move constructor
std::optional<MyClass> opt4 = std::move(*opt1);
opt4->GetValue();

// Similar for make_unique and make_shared, but have to manually move / copy values
std::shared_ptr<MyClass> sp1 = std::make_shared<MyClass>();
std::shared_ptr<MyClass> sp2 = sp1;
std::shared_ptr<MyClass> sp3 = std::move(sp1);
MyClass* p2 = sp1.get();

std::unique_ptr<MyClass> up1 = std::make_unique<MyClass>(*sp1);
std::unique_ptr<MyClass> up2 = *up1; // But have to manually move / copy values like above
std::unique_ptr<MyClass> up3 = up1; // Fails (no copy constructor)
std::unique_ptr<MyClass> up4 = std::move(up1);
MyClass* p1 = up1.get();
up1->GetValue();

Namespaces

A namespace encapsulates a set of functions, classes, and other namespaces
If I have a really big piece of code, with several external pieces of code, what are the chances of two functions / classes having the same name somewhere in the code?
You've already seen one namespace used a lot, without knowing it (std)

// path/to/file.h

namespace path {
namespace to {

class MyClass {
}

void MyFn();
  
} // namespace to
} // namespace path

// main.cpp
#include "path/to/file.h"

int main() {
  path::to::MyClass myClass;
  path::to::MyFn();
}

// path/to/file.cpp

namespace path {
namespace to {

MyFn() {
}
  
} // namespace to
} // namespace path

The using keyword

Several ways to use the using keyword
- These are the two most important ways

// Far cleaner than typedef, and the
// arguments are the right way around!
int main() {
  using intvec = std::vector<int>;
  intvec vec;

  C::iterator_t it;
}

class IteratorC {
}

class C {
  using iterator_t = IteratorC;
}

#include "path/to/file.h"

int main() {
  // Imports a single thing
  // into the current scope.
  using path::to::MyClass;
  MyClass myClass;
}

Using declaration

Type alias

ADL

Due to a feature of C++ called "Argument dependent lookup", use the using declaration for some specific functions
- This is a complex topic to be discussed in later weeks
This is only relevant when using non-standard types
Use this for the following functions
- std::swap
- std::[cr]begin
- std::[cr]end
- std::empty
- std::size
- std::data

#include "myclass.h"

using std::begin;
using std::end;
using std::swap;

int main() {
  std::vector<MyClass> vec{{}, {}};
  swap(vec[0], vec[1]);
  for (auto it = begin(vec); it != end(vec); ++it) {
    std::cout << *it << '\n';
  }
}

Argument dependent lookup

When looking up an unqualified function, the compiler first looks at the namespace of the type of the arguments
- If it contains a matching function declaration, it uses that
- Otherwise, it falls back to the normal function lookup
Use ADL for std::swap, std::begin, and std::end
- You may write "using std::swap;"
- Do not write "using namespace std;"

// myclass.h

namespace ns {

void MyClass {
}

void swap(MyClass&, MyClass&);

}

#include "myclass.h"

int main() {
  ns::MyClass v1, v2;
  std::swap(v1, v2);  // Calls std::swap
  {
    // Import std::swap to the current scope
    using std::swap;
    int i, j;
    swap(i, j); // calls std::swap
    swap(v1, v2); // calls ns::swap
  }
}

COMP6771 19T2 - 3.1 - Basic OOP

By cs6771

COMP6771 19T2 - 3.1 - Basic OOP

COMP6771 Week 3.1

Scope

Object Lifetimes

Construction

Construction

Why are object lifetimes useful?

RAII

Noexcept

Destructors

Destructors

What is OOP

C++ classes

Abstraction and encapsulation

Incomplete types

Member access control

Classes and structs in C++

Friends

Class Scope

This pointer

This pointer

Const objects

Are the following correct

Are the following correct

Constructors

The synthesized default constructor

Constructor initialiser list

Constructor initialiser list

Delegating constructors

Static members

Explicit type conversions

OOP design

Copying constructor

Copying assignment

Rvalue references

Rvalue references

std::move

Move constructor

Move assignment

Object lifetimes

Constructing wrapper types

Namespaces

The using keyword

ADL

Argument dependent lookup

COMP6771 19T2 - 3.1 - Basic OOP

More from cs6771