-
Notifications
You must be signed in to change notification settings - Fork 96
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create FairBaseTypes.h
#1410
base: dev
Are you sure you want to change the base?
Create FairBaseTypes.h
#1410
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this!
Here is a first set of comments to improve some parts.
fairroot/tools/FairBaseTypes.h
Outdated
} | ||
|
||
private: | ||
underlying_type fId; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's use default member initializers:
underlying_type fId; | |
underlying_type fId{std::numeric_limits<underlying_type>::max()}; |
fairroot/tools/FairBaseTypes.h
Outdated
|
||
EntryID(underlying_type value) : fId(value) {} | ||
|
||
EntryID() : EntryID(None) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Which simplifies the default constructor a lot.
EntryID() : EntryID(None) {} | |
EntryID() = default; |
fairroot/tools/FairBaseTypes.h
Outdated
struct EntryID { | ||
using underlying_type = size_t; | ||
|
||
static constexpr underlying_type None = std::numeric_limits<underlying_type>::max(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice, if None
would be of type EntryID
, right?
static constexpr underlying_type None = std::numeric_limits<underlying_type>::max(); | |
static const EntryID None; |
And add this after the closing }
of the class, but inside the namespace:
/// \sa https://stackoverflow.com/questions/29432283/c-static-constexpr-field-with-incomplete-type/50295183#50295183
inline constexpr const EntryID EntryID::None{};
fairroot/tools/FairBaseTypes.h
Outdated
|
||
namespace FairRoot { | ||
struct EntryID { | ||
using underlying_type = size_t; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like size_t
.
If you intend to use EntryId
as a member of a class that gets written to a ROOT file, you should consider using an integer with a fixed size, maybe uint32_t
or uint64_t
, or even some of the ROOT types.
If on the other hand, EntryID is strictly for runtime only use, then size_t
is fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first iteration of the Doxygen docs for the namespace is here. And the link to the current Doxygen build for this PR can be found here: https://github.com/FairRootGroup/FairRoot/pull/1410/checks (and click on Doxygen-Preview).
fairroot/tools/FairBaseTypes.h
Outdated
namespace FairRoot { | ||
struct EntryID { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider to add some Doxygen comments to the namespace and class?
namespace FairRoot { | |
struct EntryID { | |
/** | |
* \brief Main namespace for FairRoot classes / types | |
* | |
* All new public classes and types of FairRoot will be in this namespace. | |
* Note: Nost classes are still in no namespace. | |
*/ | |
namespace FairRoot { | |
/** | |
* \brief <What Entry is this ID meant for?> | |
*/ | |
struct EntryID | |
{ |
Created `namespace FairRoot` with `struct EntryID {size_t fId;}`. Should replace PR FairRootGroup#1405.
* All new public classes and types of FairRoot will be in this namespace. | ||
* Note: Nost classes are still in no namespace. | ||
*/ | ||
namespace FairRoot { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't we agree on a lowercase name for this?
namespace FairRoot { | |
namespace fairroot { |
If we didn't, I would still suggest to use lowercase. Checking the guidelines of Mozilla (upon which we base our clang-format), they seem to suggest lowercase: https://firefox-source-docs.mozilla.org/code-quality/coding-style/coding_style_cpp.html#c-namespaces
So do the Alice guidelines: https://rawgit.com/AliceO2Group/CodingGuidelines/master/naming_formatting.html?showone=Namespace_Names#Namespace_Names
For me it's more a personal preference. But one objective reason could be so they are distinguishable from class names.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, I will change it.
Soooo, what are the benefits of going full type here? What do we loose with a simpler: namespace fairroot
{
using EntryID = size_t;
} |
* \brief Main namespace for FairRoot classes / types | ||
* | ||
* All new public classes and types of FairRoot will be in this namespace. | ||
* Note: Nost classes are still in no namespace. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* Note: Nost classes are still in no namespace. | |
* Note: Most classes are still in no namespace. |
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. |
@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^^ |
/**Run for the given single entry*/ | ||
void Run(Long64_t entry); | ||
/**Run event reconstruction from event number NStart to event number NStop */ | ||
void RunEventReco(Int_t NStart, Int_t NStop); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we also should deprecated the int, int overloads first before removing them, right?
Replaced `Int_t` with the new type `EntryID` in `FairRun` and derived classes. Depracated `void FairRunAna::Run(Long64_t entry)`, which internally calls introduced `void RunSingle(FairRoot::EntryID entry);`.
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/ |
Are you also proposing to ultimately replace the |
? I cannot follow |
Created
namespace FairRoot
with
struct EntryID {size_t fId;}
.Should replace PR #1405.
Checklist: