Trance-0/NoteNextra-origin
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity

update

Browse Source
This commit is contained in:
Trance-0
2025-03-05 00:49:12 -06:00
parent 4527d424c2
commit 3b7a23a323
3 changed files with 481 additions and 172 deletions
Download Patch File Download Diff File Expand all files Collapse all files

429
pages/CSE332S/CSE332S_L13.md
View File

@@ -1,224 +1,309 @@
# CSE332S Lecture 13
## Copy control
## Memory layout of a C++ program, variables and their lifetimes
Copy control consists of 5 distinct operations
### C++ Memory Overview
- A `copy constructor` initializes an object by duplicating the const l-value that was passed to it by reference
- A `copy-assignment operator` (re)sets an object's value by duplicating the const l-value passed to it by reference
- A `destructor` manages the destruction of an object
- A `move constructor` initializes an object by transferring the implementation from the r-value reference passed to it (next lecture)
- A `move-assignment operator` (re)sets an object's value by transferring the implementation from the r-value reference passed to it (next lecture)
4 major memory segments
Today we'll focus on the first 3 operations and will defer the others (introduced in C++11) until next time
- Global: variables outside stack, heap
- Code (a.k.a. text): the compiled program
- Heap: dynamically allocated variables
- Stack: parameters, automatic and temporary variables (all the variables that are declared inside a function, managed by the compiler, so must be fixed size)
- _For the dynamically allocated variables, they will be allocated in the heap segment, but the pointer (fixed size) to them will be stored in the stack segment._
- The others depend on the new C++11 `move semantics`
Key differences from Java
### Basic copy control operations
- Destructors of automatic variables called when stack frame where declared pops
- No garbage collection: program must explicitly free dynamic memory
A copy constructor or copy-assignment operator takes a reference to a (usually const) instance of the class
Heap and stack use varies dynamically
- Copy constructor initializes a new object from it
- Copy-assignment operator sets object's value from it
- In either case, original the object is left unchanged (which differs from the move versions of these operations)
- Destructor takes no arguments `~A()` (except implicit `this`)
Code and global use is fixed
Copy control operations for built-in types
- Copy construction and copy-assignment copy values
- Destructor of built-in types does nothing (is a "no-op")
Compiler-synthesized copy control operations
- Just call that same operation on each member of the object
- Uses defined/synthesized definition of that operation for user-defined types (see above for built-in types)
### Preventing or Allowing Basic Copy Control
Old (C++03) way to prevent compiler from generating a default constructor, copy constructor, destructor, or assignment operator was somewhat awkward
- Declare private, don't define, don't use within class
- This works, but gives cryptic linker error if operation is used
New (C++11) way to prevent calls to any method
- End the declaration with `= delete` (and don't define)
- Compiler will then give an intelligible error if a call is made
C++11 allows a constructor to call peer constructors
- Allows re-use of implementation (through delegation)
- Object is fully constructed once any constructor finishes
C++11 lets you ask compiler to synthesize operations
- Explicitly, but only for basic copy control, default constructor
- End the declaration with `= default` (and don't define) The compiler will then generate the operation or throw an error if it can't.
## Shallow vs Deep Copy
### Shallow Copy Construction
Code segment is "read-only"
```cpp
// just uses the array that's already in the other object
IntArray::IntArray(const IntArray &a)
:size_(a.size_),
values_(a.values_) {
// only memory address is copied, not the memory it points to
int g_default_value = 1;
int main (int argc, char **argv) {
Foo *f = new Foo;
f->setValue(g_default_value);
delete f; // programmer must explicitly free dynamic memory
return 0;
}
int main(int argc, char * argv[]){
IntArray arr = {0,1,2};
IntArray arr2 = arr;
return 0;
void Foo::setValue(int v) {
this->m_value = v;
}
```
There are two ways to "copy"
![Image of memory layout](https://notenextra.trance-0.com/images/CSE332S/CPP_Function_Memory.png)
- Shallow: re-aliases existing resources
- E.g., by copying the address value from a pointer member variable
- Deep: makes a complete and separate copy
- I.e., by following pointers and deep copying what they alias
### Memory, Lifetimes, and Scopes
Version above shows shallow copy
Temporary variables
- Efficient but may be risky (why?) The destructor will delete the memory that the other object is pointing to.
- Usually want no-op destructor, aliasing via `shared_ptr` or a boolean value to check if the object is the original memory allocator for the resource.
- Are scoped to an expression, e.g., `a = b + 3 * c;`
### Deep Copy Construction
Automatic (stack) variables
- Are scoped to the duration of the function in which they are declared
Dynamically allocated variables
- Are scoped from explicit creation (new) to explicit destruction (delete)
Global variables
- Are scoped to the entire lifetime of the program
- Includes static class and namespace members
- May still have initialization ordering issues
Member variables
- Are scoped to the lifetime of the object within which they reside
- Depends on whether object is temporary, automatic, dynamic, or global
**Lifetime of a pointer/reference can differ from the lifetime of the location to which it points/refers**
## Direct Dynamic Memory Allocation and Deallocation
```cpp
IntArray::IntArray(const IntArray &a)
:size_(0), values_(nullptr) {
if (a.size_ > 0) {
// new may throw bad_alloc,
// set size_ after it succeeds
values_ = new int[a.size_];
size_ = a.size_;
// could use memcpy instead
for (size_t i = 0;
i < size_; ++i) {
values_[i] = a.values_[i];
}
#include <iostream>
using namespace std;
int main (int, char *[]) {
int * i = new int; // any of these can throw bad_alloc
int * j = new int(3);
int * k = new int[*j];
int * l = new int[*j];
for (int m = 0; m < *j; ++m) { // fill the array with loop
l[m] = m;
}
delete i; // call int destructor
delete j; // single destructor call
delete [] k; // call int destructor for each element
delete [] l;
return 0;
}
int main(int argc, char * argv[]){
IntArray arr = {0,1,2};
IntArray arr2 = arr;
return 0;
}
```
This code shows deep copy
## Issues with direct memory management
- Safe: no shared aliasing, exception aware initialization
- But may not be as efficient as shallow copy in many cases
Note trade-offs with arrays
- Allocate memory once
- More efficient than multiple calls to new (heap search)
- Constructor and assignment called on each array element
- Less efficient than block copy
- E.g., using `memcpy()`
- But sometimes necessary
- i.e., constructors, destructors establish needed invariants
Each object is responsible for its own resources.
## Swap Trick for Copy-Assignment
The swap trick is a way to implement the copy-assignment operator, given that the `size_` and `values_` members are already defined in constructor.
### A Basic Issue: Multiple Aliasing
```cpp
class Array {
public:
Array(unsigned int) ; // assume constructor allocates memory
Array(const Array &); // assume copy constructor makes a deep copy
~Array(); // assume destructor calls delete on values_
Array & operator=(const Array &a);
private:
size_t size_;
int * values_;
};
Array & Array::operator=(const Array &a) { // return ref lets us chain
if (&a != this) { // note test for self-assignment (safe, efficient)
Array temp(a); // copy constructor makes deep copy of a
swap(temp.size_, size_); // note unqualified calls to swap
swap(temp.values_, values_); // (do user-defined or std::swap)
}
return *this; // previous *values_ cleaned up by temp's destructor, which is the member variable of the current object
int main (int argc, char **argv) {
Foo f;
Foo *p = &f;
Foo &r = f;
delete p;
return 0;
}
int main(int argc, char * argv[]){
IntArray arr = {0,1,2};
IntArray arr2 = {3,4,5};
arr2 = arr;
return 0;
}
```
## Review: Construction/destruction order with inheritance, copy control with inheritance
Multiple aliases for same object
### Constructor and Destructor are Inverses
- `f` is a simple alias, the object itself
- `p` is a variable holding a pointer
- `r` is a variable holding a reference
What happens when we call delete on p?
- Destroy a stack variable (may get a bus error there if we’re lucky)
- If not, we may crash in destructor of f at function exit
- Or worse, a local stack corruption that may lead to problems later
Problem: object destroyed but another alias to it was then used (**dangling pointer issue**)
### Memory Lifetime Errors
```cpp
IntArray::IntArray(unsigned int u)
: size_(0), values_(nullptr) {
// exception safe semantics
values_ = new int [u];
size_ = u;
Foo *bad() {
Foo f;
return &f; // return address of local variable, f is destroyed after function returns
}
IntArray::~IntArray() {
Foo &alsoBad() {
Foo f;
return f; // return reference to local variable, f is destroyed after function returns
}
// deallocates heap memory
// that values_ points to,
// so it's not leaked:
// with deep copy, object
// owns the memory
delete [] values_;
Foo mediocre() {
Foo f;
return f; // return copy of local variable, f is destroyed after function returns, danger when f is a large object
}
// the size_ and values_
// member variables are
// themselves destroyed
// after destructor body
Foo * good() {
Foo *f = new Foo;
return f; // return pointer to local variable, with new we can return a pointer to a dynamically allocated object, but we must remember to delete it later
}
int main() {
Foo *f = &mediocre(); // f is a pointer to a temporary object, which is destroyed after function returns, f is invalid after function returns
cout << good()->value() << endl; // good() returns a pointer to a dynamically allocated object, but we did not store the pointer, so it will be lost after function returns, making it impossible to delete it later.
return 0;
}
```
Constructors initialize
- At the start of each object's lifetime
- Implicitly called when object is created
Automatic variables
Destructors clean up
- Are destroyed on function return
- But in bad, we return a pointer to a variable that no longer exists
- Reference from also_bad similar
- Like an un-initialized pointer
- Implicitly called when an object is destroyed
- E.g., when stack frame where it was declared goes out of scope
- E.g., when its address is passed to delete
- E.g., when another object of which it is a member is being destroyed
What if we returned a copy?
### More on Initialization and Destruction
- Ok, we avoid the bad pointer, and end up with an actual object
- But we do twice the work (why?)
- And, it’s a temporary variable (more on this next)
Initialization follows a well defined order
We really want dynamic allocation here
- Base class constructor is called
- That constructor recursively follows this order, too
- Member constructors are called
- In order members were declared
- Good style to list in that order (a good compiler may warn if not)
- Constructor body is run
Dynamically allocated variables
Destruction occurs in the reverse order
- Are not garbage collected
- But are lost if no one refers to them: called a "**memory leak**"
- Destructor body is run, then member destructors, then base class destructor (which recursively follows reverse order)
Temporary variables
**Make destructor virtual if members are virtual**
- Are destroyed at end of statement
- Similar to problems w/ automatics
- Or if class is part of an inheritance hierarchy
- Avoids “slicing”: ensures destruction starts at the most derived class destructor (not at some higher base class)
Can you spot 2 problems?
- One with a temporary variable
- One with dynamic allocation
### Double Deletion Errors
```cpp
int main (int argc, char **argv) {
Foo *f = new Foo;
delete f;
// ... do other stuff
delete f; // will throw an error because f is already deleted
return 0;
}
```
What could be at this location?
- Another heap variable
- Could corrupt heap
## Shared pointers and the RAII idiom
### A safer approach using smart pointers
C++11 provides two key dynamic allocation features
- `shared_ptr` : a reference counted pointer template to alias and manage objects allocated in dynamic memory (we’ll mostly use the shared_ptr smart pointer in this course)
- `make_shared` : a function template that dynamically allocates and value initializes an object and then returns a shared pointer to it (hiding the object’s address, for safety)
C++11 provides 2 other smart pointers as well
- `unique_ptr` : a more complex but potentially very efficient way to transfer ownership of dynamic memory safely (implements C++11 “move semantics”)
- `weak_ptr` : gives access to a resource that is guarded by a shared_ptr without increasing reference count (can be used to prevent memory leaks due to circular references)
### Resource Acquisition Is Initialization (RAII)
Also referred to as the "Guard Idiom"
- However, the term "RAII" is more widely used for C++
Relies on the fact that in C++ a stack object’s destructor is called when stack frame pops
Idea: we can use a stack object (usually a smart pointer) to hold the ownership of a heap object, or any other resource that requires explicit clean up
- Immediately initialize stack object with the allocated resource
- De-allocate resource in the stack object’s destructor
### Example: Resource Acquisition Is Initialization (RAII)
```cpp
shared_ptr<Foo> createAndInit() {
shared_ptr<Foo> p =
make_shared<Foo> ();
init(p);// may throw exception
return p;
}
int run () {
try {
shared_ptr<Foo> spf =
createAndInit();
cout << “*spf is ” << *spf;
} catch (...) {
return -1
}
return 0;
}
```
RAII idiom example using shared_ptr
```cpp
#include <memory>
using namespace std;
```
- `shared_ptr<X>` assumes and maintains ownership of aliased X
- Can access the aliased X through it (*spf)
- `shared_ptr<X>` destructor calls delete on address of owned X when it’s safe to do so (per reference counting idiom discussed next)
- Combines well with other memory idioms
### Reference Counting
Basic Problem
- Resource sharing is often more efficient than copying
- But it’s hard to tell when all are done using a resource
- Must avoid early deletion
- Must avoid leaks (non-deletion)
Solution Approach
- Share both the resource and a counter for references to it
- Each new reference increments the counter
- When a reference is done, it decrements the counter
- If count drops to zero, also deletes resource and counter
- "last one out shuts off the lights"
### Reference Counting Example
```cpp
shared_ptr<Foo> createAndInit() {
shared_ptr<Foo> p =
make_shared<Foo> ();
init(p);// may throw exception
return p;
}
int run () {
try {
shared_ptr<Foo> spf =
createAndInit();
shared_ptr<Foo> spf2 = spf;
// object destroyed after
// both spf and spf2 go away
} catch (...) {
return -1
}
return 0;
}
```
Again starts with RAII idiom via shared_ptr
- `spf` initially has sole ownership of aliased X
- `spf.unique()` would return true
- `spf.use_count` would return 1
`shared_ptr<X>` copy constructor increases count, and its destructor decreases count
`shared_ptr<X>` destructor calls delete on the pointer to the owned X when count drops to 0

224
pages/CSE332S/CSE332S_L14.md Normal file
View File

@@ -0,0 +1,224 @@
# CSE332S Lecture 14
## Copy control
Copy control consists of 5 distinct operations
- A `copy constructor` initializes an object by duplicating the const l-value that was passed to it by reference
- A `copy-assignment operator` (re)sets an object's value by duplicating the const l-value passed to it by reference
- A `destructor` manages the destruction of an object
- A `move constructor` initializes an object by transferring the implementation from the r-value reference passed to it (next lecture)
- A `move-assignment operator` (re)sets an object's value by transferring the implementation from the r-value reference passed to it (next lecture)
Today we'll focus on the first 3 operations and will defer the others (introduced in C++11) until next time
- The others depend on the new C++11 `move semantics`
### Basic copy control operations
A copy constructor or copy-assignment operator takes a reference to a (usually const) instance of the class
- Copy constructor initializes a new object from it
- Copy-assignment operator sets object's value from it
- In either case, original the object is left unchanged (which differs from the move versions of these operations)
- Destructor takes no arguments `~A()` (except implicit `this`)
Copy control operations for built-in types
- Copy construction and copy-assignment copy values
- Destructor of built-in types does nothing (is a "no-op")
Compiler-synthesized copy control operations
- Just call that same operation on each member of the object
- Uses defined/synthesized definition of that operation for user-defined types (see above for built-in types)
### Preventing or Allowing Basic Copy Control
Old (C++03) way to prevent compiler from generating a default constructor, copy constructor, destructor, or assignment operator was somewhat awkward
- Declare private, don't define, don't use within class
- This works, but gives cryptic linker error if operation is used
New (C++11) way to prevent calls to any method
- End the declaration with `= delete` (and don't define)
- Compiler will then give an intelligible error if a call is made
C++11 allows a constructor to call peer constructors
- Allows re-use of implementation (through delegation)
- Object is fully constructed once any constructor finishes
C++11 lets you ask compiler to synthesize operations
- Explicitly, but only for basic copy control, default constructor
- End the declaration with `= default` (and don't define) The compiler will then generate the operation or throw an error if it can't.
## Shallow vs Deep Copy
### Shallow Copy Construction
```cpp
// just uses the array that's already in the other object
IntArray::IntArray(const IntArray &a)
:size_(a.size_),
values_(a.values_) {
// only memory address is copied, not the memory it points to
}
int main(int argc, char * argv[]){
IntArray arr = {0,1,2};
IntArray arr2 = arr;
return 0;
}
```
There are two ways to "copy"
- Shallow: re-aliases existing resources
- E.g., by copying the address value from a pointer member variable
- Deep: makes a complete and separate copy
- I.e., by following pointers and deep copying what they alias
Version above shows shallow copy
- Efficient but may be risky (why?) The destructor will delete the memory that the other object is pointing to.
- Usually want no-op destructor, aliasing via `shared_ptr` or a boolean value to check if the object is the original memory allocator for the resource.
### Deep Copy Construction
```cpp
IntArray::IntArray(const IntArray &a)
:size_(0), values_(nullptr) {
if (a.size_ > 0) {
// new may throw bad_alloc,
// set size_ after it succeeds
values_ = new int[a.size_];
size_ = a.size_;
// could use memcpy instead
for (size_t i = 0;
i < size_; ++i) {
values_[i] = a.values_[i];
}
}
}
int main(int argc, char * argv[]){
IntArray arr = {0,1,2};
IntArray arr2 = arr;
return 0;
}
```
This code shows deep copy
- Safe: no shared aliasing, exception aware initialization
- But may not be as efficient as shallow copy in many cases
Note trade-offs with arrays
- Allocate memory once
- More efficient than multiple calls to new (heap search)
- Constructor and assignment called on each array element
- Less efficient than block copy
- E.g., using `memcpy()`
- But sometimes necessary
- i.e., constructors, destructors establish needed invariants
Each object is responsible for its own resources.
## Swap Trick for Copy-Assignment
The swap trick is a way to implement the copy-assignment operator, given that the `size_` and `values_` members are already defined in constructor.
```cpp
class Array {
public:
Array(unsigned int) ; // assume constructor allocates memory
Array(const Array &); // assume copy constructor makes a deep copy
~Array(); // assume destructor calls delete on values_
Array & operator=(const Array &a);
private:
size_t size_;
int * values_;
};
Array & Array::operator=(const Array &a) { // return ref lets us chain
if (&a != this) { // note test for self-assignment (safe, efficient)
Array temp(a); // copy constructor makes deep copy of a
swap(temp.size_, size_); // note unqualified calls to swap
swap(temp.values_, values_); // (do user-defined or std::swap)
}
return *this; // previous *values_ cleaned up by temp's destructor, which is the member variable of the current object
}
int main(int argc, char * argv[]){
IntArray arr = {0,1,2};
IntArray arr2 = {3,4,5};
arr2 = arr;
return 0;
}
```
## Review: Construction/destruction order with inheritance, copy control with inheritance
### Constructor and Destructor are Inverses
```cpp
IntArray::IntArray(unsigned int u)
: size_(0), values_(nullptr) {
// exception safe semantics
values_ = new int [u];
size_ = u;
}
IntArray::~IntArray() {
// deallocates heap memory
// that values_ points to,
// so it's not leaked:
// with deep copy, object
// owns the memory
delete [] values_;
// the size_ and values_
// member variables are
// themselves destroyed
// after destructor body
}
```
Constructors initialize
- At the start of each object's lifetime
- Implicitly called when object is created
Destructors clean up
- Implicitly called when an object is destroyed
- E.g., when stack frame where it was declared goes out of scope
- E.g., when its address is passed to delete
- E.g., when another object of which it is a member is being destroyed
### More on Initialization and Destruction
Initialization follows a well defined order
- Base class constructor is called
- That constructor recursively follows this order, too
- Member constructors are called
- In order members were declared
- Good style to list in that order (a good compiler may warn if not)
- Constructor body is run
Destruction occurs in the reverse order
- Destructor body is run, then member destructors, then base class destructor (which recursively follows reverse order)
**Make destructor virtual if members are virtual**
- Or if class is part of an inheritance hierarchy
- Avoids “slicing”: ensures destruction starts at the most derived class destructor (not at some higher base class)

BIN
public/CSE332S/CPP_Function_Memory.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 17 KiB