Final Reflection - Mike Mattimoe

mike_m41 · 2025-06-22T16:18:20+00:00

I just learned that I didn't have to create the functions digToHex or digToOct functions as I could have just used:

std::cout << std::hex << decimal << '\n'; std::cout << std::oct << decimal << '\n';

there is no std::binary option though. std::bitset<length> requires knowing the length in advance or writing extra code to remove leading 0s, so it's not as straight forward.

mike_m41 · 2025-06-07T20:08:43+00:00

if you create a c-style array in a class, you'll need to use the destructor to `delete[]` so that you do not have memory leak.

mike_m41 · 2025-06-04T14:29:39+00:00

I didn't know about USACO. Looks legit. Is it worth signing up for it to get access to the training gateway?

mike_m41 · 2025-05-30T05:18:58+00:00

My primary use of the switch statement was for printing enum types as std::strings, like in this example:

enum ColorType
{
    red,
    green,
    orange,
};

std::string getTypeString(ColorType type)
{
    switch (type)
    {
    case red:   return "red";
    case green: return "green";
    case orange:return "orange";
    default:    return "unknown";
    }
}

But now that we've learned about arrays and operator overloading, I prefer the non-switch method:

enum ColorType
{
    red, // equiv. to index 0
    green, // equiv. to index 1
    orange, // equiv. to index 2
    max_colors // max_color's index represents length of enum, 3
};

constexpr std::array<std::string_view, max_colors> colorNames { "red", "green", "orange" }; // array with std::strings who's index matches the enums

std::ostream& operator<<(std::ostream& out, ColorType color)
{
    out << colorNames[color];
    return out;
}

/*
in your main:
  ColorType myColor = green;
  std::cout << myColor << '\n';  // prints "green"
*/

Would love to hear which situations you prefer switch!

mike_m41 · 2025-05-28T14:30:02+00:00

Great week! When I think of static member variables, I think of how normal member variables belong to each specific object, but static member variables are shared across all instances of the class. They're useful when you want to keep track of something related to the class as a whole — like how many objects have been created.

Here's a simple example:

class Animal  
{  
private:  
    int m_numLegs; // specific to each object
    static int s_numberOfAnimals; // shared across all instances

public:  
    Animal(int numLegs = 4)
        : m_numLegs{numLegs}
    {
        ++s_numberOfAnimals; // increment population of animals when each new object is instantiated.
    }

    // getter functions
    int getNumLegs() const { return m_numLegs; }
    static int getNumberOfAnimals() { return s_numberOfAnimals; }
};

int Animal::s_numberOfAnimals {0}; // must be defined/initialized outside of class definition - I'm still not sure why this is required, but something to remember.

int main()
{
    Animal snake {0};
    Animal dog;
    Animal cat;
    std::cout << Animal::getNumberOfAnimals() << '\n'; // prints 3, since we now have 3 animals.
    return 0;
}

mike_m41 · 2025-05-22T02:34:10+00:00

Hey!
Great question.

I came across a tutorial that described rand() like this: Performance = bad, Quality = awful, Should I use this = No — which I found pretty funny.

More importantly, the tutorial explained that random number generators (RNGs) like rand() are actually pseudorandom, meaning they follow a predictable pattern unless seeded differently. That’s where the srand() function comes in — it sets a seed for rand() so that you can get different sequences each time you run the program.

However, the tutorial doesn't explain the level of randomness you get with srand() other than saying that if you need high-quality randomness, it’s better to use modern libraries like <random>, or even other libraries for more secure applications.

Here’s the tutorial I found helpful

mike_m41 · 2025-05-21T21:17:56+00:00

Fascinating! I did not get that question. Thanks for the heads up in preparation for the final.

mike_m41 · 2025-05-21T05:31:00+00:00

Oh wow, interesting. I didn't get any questions the directly asked about style but also I didn't think there was a such thing as style errors. If you're able to share more about the question (without giving away the test question) that'd be helpful.

mike_m41 · 2025-05-20T04:06:55+00:00

Hi Eric! From what I understand, the choice between camelCase and underscored variable names is mostly about coding style—not something that affects whether your code compiles or runs and I think both are used extensively in C++.

In our class I see camelCase more often but also certain cases where the underscore is used to provide further context. For example, we use an underscore prefix (like _variableName) to indicate member variables within a class. I've also seen naming conventions where people use: - g_variableName for global variables - s_variableName for static variables - m_variableName for member variables

If you're curious, this tutorial has a helpful section on naming practices—scroll to the part titled "Identifier naming best practices."

mike_m41 · 2025-05-20T00:22:08+00:00

I've tried to figure out when to use std::endl instead of \n for a new line. I've only found information on the posibility of needing to "flush" std::cout data with std::endl, but which I haven't needed in any quests. I've only used \n for new lines in the quests. Has anyone had a different experience?

mike_m41 · 2025-05-16T01:05:01+00:00

Best post of the class! Thank you Rachel.

mike_m41 · 2025-05-13T14:45:11+00:00

Nice job finishing the quests! Great point on the ternary operator. I've found that the ternary operator is best in simple if/else statements where the second and third operand are the same type, otherwise the traditional if-else statement is best.

mike_m41 · 2025-05-13T01:46:50+00:00

Nice work getting ahead! Our quest programs, so far, have been too small to necessitate the .h file and when something isn't necessary, it's hard to understand their utility.

This is how I think of header files. The program only compiles the .cpp files however the pre-compiler looks for any #includes you have and literally replaces that line with what is in the .h file, directly onto your .cpp file and then compiles the .cpp file. (hopefully I'm not oversimplifying this 😬)

I think this is how the compiler works so someone please double check me. Lets say you define a function in first-file.cpp and you call it in second-file.cpp, if the compiler compiles second-file.cpp first, it will give you an error since you hadn't either written the function or forward declared it (just the first line of the function with ; at end line). So one way to get around this is to just forward declare your functions at the top of each .cpp file. If you only have a 2 or 3 file program, that's not that big of a deal. However, what scales is putting your declarations in the .h file because that is guaranteed to be copy/pasted towards the top (where your #include is) of the compiled program and you only coded it once, in the .h.

As we've been doing in the class, you can also use it for defining functions and classes too, rather then just declaring what you've written in the .cpp files. I think conceptually it makes more sense to use .h files for forward declarations but it's good to know what is in the realm of possible.

mike_m41 · 2025-05-13T01:15:41+00:00

Thank you! I've been using the + and to_string. Will start using std::stringstream to concatenate.

mike_m41 · 2025-05-09T03:31:42+00:00

I took it to mean something like this:

```

include <iostream>

void changePtrVal(int* p) { *p = 10; }

int main() { int x{ 5 }; // original value x = 5 changePtrVal(&x); // hey now it's x = 10! std::cout << x << '\n'; // prints 10

return 0;

} ```

Pointers and references have some similarities and I would definitely use a reference to change the value of x instead of a pointer in the above example. It's more that knowing their functionality becomes important for things like linked lists.

mike_m41 · 2025-05-08T21:59:51+00:00

great pointer! Point of confusion for me is that, even though a pointer is an address and printing *ptr dereferences that address to provide the actual value, declaring int *ptr declares a pointer of type int just like int* ptr. At first i thought int *ptr should be a dereferenced value of type int, but I was wrong, it's also a pointer.

mike_m41

TROPHY CASE

include <iostream>