@@ -37,16 +37,15 @@ ROOT::RLogChannel &RFileLog();
3737## When and why should you use RFile
3838
3939RFile is a modern and minimalistic interface to ROOT files, both local and remote, that can be used instead of TFile
40- when the following conditions are met:
41- - you want a simple interface that makes it easy to do things right and hard to do things wrong;
42- - you only need basic Put/Get operations and don't need the more advanced TFile/TDirectory functionalities;
43- - you want more robustness and better error reporting for those operations;
44- - you want clearer ownership semantics expressed through the type system rather than having objects "automagically"
45- handled for you via implicit ownership of raw pointers.
40+ when you only need basic Put/Get operations and don't need the more advanced TFile/TDirectory functionalities.
41+ It provides:
42+ - a simple interface that makes it easy to do things right and hard to do things wrong;
43+ - more robustness and better error reporting for those operations;
44+ - clearer ownership semantics expressed through the type system.
4645
47- RFile doesn't try to cover the entirety of use cases covered by TFile/TDirectory/TDirectoryFile and is not
48- a 1:1 replacement for them. It is meant to simplify the most common use cases and make them easier to handle by
49- minimizing the amount of ROOT-specific quirks and conforming to more standard C++ practices.
46+ RFile doesn't cover the entirety of use cases covered by TFile/TDirectory/TDirectoryFile and is not
47+ a 1:1 replacement for them. It is meant to simplify the most common use cases by following newer standard C++
48+ practices.
5049
5150## Ownership model
5251
@@ -65,13 +64,11 @@ file).
6564
6665## Directories
6766
68- Differently from TFile, the RFile class itself is not also a "directory". In fact, there is no RDirectory class at all.
69-
70- Directories are still an existing concept in RFile (since they are a concept in the ROOT binary format),
71- but they are usually interacted with indirectly, via the use of filesystem-like string-based paths. If you Put an object
72- in an RFile under the path "path/to/object", "object" will be stored under directory "to" which is in turn stored under
73- directory "path". This hierarchy is encoded in the ROOT file itself and it can provide some optimization and/or
74- conveniencies when querying objects.
67+ Even though there is no equivalent of TDirectory in the RFile API, directories are still an existing concept in RFile
68+ (since they are a concept in the ROOT binary format). However they are for now only interacted with indirectly, via the
69+ use of filesystem-like string-based paths. If you Put an object in an RFile under the path "path/to/object", "object"
70+ will be stored under directory "to" which is in turn stored under directory "path". This hierarchy is encoded in the
71+ ROOT file itself and it can provide some optimization and/or conveniencies when querying objects.
7572
7673For the most part, it is convenient to think about RFile in terms of a key-value storage where string-based paths are
7774used to refer to arbitrary objects. However, given the hierarchical nature of ROOT files, certain filesystem-like
@@ -96,8 +93,11 @@ auto myObj = file->Get<TH1D>("h");
9693~~~
9794*/
9895class RFile final {
96+ // / Flags used in PutInternal()
9997 enum PutFlags {
98+ // / When encountering an object at the specified path, overwrite it with the new one instead of erroring out.
10099 kPutAllowOverwrite = 0x1 ,
100+ // / When overwriting an object, preserve the existing one and create a new cycle, rather than removing it.
101101 kPutOverwriteKeepCycle = 0x2 ,
102102 };
103103
0 commit comments