Create `FairBaseTypes.h`

[karabowi]

Created namespace FairRoot with struct EntryID {size_t fId;}.

Should replace PR #1405.

---

Checklist:

• [x] Followed the Contributing Guidelines

[rbx]

Soooo, what are the benefits of going full type here?

What do we loose with a simpler:

namespace fairroot
{
using EntryID = size_t;
}

[dennisklein]

Soooo, what are the benefits of going full type here?

I guess, the idea would be to have safer-to-use and better-self-documenting function signatures (and call sites), e.g.

void RunReco(EntryID start, EntryID stop); // range [start, stop]
void RunReco(EntryID start, int n);        // range [start, start + n]
void RunReco(EntryID id);                  // single entry
void RunReco(int n);                       // n entries (starting from some implicit cursor)

With an alias it would be less clear what is meant and the compiler couldn't help you, if you misuse one of the signatures. (some overloads wouldn't even be possible). Now imagine argument lists with even more int args, where some are timeouts in seconds, different ids etc, easy to mess up the order when calling.

[dennisklein]

@rbx But I am not 100% convinced myself, if this is the best use case for a "strong alias". Especially, as there is already existing code using all kinds of int, uint, size_t etc for the same thing including serialized root files that need to be read back etc. Not sure, how much will break for the good or the worse^^

[dennisklein]

If we see a potential for more "strong aliases" like this one in the near future, we could adopt the templates proposed here: https://www.foonathan.net/2016/10/strong-typedefs/

[karabowi]

Soooo, what are the benefits of going full type here?

I guess, the idea would be to have safer-to-use and better-self-documenting function signatures (and call sites), e.g.

void RunReco(EntryID start, EntryID stop); // range [start, stop]
void RunReco(EntryID start, int n);        // range [start, start + n]
void RunReco(EntryID id);                  // single entry
void RunReco(int n);                       // n entries (starting from some implicit cursor)

With an alias it would be less clear what is meant and the compiler couldn't help you, if you misuse one of the signatures. (some overloads wouldn't even be possible). Now imagine argument lists with even more int args, where some are timeouts in seconds, different ids etc, easy to mess up the order when calling.

Are you also proposing to ultimately replace the Run() functions with RunReco()?

[dennisklein]

Soooo, what are the benefits of going full type here?

I guess, the idea would be to have safer-to-use and better-self-documenting function signatures (and call sites), e.g.

void RunReco(EntryID start, EntryID stop); // range [start, stop]
void RunReco(EntryID start, int n);        // range [start, start + n]
void RunReco(EntryID id);                  // single entry
void RunReco(int n);                       // n entries (starting from some implicit cursor)

With an alias it would be less clear what is meant and the compiler couldn't help you, if you misuse one of the signatures. (some overloads wouldn't even be possible). Now imagine argument lists with even more int args, where some are timeouts in seconds, different ids etc, easy to mess up the order when calling.

Are you also proposing to ultimately replace the Run() functions with RunReco()?

? I cannot follow