Week 6 - Pair Programming Round 2 (Oct 1 to Oct 7)

Yesterday, I posted a blog which goes into some depth about const expressions in C++.

Since Andy and I recently encountered an issue with "const" in our project, I will add an extra comment about that here. Note that you can add "const" right before the opening brace of a method declaration, which tells the compiler that the code in that method will not alter the state of the current instance of the class.

Since a[] is an instance member of class Allocator, "bool valid() const {" says that it won't try to modify the values in a[]. Depending on how you write validate, you might run into the situation where the compiler complains about something like:

char* first = &a[0]; // error

So the simple solution to that is instead writing:

const char* first = &a[0];

Note that this is a side effect of the compiler trying to protect you from making unintentional changes to a[] inside of a function which says you won't modify it. In a non-const function, the first version would be okay.

Technically since valid() is a private function, you can change its interface to not say "const", but I would recommend against that because they provided the method stub for us.

Project 3 So Far

---

Going into this project I was a little less enthusiastic going into previous ones, because in CS 439 last semester, I implemented a memory allocator (specifically, a malloc package) using this algorithm (and also a more complex algorithm that uses a O(log(n)) algorithm for selecting which free block to use (to improve performance for a workflow involving many alloc()'s and many free()'s in an arbitrary order)).

Basically, I felt like I had already done this project and that it would be a waste of time.

I'm pleased to say that it definitely wasn't! Working with Andy has been a really pleasant experience. Since I already knew the project really well, I had the opportunity to really slow down and explain how it worked to someone who is really willing to absorb and learn.

Also I have the chance to slow down and make sure that the whole thing is adequately tested and documented.

The cool thing about this project is seeing how templates let us take the same unit tests and apply them to different implementations of the same interface. I like Java generics a bit better in this respect because you can declare a generic with a certain type or interface and any class which subclasses that class can substitute in, but in C++, you don't exactly get that sort of information. As long as you know what you're doing, however, that's not too much of a problem.

One thing which saved us a lot of grief in this project was modularizing the code A LOT and using macros for common "gestures" like finding the header and footer of the previous and next block. Once nice thing about macros is that even though they appear to be functions, they can be used as lvalues as long as the expression works (like you have a pointer p and you have a macro which does *p, which is an lvalue).

I wonder if there is a way to make the return value from a function act as an lvalue. There is probably a trick with references that can be used in that situation.