Don't using namespace std;, as that can be harmful.

Instead, write out std::unt32_t, std::cout, std::memcpy etc. in full. Maintainers (future you, perhaps) will thank you for being clear which identifiers you're using, and you'll save yourself from embarrassment when the standard library adds more identifiers.

Don't mix diagnostic messages with output.

We should be using std::clog for these messages so they don't end up being processed by the consumer of the program.

Use initializers for class data members.

The constructors here allow the members to default-initialise, then assign values. Instead, we should be using the constructor's initializer list to populate these.

Use a larger indentation.

2 spaces per level is hard to distinguish. Most style guides recommend at least 4; Linux kernel style uses tabs instead (normally 8 per level).

An advantage of the larger indents is that they alert you to deeply-nested control structures - normally a sign that the code needs refactoring for easier comprehension.

And everything mentioned in G. Sliepen's review.

Don't using namespace std;, as that can be harmful.

Instead, write out std::uint32_t, std::cout, std::memcpy etc. in full. Maintainers (future you, perhaps) will thank you for being clear which identifiers you're using, and you'll save yourself from embarrassment when the standard library adds more identifiers.

Don't mix diagnostic messages with output.

We should be using std::clog for these messages so they don't end up being processed by the consumer of the program.

Use initializers for class data members.

The constructors here allow the members to default-initialise, then assign values. Instead, we should be using the constructor's initializer list to populate these.

Use a larger indentation.

2 spaces per level is hard to distinguish. Most style guides recommend at least 4; Linux kernel style uses tabs instead (normally 8 per level).

An advantage of the larger indents is that they alert you to deeply-nested control structures - normally a sign that the code needs refactoring for easier comprehension.

And everything mentioned in G. Sliepen's review.