Cpp guidelines

Passing arguments

We try to return all objects from functions using pairs or tuples:

int value;
bool flag = foo( argument, &value); // worse

std::pair<bool, int> result = foo( argument); // better

auto result = foo( argument); //even better

auto[flag, value] = foo( argument); // also nice

Integer types

We do not use predefined C++ types as they have bad-defined sizes. Instead, we use <infra/types.h> types:

• int8, int16, int32, int64
• uint8, uint16, uint32, uint64
• Addr — to represent guest machine address and derived types like address masks, BPU targets etc.

For the most of the cases you have to use uint32. Smaller types must be used only in two cases:

• when they are explicitly required — like keeping an array of bytes or performing sign extension.
• when you have to keep the data really dense — so far there are no such needs.

Namespaces

To avoid namespace pollution and possible interference between libraries (e.g. Boost and STL) constructions like using namespace std are strictly prohibited.

Type deduction

We use C++11 type deduction wherever possible:

auto inst = rp_decode_2_memory->read( cycle); // good
FuncInstr inst = rp_decode_2_memory->read( cycle); // worse

Memory management

We do not use 'new'/'delete', except the lower-level classes. Instead, RAII memory management classes should be used, see our manual for smart pointers.

void avoid()
{ 
    auto pointer = new MyClass(arg1, arg2);
    // ...
    delete pointer;
}

void prefer()
{
    auto pointer = std::make_unique<MyClass>(arg1, arg2);
}

Exceptions and error handling

We do not use C++ exceptions (try, catch, throw keywords). We are agreed with Google Code Style opinion on exceptions.

We distinguish between internal errors and external errors. Internal errors are errors inside simulator like passing -1 way to cache read function. These errors can be handled by C-style assert() and warning() macros

External errors are errors caused by incorrect user input, like unsupported instruction or invalid cache size setting. They must be reported to output with serr << ... << critical idiom.