diff --git a/config/thisroot.csh b/config/thisroot.csh
index 89ddaa5c8dd4312a235197097c0f0f6108443dde..7d2d94cf3dfb70055d87055e1e2ce4a0a601481f 100644
--- a/config/thisroot.csh
+++ b/config/thisroot.csh
@@ -8,90 +8,90 @@
# Author: Fons Rademakers, 18/8/2006
if ($?ROOTSYS) then
- setenv OLD_ROOTSYS "$ROOTSYS"
+ set old_rootsys="$ROOTSYS"
endif
# $_ should be source .../thisroot.csh
set ARGS=($_)
if ("$ARGS" != "") then
- set THIS="`dirname ${ARGS[2]}`"
+ set thisroot="`dirname ${ARGS[2]}`"
else
# But $_ might not be set if the script is source non-interactively.
# In [t]csh the sourced file is inserted 'in place' inside the
# outer script, so we need an external source of information
# either via the current directory or an extra parameter.
if ( -e thisroot.csh ) then
- set THIS=${PWD}
- else if ( -e bin/thisroot.csh ) then
- set THIS=${PWD}/bin
+ set thisroot=${PWD}
+ else if ( -e bin/thisroot.csh ) then
+ set thisroot=${PWD}/bin
else if ( "$1" != "" ) then
if ( -e ${1}/bin/thisroot.csh ) then
- set THIS=${1}/bin
+ set thisroot=${1}/bin
else if ( -e ${1}/thisroot.csh ) then
- set THIS=${1}
- else
+ set thisroot=${1}
+ else
echo "thisroot.csh: ${1} does not contain a ROOT installation"
- endif
+ endif
else
echo 'Error: The call to "source where_root_is/bin/thisroot.csh" can not determine the location of the ROOT installation'
echo "because it was embedded another script (this is an issue specific to csh)."
echo "Use either:"
echo " cd where_root_is; source bin/thisroot.csh"
echo "or"
- echo " source where_root_is/bin/thisroot.csh where_root_is"
+ echo " source where_root_is/bin/thisroot.csh where_root_is"
endif
endif
-if ($?THIS) then
+if ($?thisroot) then
-setenv ROOTSYS "`(cd ${THIS}/..;pwd)`"
+setenv ROOTSYS "`(cd ${thisroot}/..;pwd)`"
-if ($?OLD_ROOTSYS) then
- setenv PATH `echo $PATH | sed -e "s;:$OLD_ROOTSYS/bin:;:;g" \
- -e "s;:$OLD_ROOTSYS/bin;;g" \
- -e "s;$OLD_ROOTSYS/bin:;;g" \
- -e "s;$OLD_ROOTSYS/bin;;g"`
+if ($?old_rootsys) then
+ setenv PATH `echo $PATH | sed -e "s;:$old_rootsys/bin:;:;g" \
+ -e "s;:$old_rootsys/bin;;g" \
+ -e "s;$old_rootsys/bin:;;g" \
+ -e "s;$old_rootsys/bin;;g"`
if ($?LD_LIBRARY_PATH) then
setenv LD_LIBRARY_PATH `echo $LD_LIBRARY_PATH | \
- sed -e "s;:$OLD_ROOTSYS/lib:;:;g" \
- -e "s;:$OLD_ROOTSYS/lib;;g" \
- -e "s;$OLD_ROOTSYS/lib:;;g" \
- -e "s;$OLD_ROOTSYS/lib;;g"`
+ sed -e "s;:$old_rootsys/lib:;:;g" \
+ -e "s;:$old_rootsys/lib;;g" \
+ -e "s;$old_rootsys/lib:;;g" \
+ -e "s;$old_rootsys/lib;;g"`
endif
if ($?DYLD_LIBRARY_PATH) then
setenv DYLD_LIBRARY_PATH `echo $DYLD_LIBRARY_PATH | \
- sed -e "s;:$OLD_ROOTSYS/lib:;:;g" \
- -e "s;:$OLD_ROOTSYS/lib;;g" \
- -e "s;$OLD_ROOTSYS/lib:;;g" \
- -e "s;$OLD_ROOTSYS/lib;;g"`
+ sed -e "s;:$old_rootsys/lib:;:;g" \
+ -e "s;:$old_rootsys/lib;;g" \
+ -e "s;$old_rootsys/lib:;;g" \
+ -e "s;$old_rootsys/lib;;g"`
endif
if ($?SHLIB_PATH) then
setenv SHLIB_PATH `echo $SHLIB_PATH | \
- sed -e "s;:$OLD_ROOTSYS/lib:;:;g" \
- -e "s;:$OLD_ROOTSYS/lib;;g" \
- -e "s;$OLD_ROOTSYS/lib:;;g" \
- -e "s;$OLD_ROOTSYS/lib;;g"`
+ sed -e "s;:$old_rootsys/lib:;:;g" \
+ -e "s;:$old_rootsys/lib;;g" \
+ -e "s;$old_rootsys/lib:;;g" \
+ -e "s;$old_rootsys/lib;;g"`
endif
if ($?LIBPATH) then
setenv LIBPATH `echo $LIBPATH | \
- sed -e "s;:$OLD_ROOTSYS/lib:;:;g" \
- -e "s;:$OLD_ROOTSYS/lib;;g" \
- -e "s;$OLD_ROOTSYS/lib:;;g" \
- -e "s;$OLD_ROOTSYS/lib;;g"`
+ sed -e "s;:$old_rootsys/lib:;:;g" \
+ -e "s;:$old_rootsys/lib;;g" \
+ -e "s;$old_rootsys/lib:;;g" \
+ -e "s;$old_rootsys/lib;;g"`
endif
if ($?PYTHONPATH) then
setenv PYTHONPATH `echo $PYTHONPATH | \
- sed -e "s;:$OLD_ROOTSYS/lib:;:;g" \
- -e "s;:$OLD_ROOTSYS/lib;;g" \
- -e "s;$OLD_ROOTSYS/lib:;;g" \
- -e "s;$OLD_ROOTSYS/lib;;g"`
+ sed -e "s;:$old_rootsys/lib:;:;g" \
+ -e "s;:$old_rootsys/lib;;g" \
+ -e "s;$old_rootsys/lib:;;g" \
+ -e "s;$old_rootsys/lib;;g"`
endif
if ($?MANPATH) then
setenv MANPATH `echo $MANPATH | \
- sed -e "s;:$OLD_ROOTSYS/man:;:;g" \
- -e "s;:$OLD_ROOTSYS/man;;g" \
- -e "s;$OLD_ROOTSYS/man:;;g" \
- -e "s;$OLD_ROOTSYS/man;;g"`
+ sed -e "s;:$old_rootsys/man:;:;g" \
+ -e "s;:$old_rootsys/man;;g" \
+ -e "s;$old_rootsys/man:;;g" \
+ -e "s;$old_rootsys/man;;g"`
endif
endif
@@ -99,7 +99,7 @@ endif
if ($?MANPATH) then
# Nothing to do
else
- # Grab the default man path before setting the path to avoid duplicates
+ # Grab the default man path before setting the path to avoid duplicates
if ( -X manpath ) then
set default_manpath = `manpath`
else
@@ -145,4 +145,8 @@ else
setenv MANPATH `dirname @mandir@`:$default_manpath
endif
-endif # if ("$THIS" != "")
+endif # if ("$thisroot" != "")
+
+set thisroot=
+set old_rootsys=
+
diff --git a/config/thisroot.sh b/config/thisroot.sh
index 066584caf23cda9d9177a94542e719edf3e178b2..adfd22a2111c8e4c4bd82a60398135044b368e09 100644
--- a/config/thisroot.sh
+++ b/config/thisroot.sh
@@ -25,7 +25,7 @@ drop_from_path()
}
if [ -n "${ROOTSYS}" ] ; then
- OLD_ROOTSYS=${ROOTSYS}
+ old_rootsys=${ROOTSYS}
fi
if [ "x${BASH_ARGV[0]}" = "x" ]; then
@@ -37,43 +37,43 @@ if [ "x${BASH_ARGV[0]}" = "x" ]; then
ROOTSYS="$PWD"; export ROOTSYS
else
# get param to "."
- THIS=$(dirname ${BASH_ARGV[0]})
- ROOTSYS=$(cd ${THIS}/..;pwd); export ROOTSYS
+ thisroot=$(dirname ${BASH_ARGV[0]})
+ ROOTSYS=$(cd ${thisroot}/..;pwd); export ROOTSYS
fi
-if [ -n "${OLD_ROOTSYS}" ] ; then
+if [ -n "${old_rootsys}" ] ; then
if [ -n "${PATH}" ]; then
- drop_from_path $PATH ${OLD_ROOTSYS}/bin
+ drop_from_path $PATH ${old_rootsys}/bin
PATH=$newpath
fi
if [ -n "${LD_LIBRARY_PATH}" ]; then
- drop_from_path $LD_LIBRARY_PATH ${OLD_ROOTSYS}/lib
+ drop_from_path $LD_LIBRARY_PATH ${old_rootsys}/lib
LD_LIBRARY_PATH=$newpath
fi
if [ -n "${DYLD_LIBRARY_PATH}" ]; then
- drop_from_path $DYLD_LIBRARY_PATH ${OLD_ROOTSYS}/lib
+ drop_from_path $DYLD_LIBRARY_PATH ${old_rootsys}/lib
DYLD_LIBRARY_PATH=$newpath
fi
if [ -n "${SHLIB_PATH}" ]; then
- drop_from_path $SHLIB_PATH ${OLD_ROOTSYS}/lib
+ drop_from_path $SHLIB_PATH ${old_rootsys}/lib
SHLIB_PATH=$newpath
fi
if [ -n "${LIBPATH}" ]; then
- drop_from_path $LIBPATH ${OLD_ROOTSYS}/lib
+ drop_from_path $LIBPATH ${old_rootsys}/lib
LIBPATH=$newpath
fi
if [ -n "${PYTHONPATH}" ]; then
- drop_from_path $PYTHONPATH ${OLD_ROOTSYS}/lib
+ drop_from_path $PYTHONPATH ${old_rootsys}/lib
PYTHONPATH=$newpath
fi
if [ -n "${MANPATH}" ]; then
- drop_from_path $MANPATH ${OLD_ROOTSYS}/man
+ drop_from_path $MANPATH ${old_rootsys}/man
MANPATH=$newpath
fi
fi
if [ -z "${MANPATH}" ]; then
- # Grab the default man path before setting the path to avoid duplicates
+ # Grab the default man path before setting the path to avoid duplicates
if `which manpath > /dev/null 2>&1` ; then
default_manpath=`manpath`
else
@@ -126,3 +126,7 @@ fi
if [ "x`root-config --arch | grep -v win32gcc | grep -i win32`" != "x" ]; then
ROOTSYS="`cygpath -w $ROOTSYS`"
fi
+
+unset old_rootsys
+unset thisroot
+
diff --git a/docbook/users-guide/CINT.md b/docbook/users-guide/CINT.md
index a40c5bd17bd74a56c303e0bad3ac565bdaa9db64..d997c70f4a5d84564ce27456f1a7bcc7527578c8 100644
--- a/docbook/users-guide/CINT.md
+++ b/docbook/users-guide/CINT.md
@@ -3,20 +3,21 @@
The subject of this chapter is CINT, ROOT command line interpreter and
script processor. First, we explain what CINT is and why ROOT uses it.
-Then we discuss CINT as the command line interpreter, the CINT commands,
-and CINT extensions to C++ are discussed. CINT as the script interpreter
-is explained and illustrated with several examples.
+Then we discuss CINT as the command line interpreter, the CINT
+commands, and CINT extensions to C++ are discussed. CINT as the script
+interpreter is explained and illustrated with several examples.
## What is CINT?
CINT, which is pronounced `['sint]`, is a C++ interpreter. An
-interpreter takes a program, in this case a C++ program, and carries it
-out by examining each instruction and in turn executing the equivalent
-sequence of machine language. For example, an interpreter translates and
-executes each statement in the body of a loop "n" times. It does not
-generate a machine language program. This may not be a good example,
-because most interpreters have become 'smart' about loop processing.
+interpreter takes a program, in this case a C++ program, and carries
+it out by examining each instruction and in turn executing the
+equivalent sequence of machine language. For example, an interpreter
+translates and executes each statement in the body of a loop "n"
+times. It does not generate a machine language program. This may not
+be a good example, because most interpreters have become 'smart' about
+loop processing.
A compiler on the other hand, takes a program and makes a machine
language executable. Once compiled the execution is very fast, which
@@ -27,29 +28,29 @@ ROOT for the first time (depending on the CPU). Once compiled it runs
very fast. On the average, a compiled program runs roughly ten times
faster than an interpreted one. Because compiling is slow, using a
compiler is cumbersome for rapid prototyping when one changes and
-rebuilds as often as once per minute. An interpreter, on the other hand,
-is the perfect tool for code that changes often and runs a few times.
-Most of the time, interpreters are built for scripting languages, such
-as JavaScript, IDL, or Python. These languages are specifically designed
-to be interpreted rather than compiled. The advantage of using a
-normally compiled language is that code can be compiled once the
-prototype is debugged and refined. CINT is a C++ interpreter, making it
-a tool for rapid prototyping and scripting in C++. It is also available
-as a stand-alone product, see <http://root.cern.ch/cint>. This page also
-has links to all the CINT documentation. The downloadable tar file
-contains documentation, the CINT executable, and many demo scripts that
-are not included in the regular ROOT distribution. Here is the list of
-CINT main features:
+rebuilds as often as once per minute. An interpreter, on the other
+hand, is the perfect tool for code that changes often and runs a few
+times. Most of the time, interpreters are built for scripting
+languages, such as JavaScript, IDL, or Python. These languages are
+specifically designed to be interpreted rather than compiled. The
+advantage of using a normally compiled language is that code can be
+compiled once the prototype is debugged and refined. CINT is a C++
+interpreter, making it a tool for rapid prototyping and scripting in
+C++. It is also available as a stand-alone product, see
+<http://root.cern.ch/cint>. This page also has links to all the CINT
+documentation. The downloadable tar file contains documentation, the
+CINT executable, and many demo scripts that are not included in the
+regular ROOT distribution. Here is the list of CINT main features:
- Supports K&R-C, ANSI-C, and ANSI-C++
-- CINT covers 85-95% of the C++, ANSI-C and K&R-C language constructs.
- It supports multiple inheritance, virtual function, function
- overloading, operator overloading, default parameters, templates,
- and much more. CINT is robust enough to interpret its own source
- code. CINT is not designed to be a 100% ANSI/ISO compliant C++
- language processor. It is a portable scripting language environment,
- which is close enough to the standard C++.
+- CINT covers 85-95% of the C++, ANSI-C and K&R-C language
+ constructs. It supports multiple inheritance, virtual function,
+ function overloading, operator overloading, default parameters,
+ templates, and much more. CINT is robust enough to interpret its
+ own source code. CINT is not designed to be a 100% ANSI/ISO
+ compliant C++ language processor. It is a portable scripting
+ language environment, which is close enough to the standard C++.
- Interprets Large C/C++ source code
@@ -62,20 +63,20 @@ CINT main features:
- Depending on the need for execution speed or the need for
interaction, one can mix native code execution and interpretation.
"`makecint`" encapsulates arbitrary C/C++ objects as precompiled
- libraries. A precompiled library can be configured as a dynamically
- linked library. Accessing interpreted code and precompiled code can
- be done seamlessly in both directions.
+ libraries. A precompiled library can be configured as a
+ dynamically linked library. Accessing interpreted code and
+ precompiled code can be done seamlessly in both directions.
- Provides a Single-Language solution
-- `CINT/makecint` is a single-language environment. It works with any
- ANSI-C/C++ compiler to provide the interpreter environment on top of
- it.
+- `CINT/makecint` is a single-language environment. It works with
+ any ANSI-C/C++ compiler to provide the interpreter environment on
+ top of it.
- Simplifies C++
-- CINT is meant to bring C++ to the non-software professional. C++ is
- simpler to use in the interpreter environment. It helps the
+- CINT is meant to bring C++ to the non-software professional. C++
+ is simpler to use in the interpreter environment. It helps the
non-software professional (the domain expert) to talk the same
language as the software counterpart.
@@ -84,7 +85,8 @@ CINT main features:
- CINT can process C++ statements from command line, dynamically
define/erase class definition and functions; load/unload source
files and libraries. Extended Run Time Type Identification is
- provided, allowing you to explore imaginative new ways of using C++.
+ provided, allowing you to explore imaginative new ways of using
+ C++.
- CINT has a built-in debugger for complex C++ code and a text based
class browser is part of it.
@@ -92,9 +94,9 @@ CINT main features:
- It is portable.
- CINT works on number of operating systems: `HP-UX`, `Linux`,
- `SunOS`, `Solaris`, `AIX`, `Alpha-OSF`, `IRIX`, `FreeBSD`, `NetBSD`,
- `NEC` `EWS4800`, `NewsOS`, `BeBox`, `WindowsNT`, `Windows9x`,
- `MS-DOS`, `MacOS`, `VMS`, `NextStep`, `Convex`.
+ `SunOS`, `Solaris`, `AIX`, `Alpha-OSF`, `IRIX`, `FreeBSD`,
+ `NetBSD`, `NEC` `EWS4800`, `NewsOS`, `BeBox`, `WindowsNT`,
+ `Windows9x`, `MS-DOS`, `MacOS`, `VMS`, `NextStep`, `Convex`.
## The ROOT Command Line Interface
@@ -144,8 +146,8 @@ root[] .g
Here we note:
-- Terminating with 鈥榒;`鈥� is not required, see "ROOT/CINT Extensions to
- C++".
+- Terminating with 鈥榒;`鈥� is not required, see "ROOT/CINT Extensions
+ to C++".
- `Emacs` style command line editing.
@@ -172,11 +174,12 @@ List of member function--------------------------
filename line:size busy function type and name (in TLine)
(compiled) 0:0 0 public: virtual void ~TLine(void);
(compiled) 0:0 0 public: TLine TLine(void);
-(compiled) 0:0 0 public: TLine TLine(Double_t x1,Double_t y1,Double_t x2,
-Double_t y2);
+(compiled) 0:0 0 public: TLine TLine(Double_t x1,Double_t y1,
+ Double_t x2,Double_t y2);
(compiled) 0:0 0 public: TLine TLine(const TLine& line);
(compiled) 0:0 0 public: virtual void Copy(TObject& line) const;
-(compiled) 0:0 0 public: virtual Int_t DistancetoPrimitive(Int_t px,Int_t py);
+(compiled) 0:0 0 public: virtual Int_t DistancetoPrimitive(
+ Int_t px,Int_t py);
...
(compiled) 0:0 0 public: static int ImplFileLine(void);
(compiled) 0:0 0 public: static const char* ImplFileName(void);
@@ -220,7 +223,7 @@ Here we note:
- A multi-line command starts with a { and ends with a }.
-- Every line has to be correctly terminated with a ; (like in "real''
+- Every line has to be correctly terminated with a ; (like in "real''
C++).
- All objects are created in *global*scope.
@@ -239,19 +242,19 @@ above, but also arbitrarily complex class and function definitions.
### Un-named Scripts
-Let us start with a script containing a simple list of statements (like
-the multi-command line example given in the previous section). This type
-of script must start with a { and end with a } and is called an un-named
-script. Assume the file is called `script1.C`
+Let us start with a script containing a simple list of statements
+(like the multi-command line example given in the previous section).
+This type of script must start with a { and end with a } and is called
+an un-named script. Assume the file is called `script1.C`
``` {.cpp}
{
#include <iostream.h>
-cout << " Hello" << endl;
-float x = 3.;
-float y = 5.;
-int i = 101;
-cout <<" x = "<<x<<" y = "<<y<<" i = "<<i<< endl;
+ cout << " Hello" << endl;
+ float x = 3.;
+ float y = 5.;
+ int i = 101;
+ cout <<" x = "<<x<<" y = "<<y<<" i = "<<i<< endl;
}
```
@@ -261,11 +264,12 @@ To execute the stream of statements in `script1.C` do:
root[] .x script1.C
```
-This loads the contents of file `script1.C` and executes all statements
-in the interpreter's global scope. One can re-execute the statements by
-re-issuing "`.x script1.C`" (since there is no function entry point).
-Scripts are searched for in the `Root.MacroPath` as defined in your
-`.rootrc` file. To check which script is being executed use:
+This loads the contents of file `script1.C` and executes all
+statements in the interpreter's global scope. One can re-execute the
+statements by re-issuing "`.x script1.C`" (since there is no function
+entry point). Scripts are searched for in the `Root.MacroPath` as
+defined in your `.rootrc` file. To check which script is being
+executed use:
``` {.cpp}
root[] .which script1.C
@@ -313,10 +317,10 @@ script2.C 4:9 0 public: int run();
The last command shows that `run()` has been loaded from file
`script2.C`, that the function `run()` starts on line 4 and is 9 lines
-long. Notice that once a function has been loaded it becomes part of the
-system just like a compiled function. Now we copy the file `script2.C`
-to the `script3.C` and change the function name from `run()` to
-`script3(int j = 10)`:
+long. Notice that once a function has been loaded it becomes part of
+the system just like a compiled function. Now we copy the file
+`script2.C` to the `script3.C` and change the function name from
+`run()` to `script3(int j = 10)`:
``` {.cpp}
#include <iostream.h>
@@ -353,15 +357,16 @@ x = 3, y = 5, i = 33
(int)0
```
-In a named script, the objects created on the stack are deleted when the
-function exits. For example, this scenario is very common. You create a
-histogram in a named script on the stack. You draw the histogram, but
-when the function exits the canvas is empty and the histogram
-disappeared. To avoid histogram from disappearing you can create it on
-the heap (by using new). This will leave the histogram object intact,
-but the pointer in the named script scope will be deleted. Since
-histograms (and trees) are added to the list of objects in the current
-directory, you can always retrieve them to delete them if needed.
+In a named script, the objects created on the stack are deleted when
+the function exits. For example, this scenario is very common. You
+create a histogram in a named script on the stack. You draw the
+histogram, but when the function exits the canvas is empty and the
+histogram disappeared. To avoid histogram from disappearing you can
+create it on the heap (by using new). This will leave the histogram
+object intact, but the pointer in the named script scope will be
+deleted. Since histograms (and trees) are added to the list of objects
+in the current directory, you can always retrieve them to delete them
+if needed.
``` {.cpp}
root[] TH1F *h = (TH1F*)gDirectory->Get("myHist"); // or
@@ -375,53 +380,54 @@ clean up. See "Input/Output".
### Executing a Script from a Script
-You may want to execute a script conditionally inside another script. To
-do it you need to call the interpreter and you can do that with
+You may want to execute a script conditionally inside another script.
+To do it you need to call the interpreter and you can do that with
**`TROOT::ProcessLine()`**. The example
`$ROOTSYS/tutorials/tree/cernstaff.C` calls a script to build the root
file if it does not exist:
``` {.cpp}
void cernstaff() {
- if (gSystem->AccessPathName("cernstaff.root")) {
+ if (gSystem->AccessPathName("cernstaff.root")) {
gROOT->ProcessLine(".x cernbuild.C");
}
```
-`ProcessLine` takes a parameter, which is a pointer to an `int` or to a
-**`TInterpreter`**`::EErrorCode` to let you access the CINT error code
-after an attempt to interpret. This will contain the CINT error as
-defined in `enum` `TInterpreter::EErrorCode`.
+`ProcessLine` takes a parameter, which is a pointer to an `int` or to
+a **`TInterpreter`**`::EErrorCode` to let you access the CINT error
+code after an attempt to interpret. This will contain the CINT error
+as defined in `enum` `TInterpreter::EErrorCode`.
## Resetting the Interpreter Environment
-Variables created on the command line and in un-named scripts are in the
-interpreter's global scope, which makes the variables created in
-un-named scripts available on the command line event after the script is
-done executing. This is the opposite of a named script where the stack
-variables are deleted when the function in which they are defined has
-finished execution.
+Variables created on the command line and in un-named scripts are in
+the interpreter's global scope, which makes the variables created in
+un-named scripts available on the command line event after the script
+is done executing. This is the opposite of a named script where the
+stack variables are deleted when the function in which they are
+defined has finished execution.
When running an un-named script over again and this is frequently the
-case since un-named scripts are used to prototype, one should reset the
-global environment to clear the variables. This is done by calling
+case since un-named scripts are used to prototype, one should reset
+the global environment to clear the variables. This is done by calling
`gROOT->Reset()`. It is good practice, and you will see this in the
examples, to begin an un-named script with `gROOT->Reset()`. It clears
-the global scope to the state just before executing the previous script
-(not including any logon scripts). The `gROOT->Reset()` calls the
-destructor of the objects if the object was created on the stack. If the
-object was created on the heap (via new) it is not deleted, but the
-variable is no longer associated with it. Creating variables on the heap
-in un-named scripts and calling `gROOT->Reset()` without you calling the
-destructor explicitly will cause a memory leak. This may be surprising,
-but it follows the scope rules. For example, creating an object on the
-heap in a function (in a named script) without explicitly deleting it
-will also cause a memory leak. Since when exiting the function only the
-stack variables are deleted. The code below shows `gROOT->Reset()`
-calling the destructor for the stack variable, but not for the heap
-variable. In the end, neither variable is available, but the memory for
-the heap variable is not released. Here is an example:
+the global scope to the state just before executing the previous
+script (not including any logon scripts). The `gROOT->Reset()` calls
+the destructor of the objects if the object was created on the stack.
+If the object was created on the heap (via new) it is not deleted, but
+the variable is no longer associated with it. Creating variables on
+the heap in un-named scripts and calling `gROOT->Reset()` without you
+calling the destructor explicitly will cause a memory leak. This may
+be surprising, but it follows the scope rules. For example, creating
+an object on the heap in a function (in a named script) without
+explicitly deleting it will also cause a memory leak. Since when
+exiting the function only the stack variables are deleted. The code
+below shows `gROOT->Reset()` calling the destructor for the stack
+variable, but not for the heap variable. In the end, neither variable
+is available, but the memory for the heap variable is not released.
+Here is an example:
``` {.cpp}
root[] gDebug = 1
@@ -449,10 +455,12 @@ variable.
``` {.cpp}
root[] stackVar
-Error: No symbol stackVar in current scope FILE:/var/tmp/faaa01jWe_cint LINE:1
+Error: No symbol stackVar in current scope
+FILE:/var/tmp/faaa01jWe_cint LINE:1
*** Interpreter error recovered ***
root[] heapVar
-Error: No symbol heapVar in current scope FILE:/var/tmp/gaaa01jWe_cint LINE:1
+Error: No symbol heapVar in current scope
+FILE:/var/tmp/gaaa01jWe_cint LINE:1
*** Interpreter error recovered ***
```
@@ -465,8 +473,8 @@ root[] gROOT->FindObject("heap.root")
(class TObject*)0x106bfb30
```
-The object on the stack is deleted and shows a null pointer when we do a
-`FindObject`. However, the heap object is still around and taking up
+The object on the stack is deleted and shows a null pointer when we do
+a `FindObject`. However, the heap object is still around and taking up
memory.
Note `gROOT->Reset()` should be never called in a named script or a
@@ -483,27 +491,27 @@ Lets create a small class **`TMyClass`** and a derived class
#include <iostream.h>
class TMyClass {
-private:
-float fX; //x position in centimeters
-float fY; //y position in centimeters
-public:
-TMyClass() { fX = fY = -1; }
-virtual void Print() const;
-void SetX(float x) { fX = x; }
-void SetY(float y) { fY = y; }
+ private:
+ float fX; //x position in centimeters
+ float fY; //y position in centimeters
+ public:
+ TMyClass() { fX = fY = -1; }
+ virtual void Print() const;
+ void SetX(float x) { fX = x; }
+ void SetY(float y) { fY = y; }
};
void TMyClass::Print() const // parent print method
{
-cout << "fX = " << fX << ", fY = " << fY << endl;
+ cout << "fX = " << fX << ", fY = " << fY << endl;
}
class TChild : public TMyClass {
-public:
-void Print() const;
+ public:
+ void Print() const;
};
void TChild::Print() const // child print metod
{
-cout << "This is TChild::Print()" << endl;
-TMyClass::Print();
+ cout << "This is TChild::Print()" << endl;
+ TMyClass::Print();
}
```
@@ -539,7 +547,8 @@ script4.C 13:1 0 public: void SetY(float y);
root[] .q
```
-As you can see, an interpreted class behaves just like a compiled class.
+As you can see, an interpreted class behaves just like a compiled
+class.
There are some limitations for a class created in a script:
@@ -547,9 +556,9 @@ There are some limitations for a class created in a script:
cannot patch the virtual table of compiled objects to reference
interpreted objects.
-- Because the I/O is encapsulated in **`TObject`** and a class defined
- in a script cannot inherit from **`TObject`**, it cannot be written
- to a ROOT file.
+- Because the I/O is encapsulated in **`TObject`** and a class
+ defined in a script cannot inherit from **`TObject`**, it cannot
+ be written to a ROOT file.
See "Adding a Class" for ways how to add a class with a shared library
and with ACLiC.
@@ -557,10 +566,10 @@ and with ACLiC.
## Debugging Scripts
-A powerful feature of CINT is the ability to debug interpreted functions
-by means of setting breakpoints and being able to single step through
-the code and print variable values on the way. Assume we have
-`script4.C` still loaded, we can then do:
+A powerful feature of CINT is the ability to debug interpreted
+functions by means of setting breakpoints and being able to single
+step through the code and print variable values on the way. Assume we
+have `script4.C` still loaded, we can then do:
``` {.cpp}
root[] .b TChild::Print
@@ -613,15 +622,15 @@ root[] TFile f("staff.root")
root[] f.Inspect()
```
-You can see the pointers are in red and can be clicked on to follow the
-pointer to the object. If you clicked on `fList`, the list of objects in
-memory and there were none, no new canvas would be shown. On top of the
-page are the navigation buttons to see the previous and next screen.
+You can see the pointers are in red and can be clicked on to follow
+the pointer to the object. If you clicked on `fList`, the list of
+objects in memory and there were none, no new canvas would be shown.
+On top of the page are the navigation buttons to see the previous and
+next screen.
-
+
## ROOT/CINT Extensions to C++
@@ -646,27 +655,27 @@ Warning in <MakeDefCanvas>: creating a default canvas with name c1
root[] .q
```
-The *first* command shows the first extension; the declaration of f may
-be omitted when **"**`new`**"** is used. CINT will correctly create f as
-pointer to object of class **`TFile`**.
+The *first* command shows the first extension; the declaration of `f`
+may be omitted when **"**`new`**"** is used. CINT will correctly
+create `f` as pointer to object of class **`TFile`**.
-The *second* extension is shown in the second command. Although f is a
-pointer to **`TFile`** we don't have to use the pointer de-referencing
-syntax "`->`" but can use the simple "." notation.
+The *second* extension is shown in the second command. Although `f` is
+a pointer to **`TFile`** we don't have to use the pointer
+de-referencing syntax "`->`" but can use the simple "." notation.
The *third* extension is more important. In case CINT cannot find an
object being referenced, it will ask ROOT to search for an object with
an identical name in the search path defined by `TROOT::FindObject()`.
-If ROOT finds the object, it returns CINT a pointer to this object and a
-pointer to its class definition and CINT will execute the requested
+If ROOT finds the object, it returns CINT a pointer to this object and
+a pointer to its class definition and CINT will execute the requested
member function. This shortcut is quite natural for an interactive
system and saves much typing. In this example, ROOT searches for `hpx`
and finds it in `simple.root.`
-The *fourth* is shown below. There is no need to put a semicolon at the
-end of a line. The difference between having it and leaving it off is
-that when you leave it off the return value of the command will be
-printed on the next line. For example:
+The *fourth* is shown below. There is no need to put a semicolon at
+the end of a line. The difference between having it and leaving it
+off is that when you leave it off the return value of the command will
+be printed on the next line. For example:
``` {.cpp}
root[] 23+5 // no semicolon prints the return value
@@ -675,10 +684,11 @@ root[] 23+5; // semicolon no return value is printed
root[]
```
-Be aware that these extensions do not work when a compiler replaces the
-interpreter. Your code will not compile, hence when writing large
-scripts, it is best to stay away from these shortcuts. It will save you
-from having problems compiling your scripts using a real C++ compiler.
+Be aware that these extensions do not work when a compiler replaces
+the interpreter. Your code will not compile, hence when writing large
+scripts, it is best to stay away from these shortcuts. It will save
+you from having problems compiling your scripts using a real C++
+compiler.
## ACLiC - The Automatic Compiler of Libraries for CINT
@@ -713,28 +723,31 @@ root[] .files
*file="/home/./MyScript_C.so"
```
-The + option generates the shared library and names it by taking the
-name of the file "filename" but replacing the dot before the extension
-by an underscore and by adding the shared library extension for the
-current platform. For example on most platforms, `hsimple.cxx` will
-generate `hsimple_cxx.so`. If we execute a `.files` command we can see
-the newly created shared library is in the list of loaded files.
+The + option generates the shared library and names it by taking
+the name of the file "filename" but replacing the dot before the
+extension by an underscore and by adding the shared library extension
+for the current platform. For example on most platforms, `hsimple.cxx`
+will generate `hsimple_cxx.so`. If we execute a `.files` command we
+can see the newly created shared library is in the list of loaded
+files.
-The + command rebuild the library only if the script or any of the files
-it includes are newer than the library. When checking the timestamp,
-ACLiC generates a dependency file which name is the same as the library
-name, just replacing the 'so' extension by the extension '`d`'. For
-example on most platforms, `hsimple.cxx` will generate `hsimple_cxx.d`.
+The + command rebuild the library only if the script or any of the
+files it includes are newer than the library. When checking the
+timestamp, ACLiC generates a dependency file which name is the same as
+the library name, just replacing the 'so' extension by the extension
+'`d`'. For example on most platforms, `hsimple.cxx` will generate
+`hsimple_cxx.d`.
-To ensure that the shared library is rebuilt you can use the ++ syntax:
+To ensure that the shared library is rebuilt you can use the ++
+syntax:
``` {.cpp}
root[] .L MyScript.C++
```
-To build, load, and execute the function with the same name as the file
-you can use the `.x` command. This is the same as executing a named
-script. You can have parameters and use `.x `or `.X`. The only
+To build, load, and execute the function with the same name as the
+file you can use the `.x` command. This is the same as executing a
+named script. You can have parameters and use `.x `or `.X`. The only
difference is you need to append a + or a ++.
``` {.cpp}
@@ -742,25 +755,25 @@ root[] .x MyScript.C+ (4000)
Creating shared library /home/./MyScript_C.so
```
-You can select whether the script in compiled with debug symbol or with
-optimization by appending the letter 'g' or 'O' after the '+' or '++'.
-Without the specification, the script is compiled with the same level of
-debugging symbol and optimization as the currently running ROOT
-executable. For example:
+You can select whether the script in compiled with debug symbol or
+with optimization by appending the letter 'g' or 'O' after the '+' or
+'++'. Without the specification, the script is compiled with the same
+level of debugging symbol and optimization as the currently running
+ROOT executable. For example:
``` {.cpp}
root[] .L MyScript.C++g
```
-will compile `MyScript.C` with debug symbols; usually this means giving
-the `-g` option to compiler.
+will compile `MyScript.C` with debug symbols; usually this means
+giving the `-g` option to compiler.
``` {.cpp}
root[] .L MyScript.C++O
```
-will compile `MyScript.C` with optimizations; usually this means giving
-the `-O` option to compiler. The syntax:
+will compile `MyScript.C` with optimizations; usually this means
+giving the `-O` option to compiler. The syntax:
``` {.cpp}
root[] .L MyScript.C++
@@ -784,10 +797,11 @@ root[] .L MyScript.C+O
respectively compile `MyScript.C` with debug and optimization if the
library does not exist yet; they will not change the debug and the
-optimization level if the library already exist and it is up to date. To
-use ACLiC from compiled code or from inside another macro, we recommend
-using the `ProcessLine``()` method of **`TROOT`**. For example, in one
-script you can use ACLiC to compile and load another script.
+optimization level if the library already exist and it is up to date.
+To use ACLiC from compiled code or from inside another macro, we
+recommend using the `ProcessLine``()` method of **`TROOT`**. For
+example, in one script you can use ACLiC to compile and load another
+script.
``` {.cpp}
gROOT->ProcessLine(".L MyScript.C+")
@@ -830,24 +844,24 @@ something like:
gSystem->AddLinkedLibs("-L/my/path -lanylib");
```
-This is especially useful for static libraries. For shared ones you can
-also simply load them before trying to compile the script:
+This is especially useful for static libraries. For shared ones you
+can also simply load them before trying to compile the script:
``` {.cpp}
gSystem->Load("mydir/mylib");
```
-ACLiC uses the directive `fMakeSharedLibs` to create the shared library.
-If loading the shared library fails, it tries to output a list of
-missing symbols by creating an executable (on some platforms like OSF,
-this does not HAVE to be an executable) containing the script. It uses
-the directive `fMakeExe` to do so. For both directives, before passing
-them to `TSystem::Exec()`, it expands the variables `$SourceFiles`,
-`$SharedLib`, `$LibName`, `$IncludePath`, `$LinkedLibs`,
-`$ExeName `and` $ObjectFiles`. See `SetMakeSharedLib()` for more
-information on those variables. When the file being passed to ACLiC is
-on a read only file system, ACLiC warns the user and creates the library
-in a temporary directory:
+ACLiC uses the directive `fMakeSharedLibs` to create the shared
+library. If loading the shared library fails, it tries to output a
+list of missing symbols by creating an executable (on some platforms
+like OSF, this does not HAVE to be an executable) containing the
+script. It uses the directive `fMakeExe` to do so. For both
+directives, before passing them to `TSystem::Exec()`, it expands the
+variables `$SourceFiles`, `$SharedLib`, `$LibName`, `$IncludePath`,
+`$LinkedLibs`, `$ExeName `and` $ObjectFiles`. See `SetMakeSharedLib()`
+for more information on those variables. When the file being passed to
+ACLiC is on a read only file system, ACLiC warns the user and creates
+the library in a temporary directory:
``` {.cpp}
root[] .L readonly/t.C++
@@ -859,17 +873,17 @@ Info in <TUnixSystem::ACLiC>: creating shared library
To select the temporary directory ACLiC looks at `$TEMP`, `$TEMP_DIR`,
`$TEMPDIR`, `$TMP`, `$TMPDIR`, `$TMP_DIR `or uses `/tmp (`or `C:/)`.
-Also, a new interface **`TSystem`**`::Get/SetBuildDir` is introduced to
-let users select an alternative 'root' for building of the ACLiC
+Also, a new interface **`TSystem`**`::Get/SetBuildDir` is introduced
+to let users select an alternative 'root' for building of the ACLiC
libraries. For `filename``/full/path/name/macro.C`, the library is
created as `fBuildDir``/full/path/name/macro_C.so.`
### Dictionary Generation
-You can direct what is added to the dictionary generated by ACLiC in two
-ways. The simplest way is to add at the end of script (i.e. after the
-symbols have been defined) something like:
+You can direct what is added to the dictionary generated by ACLiC in
+two ways. The simplest way is to add at the end of script (i.e. after
+the symbols have been defined) something like:
``` {.cpp}
#if defined(__MAKECINT__)
@@ -878,15 +892,15 @@ symbols have been defined) something like:
```
You can also write this portion of code in a file name
-`MyScript_linkdef.h` where the suffix `'_linkdef' `is the prefix defined
-by the key `鈥楢CLiC.Linkdef`鈥� in the currently used resource file
-(usually `.rootrc `or` $ROOTSYS/etc/system.rootrc`) and the prefix is
-the name of your script.
+`MyScript_linkdef.h` where the suffix `'_linkdef' `is the prefix
+defined by the key `鈥楢CLiC.Linkdef`鈥� in the currently used resource
+file (usually `.rootrc `or` $ROOTSYS/etc/system.rootrc`) and the
+prefix is the name of your script.
-In ROOT 3.05/03 and above, the default behavior of `rootcint` is to not
-link in (i.e. generate the dictionary for) any of the symbols. In
-particular, this means that the following lines are now, in the general
-case, unnecessary.
+In ROOT 3.05/03 and above, the default behavior of `rootcint` is to
+not link in (i.e. generate the dictionary for) any of the symbols. In
+particular, this means that the following lines are now, in the
+general case, unnecessary.
``` {.cpp}
#pragma link off all globals;
@@ -900,10 +914,10 @@ This also means that linking the instantiation of a class template:
#pragma link C++ class mytemplate<int>;
```
-ONLY links this specific class. In previous versions of ROOT, depending
-on many factors, this might also have included the linking of many other
-instantiation of class template used directly or indirectly by
-`'mytemplate'`.
+ONLY links this specific class. In previous versions of ROOT,
+depending on many factors, this might also have included the linking
+of many other instantiation of class template used directly or
+indirectly by `'mytemplate'`.
A typical case would have been to rely on:
@@ -911,30 +925,31 @@ A typical case would have been to rely on:
#pragma link C++ class vector<MyClass>;
```
-to also induce the generation of the iterators. You now need to request
-them explicitly. Another advantage of the change is that now, if you
-omit the 'pragma link off' line from your `linkdef` file, you can
-actually sprinkle the 'pragma link C++ class' across as many of you
-header as file as you need.
+to also induce the generation of the iterators. You now need to
+request them explicitly. Another advantage of the change is that now,
+if you omit the 'pragma link off' line from your `linkdef` file, you
+can actually sprinkle the 'pragma link C++ class' across as many of
+you header as file as you need.
See the documentation of `rootcint` for details how `pragma` can be
used.
-NOTE: You should not call ACLiC with a script that has a function called
-`main()``.` When ACLiC calls `rootcint` with a function called `main` it
-tries to add every symbol it finds while parsing the script and the
-header files to the dictionary. This includes the system header files
-and the ROOT header files. It will result in duplicate entries at best
-and crashes at worst, because some classes in ROOT need special
-attention before they can be added to the dictionary.
+NOTE: You should not call ACLiC with a script that has a function
+called `main()``.` When ACLiC calls `rootcint` with a function called
+`main` it tries to add every symbol it finds while parsing the script
+and the header files to the dictionary. This includes the system
+header files and the ROOT header files. It will result in duplicate
+entries at best and crashes at worst, because some classes in ROOT
+need special attention before they can be added to the dictionary.
### Intermediate Steps and Files
ACLiC executes two steps and a third one if needed. These are:
-- Calling `rootcint` to create a CINT dictionary. `rootcint` is a ROOT
- specific version of `makecint`, CINT generic dictionary generator.
+- Calling `rootcint` to create a CINT dictionary. `rootcint` is a
+ ROOT specific version of `makecint`, CINT generic dictionary
+ generator.
- Calling the compiler to build the shared library from the script
@@ -942,26 +957,28 @@ ACLiC executes two steps and a third one if needed. These are:
executable to report clearly unresolved symbols.
ACLiC makes a shared library with a CINT dictionary containing the
-classes and functions declared in the script. It also adds the classes
-and functions declared in included files with the same name as the
-script file and any of the following extensions: `.h`, `.hh`, `.hpp`,
-`.hxx`, `.hPP`, `.hXX`. This means that, by default, you cannot combine
-scripts from different files into one library by using `#include`
-statements; you will need to compile each script separately. In a future
-release, we plan to add the global variables declared in the script to
-the dictionary also. If you are curious about the specific calls, you
-can raise the ROOT debug level: gDebug=3 and ACLiC will print these
-steps. If you need to keep the intermediate files around, for example
-when debugging the script using gdb, use gDebug=7.
+classes and functions declared in the script. It also adds the
+classes and functions declared in included files with the same name
+as the script file and any of the following extensions: `.h`, `.hh`,
+`.hpp`, `.hxx`, `.hPP`, `.hXX`. This means that, by default, you
+cannot combine scripts from different files into one library by using
+`#include` statements; you will need to compile each script
+separately. In a future release, we plan to add the global variables
+declared in the script to the dictionary also. If you are curious
+about the specific calls, you can raise the ROOT debug level: gDebug=3
+and ACLiC will print these steps. If you need to keep the intermediate
+files around, for example when debugging the script using gdb, use
+gDebug=7.
### Moving between Interpreter and Compiler
-The best way to develop portable scripts is to make sure you can always
-run them with both, the interpreter and with ACLiC. To do so, do not use
-the CINT extensions and program around the CINT limitations. When it is
-not possible or desirable to program around the CINT limitations, you
-can use the C preprocessor symbols defined for CINT and `rootcint`.
+The best way to develop portable scripts is to make sure you can
+always run them with both, the interpreter and with ACLiC. To do so,
+do not use the CINT extensions and program around the CINT
+limitations. When it is not possible or desirable to program around
+the CINT limitations, you can use the C preprocessor symbols defined
+for CINT and `rootcint`.
The preprocessor symbol `__CINT__` is defined for both CINT and
`rootcint`. The symbol `__MAKECINT__` is only defined in `rootcint`.
@@ -970,10 +987,10 @@ Use `!defined(__CINT__) || defined(__MAKECINT__)` to bracket code that
needs to be seen by the compiler and `rootcint`, but will be invisible
to the interpreter.
-Use `!defined(__CINT__) `to bracket code that should be seen only by the
-compiler and not by CINT or `rootcint. `For example, the following will
-hide the declaration and initialization of the array `gArray` from both
-CINT and `rootcint`.
+Use `!defined(__CINT__) `to bracket code that should be seen only by
+the compiler and not by CINT or `rootcint. `For example, the following
+will hide the declaration and initialization of the array `gArray`
+from both CINT and `rootcint`.
``` {.cpp}
#if !defined(__CINT__)
@@ -981,15 +998,15 @@ int gArray[] = { 2, 3, 4};
#endif
```
-Because ACLiC calls `rootcint` to build a dictionary, the declaration of
-`gArray` will not be included in the dictionary, and consequently,
+Because ACLiC calls `rootcint` to build a dictionary, the declaration
+of `gArray` will not be included in the dictionary, and consequently,
`gArray` will not be available at the command line even if ACLiC is
used. CINT and `rootcint` will ignore all statements between the
`"#if !defined` `(__CINT__)"` and "`#endif"`. If you want to use
-`gArray` in the same script as its declaration, you can do so. However,
-if you want use the script in the interpreter you have to bracket the
-usage of `gArray` between `#if's,` since the definition is not visible.
-If you add the following preprocessor statements:
+`gArray` in the same script as its declaration, you can do so.
+However, if you want use the script in the interpreter you have to
+bracket the usage of `gArray` between `#if's,` since the definition is
+not visible. If you add the following preprocessor statements:
``` {.cpp}
#if !defined(__CINT__)
@@ -999,29 +1016,30 @@ int gArray[];
#endif
```
-`gArray` will be visible to `rootcint` but still not visible to CINT. If
-you use ACLiC, `gArray` will be available at the command line and be
-initialized properly by the compiled code.
+`gArray` will be visible to `rootcint` but still not visible to CINT.
+If you use ACLiC, `gArray` will be available at the command line and
+be initialized properly by the compiled code.
We recommend you always write scripts with the needed include
statements. In most cases, the script will still run with the
interpreter. However, a few header files are not handled very well by
CINT.
-These types of headers can be included in interpreted and compiled mode:
+These types of headers can be included in interpreted and compiled
+mode:
- The subset of standard C/C++ headers defined in
`$ROOTSYS/cint/include.`
-- Headers of classes defined in a previously loaded library (including
- ROOT own). The defined class must have a name known to ROOT (i.e. a
- class with a `ClassDef`).
+- Headers of classes defined in a previously loaded library
+ (including ROOT own). The defined class must have a name known to
+ ROOT (i.e. a class with a `ClassDef`).
-A few headers will cause problems when they are included in interpreter
-mode, because the interpreter itself already includes them. In general,
-the interpreter needs to know whether to use the interpreted or compiled
-version. The mode of the definition needs to match the mode of the
-reference.
+A few headers will cause problems when they are included in
+interpreter mode, because the interpreter itself already includes
+them. In general, the interpreter needs to know whether to use the
+interpreted or compiled version. The mode of the definition needs to
+match the mode of the reference.
Here are the cases that need to be excluded in interpreted mode, but
included for `rootcint`. Bracket these with:
@@ -1035,17 +1053,17 @@ included for `rootcint`. Bracket these with:
- Headers with a class defined in libraries before the library is
loaded. For example: having `#include "TLorentzVector.h `before
`gSystem->Load("libPhysics")`. This will also cause problems when
- compiling the script, but a clear error message will be given. With
- the interpreter, it may core dump. Bracket these type of include
- statements with` #if !defined (__CINT__), `this will print an error
- in both modes.
+ compiling the script, but a clear error message will be given.
+ With the interpreter, it may core dump. Bracket these type of
+ include statements with` #if !defined (__CINT__), `this will print
+ an error in both modes.
-Hiding header files from `rootcint` that are necessary for the compiler
-but optional for the interpreter can lead to a subtle but fatal error.
-For example:
+Hiding header files from `rootcint` that are necessary for the
+compiler but optional for the interpreter can lead to a subtle but
+fatal error. For example:
``` {.cpp}
-#ifndef __CINT__
+#ifndef __CINT__
#include "TTree.h"
#else
class TTree;
@@ -1058,9 +1076,9 @@ class subTree : public TTree {
In this case, `rootcint` does not have enough information about the
**`TTree`** class to produce the correct dictionary file. If you try
this, `rootcint` and compiling will be error free, however,
-instantiating a `subTree` object from the CINT command line will cause a
-fatal error. In general, it is recommended to let `rootcint` see as many
-header files as possible.
+instantiating a `subTree` object from the CINT command line will cause
+a fatal error. In general, it is recommended to let `rootcint` see as
+many header files as possible.
## Reflex
@@ -1075,30 +1093,31 @@ build it you have to `./configure --enable-reflex`
### Overview
-Inside ROOT Reflex is thought to replace the current reflection system,
-which is inherent to CINT. This is an ongoing work and not part of this
-release. Nevertheless, Reflex dictionaries can be used inside ROOT while
-populating the current CINT data structures via a special gateway called
-Cintex (see "Cintex").
+Inside ROOT Reflex is thought to replace the current reflection
+system, which is inherent to CINT. This is an ongoing work and not
+part of this release. Nevertheless, Reflex dictionaries can be used
+inside ROOT while populating the current CINT data structures via a
+special gateway called Cintex (see "Cintex").
-In order to use reflection a dictionary of the data structures involved
-has to be generated. Before generating the dictionaries, the source code
-has to be parsed and the information extracted. In the ROOT environment,
-there are two ways to generate dictionaries for the Reflex library.
+In order to use reflection a dictionary of the data structures
+involved has to be generated. Before generating the dictionaries, the
+source code has to be parsed and the information extracted. In the
+ROOT environment, there are two ways to generate dictionaries for the
+Reflex library.
-- Using CINT as a source code parser - the command to issue when using
- CINT for parsing C++ constructs is:
+- Using CINT as a source code parser - the command to issue when
+ using CINT for parsing C++ constructs is:
``` {.cpp}
rootcint -reflex -f module/src/G__Module.cxx -c module/inc/TMod1.h
module/inc/TMod2.h module/inc/Linkdef.h
```
-- Using the `gcc` compiler as a source code parser: With this option a
- special program called "`gccxml`" has to be installed. This program
- is an extension to gcc and produces `xml` code out of parsed C++
- definitions which will be further used to generate the proper
- dictionary source code via a python script. For parsing C++
+- Using the `gcc` compiler as a source code parser: With this option
+ a special program called "`gccxml`" has to be installed. This
+ program is an extension to gcc and produces `xml` code out of
+ parsed C++ definitions which will be further used to generate the
+ proper dictionary source code via a python script. For parsing C++
constructs using the `gcc` compiler the command will be:
``` {.cpp}
@@ -1106,21 +1125,23 @@ rootcint -gccxml -f module/src/G__Module.cxx -c module/inc/TMod1.h
module/inc/TMod2.h module/inc/Linkdef.h
```
-Note: an installation of Python and `gccxml` is required for using this
-option.
+Note: an installation of Python and `gccxml` is required for using
+this option.
### Selecting Types And Members
-You can use selection files to tell genreflex what it should generate a
-dictionary for. If you do not use it, it will generate a dictionary for
-all types in the files passed at the command line, or when specifying
---deep for all types it finds.
+You can use selection files to tell genreflex what it should generate
+a dictionary for. If you do not use it, it will generate a dictionary
+for all types in the files passed at the command line, or when
+specifying `--deep` for all types it finds.
-The selection file is passed to genreflex with the -s parameters like
-this:
+The selection file is passed to `genreflex` with the `-s` parameters
+like this:
+``` {.cpp}
genreflex -s selection.xml header1.h header2.h.
+```
It is an XML file with the following structure:
@@ -1155,17 +1176,18 @@ The program parsing the header files and providing genreflex with the
information what's in them is called GCCXML. It only sees templates if
they are instantiated. See the C++ standard on when template
instantiation happens. The rule of thumb is: if you design a templated
-class then it probably does not happen in that templated class's header.
+class then it probably does not happen in that templated class's
+header.
-So you need to help GCCXML. There are two common approaches: the struct
-member, and the "proper" C++ way.
+So you need to help GCCXML. There are two common approaches: the
+struct member, and the "proper" C++ way.
#### Explicit Template Instantiation
This is the preferred method, but it is not widely used. Suppose you
-have a templated template class C and a templated function template T
-A::f(const T&) const;. You can instantiate them (say with template
-parameter long long) using:
+have a templated template class C and a templated function
+`template T A::f(const T&) const;`. You can instantiate them (say with
+template parameter `long long`) using:
``` {.cpp}
#ifdef __GCCXML__
@@ -1176,7 +1198,7 @@ template long long A::f(const long long&);
```
You can even put this into your regular header file: it is surrounded by
-an \#ifdef \_\_GCCXML\_\_ and will thus be invisible to any other
+an `#ifdef __GCCXML__` and will thus be invisible to any other
compiler.
#### Template Instantiation by struct Members
@@ -1190,9 +1212,9 @@ class you can use:
#ifdef __GCCXML__
// GCCXML explicit template instantiation block
namespace {
-struct GCCXML_DUMMY_INSTANTIATION {
-C<long long> dummyMember;
-};
+ struct GCCXML_DUMMY_INSTANTIATION {
+ C<long long> dummyMember;
+ };
}
#endif
```
@@ -1212,10 +1234,10 @@ downloaded from
[ http://spi.cern.ch/lcgsoft/]( http://spi.cern.ch/lcgsoft/).
Once the dictionary sources have been generated, they can be compiled
-into a library and loaded via the Reflex builder system. The dictionary
-information can be used via the Reflex API. For this purpose, Reflex
-provides eight classes, which exploit the whole functionality of the
-system.
+into a library and loaded via the Reflex builder system. The
+dictionary information can be used via the Reflex API. For this
+purpose, Reflex provides eight classes, which exploit the whole
+functionality of the system.
### Reflex API
@@ -1231,46 +1253,31 @@ information about its type and it is location in memory.
**Type** is an abstraction of a C++ type. Types in Reflex are:
- Array
-
- Class/struct
-
- Templated class/struct
-
- Enum
-
- Function
-
- Fundamental
-
- Pointer
-
- Pointer to member
-
- Typedef
-
- Union
A **scope** is an abstraction of a C++ type. It holds information such
-as its declaring scope, it is underlying scope and it is data`/`function
-members. Scopes are:
+as its declaring scope, it is underlying scope and it is
+data`/`function members. Scopes are:
- Namespace
-
- Class/Struct
-
- Templated class/struct
-
- Union
-
- Enum
-A **member** lives inside a scope and is of a given Type. Members can be
-distinguished as:
+A **member** lives inside a scope and is of a given Type. Members can
+be distinguished as:
- DataMember
-
- FunctionMember
-
- Templated member
**Base** holds the information about the inheritance structure of
@@ -1279,8 +1286,8 @@ and the type of the base class.
**Properties** are key/value pairs where the key is a string and the
value an Any object (Boost::Any). Any objects can hold any type of
-information be it a string, int or any arbitrary object. Properties can
-be attached to Types, Scopes and Members and hold any kind of
+information be it a string, int or any arbitrary object. Properties
+can be attached to Types, Scopes and Members and hold any kind of
information that is not specific to C++. Examples for Properties would
be the class author, a description of a member or the class id.
@@ -1292,9 +1299,9 @@ A **TypeTemplate** is an abstraction of a templated type (e.g. class).
It holds the same information as the MemberTemplate (e.g. template
parameters, list of instantiations)
-The Reflex package lives in the namespace **`ROOT::Reflex`**. Below some
-examples of usage of the package are given. For further information
-please see the documentation of the different API classes.
+The Reflex package lives in the namespace **`ROOT::Reflex`**. Below
+some examples of usage of the package are given. For further
+information please see the documentation of the different API classes.
The next examples will refer to the example class `MyClass`:
@@ -1302,35 +1309,35 @@ The next examples will refer to the example class `MyClass`:
class MyClass {
public:
-MyClass() : fMem1(47), fMem2("foo") { }
-int GetMem1() { return fMem1; }
-int GetMem1(int i) { return fMem1*i; }
-void SetMem1(int i) { fMem1 = i; }
-std::string GetMem2() { return fMem2; }
-void SetMem2(const std::string & str) { fMem2 = str; }
+ MyClass() : fMem1(47), fMem2("foo") { }
+ int GetMem1() { return fMem1; }
+ int GetMem1(int i) { return fMem1*i; }
+ void SetMem1(int i) { fMem1 = i; }
+ std::string GetMem2() { return fMem2; }
+ void SetMem2(const std::string & str) { fMem2 = str; }
private:
-int fMem1;
-std::string fMem2;
+ int fMem1;
+ std::string fMem2;
};
```
-The first thing after loading a dictionary (which is done at the moment
-at the same time as the implemenation library), will be to look up a
-certain Type or Scope.
+The first thing after loading a dictionary (which is done at the
+moment at the same time as the implemenation library), will be to look
+up a certain Type or Scope.
``` {.cpp}
Type t1 = Type::ByName("MyClass");
```
-Every API class provides the `operator bool`, which will return true if
-the information retrieved for this instance is valid and further actions
-on this instance can be taken.
+Every API class provides the `operator bool`, which will return true
+if the information retrieved for this instance is valid and further
+actions on this instance can be taken.
``` {.cpp}
if (t1) {
-if (t1.IsClass()) std::cout << "Class ";
-std::cout << t1.Name();
+ if (t1.IsClass()) std::cout << "Class ";
+ std::cout << t1.Name();
}
```
@@ -1339,18 +1346,20 @@ over its members. This can be done either with stl like iterators or
with an iteration by number:
``` {.cpp}
-For (Member_Iterator mi = t1.DataMember_Begin(); mi != DataMember_End(); ++mi) {
-std::cout << (*mi).Name(SCOPED) << " " << (*mi).TypeOf().Name(QUALIFIED);
+For (Member_Iterator mi = t1.DataMember_Begin();
+ mi != DataMember_End(); ++mi) {
+ std::cout << (*mi).Name(SCOPED) << " "
+ << (*mi).TypeOf().Name(QUALIFIED);
}
Member m;
for (size_t i = 0; i < t1.FunctionMemberSize(); ++i) {
-m = t1.FunctionMemberAt(i);
-std::cout << m.Name() << " " << m.TypeOf().Name();
-for (Type_Iterator ti = m.FunctionParaeter_Begin(); ti !=
-m.FunctionParameter_End(); ++ti) {
-std::cout << (*ti).Name() << std::endl;
-}
+ m = t1.FunctionMemberAt(i);
+ std::cout << m.Name() << " " << m.TypeOf().Name();
+ for (Type_Iterator ti = m.FunctionParaeter_Begin(); ti !=
+ m.FunctionParameter_End(); ++ti) {
+ std::cout << (*ti).Name() << std::endl;
+ }
}
```
@@ -1364,8 +1373,8 @@ Object o1 = t1.Construct();
```
which will call the default constructor for this type and allocate the
-memory for this type inside the Object. The Object will also contain the
-type information constructed.
+memory for this type inside the Object. The Object will also contain
+the type information constructed.
Now the object of a certain type has been constructed one may interact
with it. E.g. getting the value of a data member can be done via which
@@ -1375,7 +1384,7 @@ will return an Object of the data member in question.
Object mem_obj = o1.Get("fMem1");
int real_value = 0;
if (mem_obj.TypeOf().Name() == "int)
-int real_value = Object_Cast<int>(mem_obj);
+ int real_value = Object_Cast<int>(mem_obj);
```
It is also possible to invoke function members via the Object class. A
@@ -1389,11 +1398,12 @@ change in the future to pass a vector of Objects.
int par1 = 2;
std::vector<void*> parVec;
parVec.push_back(&par1);
-int ret_val = Object_Cast<int>(o1.Invoke("GetMem1","int (int)",parVec));
+int ret_val = Object_Cast<int>(
+ o1.Invoke("GetMem1","int (int)",parVec));
```
-Calling the destructor of an Object can be done via, this will call both
-the destructor and of the object type and deallocate the memory.
+Calling the destructor of an Object can be done via, this will call
+both the destructor and of the object type and deallocate the memory.
``` {.cpp}
o1.Destruct();
@@ -1402,32 +1412,32 @@ o1.Destruct();
### Cintex
-Cintex is an optional package inside ROOT. In order to build it you have
-to
+Cintex is an optional package inside ROOT. In order to build it you
+have to
``` {.cpp}
./configure --enable-cintex at the ROOT configuration step.
```
The purpose of the Cintex package is to bridge uni-directional
-information from the Reflex to the CINT dictionary system. This package
-will be needed as long as the unification of the Reflex and CINT
-dictionaries has not been completed. This unification is work ongoing.
-In order to use Cintex functionality it will be needed to load the
-Cintex library (e.g. libCintex.so on linux systems) and enable the
-Cintex gateway with
+information from the Reflex to the CINT dictionary system. This
+package will be needed as long as the unification of the Reflex and
+CINT dictionaries has not been completed. This unification is work
+ongoing. In order to use Cintex functionality it will be needed to
+load the Cintex library (e.g. libCintex.so on linux systems) and
+enable the Cintex gateway with
``` {.cpp}
Cintex::Enable();
```
-After these two steps have been taken, any Reflex dictionary information
-should be propagated to the CINT dictionaries and subsequently usable
-inside the CINT environment (e.g. from the root prompt). If wanted
-debugging information while loading Reflex dictionaries can be turned on
-with (any number greater than 0 can be used as argument but will not
-make any difference in the amount of debugging output for the time
-being).
+After these two steps have been taken, any Reflex dictionary
+information should be propagated to the CINT dictionaries and
+subsequently usable inside the CINT environment (e.g. from the root
+prompt). If wanted debugging information while loading Reflex
+dictionaries can be turned on with (any number greater than 0 can be
+used as argument but will not make any difference in the amount of
+debugging output for the time being).
``` {.cpp}
Cintex::SetDebug(1);
diff --git a/docbook/users-guide/FittingHistograms.md b/docbook/users-guide/FittingHistograms.md
index 4bf7f0342421266c42db1aff2048870613efc029..d915e6b68773b0ed2e809bfa6a534e2d502f097a 100644
--- a/docbook/users-guide/FittingHistograms.md
+++ b/docbook/users-guide/FittingHistograms.md
@@ -590,9 +590,6 @@ function:
// the non-linear part (Lorentzian
```
-For another example see:
-<http://root.cern.ch/root/html/examples/backsig.C.html>
-
## Associated Function
diff --git a/docbook/users-guide/FoldersTasks.md b/docbook/users-guide/FoldersTasks.md
index a0cdc7a7bb275e43b21e510cbec2c12b8f47f832..e62abd3b57cb39ee8b7d6b7abc23ac3bb9d30768 100644
--- a/docbook/users-guide/FoldersTasks.md
+++ b/docbook/users-guide/FoldersTasks.md
@@ -78,30 +78,33 @@ it is visible in the browser on the top level.
``` {.cpp}
{
-// Add the top folder of my hierary to //root
-TFolder *aliroot=gROOT->GetRootFolder()->AddFolder("aliroot",
- "aliroot top level folders");
-// Add the hierarchy to the list of browsables
-gROOT->GetListOfBrowsables()->Add(aliroot,"aliroot");
+ // Add the top folder of my hierary to //root
+ TFolder *aliroot=gROOT->GetRootFolder()->AddFolder("aliroot",
+ "aliroot top level folders");
+ // Add the hierarchy to the list of browsables
+ gROOT->GetListOfBrowsables()->Add(aliroot,"aliroot");
-// Create and add the constants folder
-TFolder *constants=aliroot->AddFolder("Constants","Detector constants");
+ // Create and add the constants folder
+ TFolder *constants=aliroot->AddFolder("Constants",
+ "Detector constants");
-// Create and add the pdg folder to pdg
-TFolder *pdg = constants->AddFolder("DatabasePDG","PDG database");
+ // Create and add the pdg folder to pdg
+ TFolder *pdg = constants->AddFolder("DatabasePDG","PDG database");
-// Create and add the run folder
-TFolder *run = aliroot->AddFolder("Run","Run dependent folders");
+ // Create and add the run folder
+ TFolder *run = aliroot->AddFolder("Run","Run dependent folders");
-// Create and add the configuration folder to run
-TFolder *configuration = run->AddFolder("Configuration","Run configuration");
+ // Create and add the configuration folder to run
+ TFolder *configuration = run->AddFolder("Configuration",
+ "Run configuration");
-// Create and add the run_mc folder
-TFolder *run_mc = aliroot->AddFolder("RunMC","MonteCarlo run dependent folders");
+ // Create and add the run_mc folder
+ TFolder *run_mc = aliroot->AddFolder("RunMC",
+ "MonteCarlo run dependent folders");
-// Create and add the configuration_mc folder to run_mc
-TFolder *configuration_mc = run_mc->AddFolder("Configuration",
- "MonteCarlo run configuration");
+ // Create and add the configuration_mc folder to run_mc
+ TFolder *configuration_mc = run_mc->AddFolder("Configuration",
+ "MonteCarlo run configuration");
}
```
@@ -136,8 +139,9 @@ consumer class. When a folder is deleted, any reference to it in the
parent or other folder is deleted also.
``` {.cpp}
-conf=(TFolder*)gROOT->FindObjectAny("/aliroot/Run/Configuration"); // or
-conf=(TFolder*)gROOT->FindObjectAny("Configuration");
+ conf=(TFolder*)gROOT->FindObjectAny("/aliroot/Run/Configuration");
+ // or ...
+ conf=(TFolder*)gROOT->FindObjectAny("Configuration");
```
By default, a folder does not own the object it contains. You can
@@ -163,8 +167,10 @@ can retrieve a pointer to the corresponding **`TFile`** object with a
statement like:
``` {.cpp}
-TFile *myFile = (TFile*)gROOT->FindObjectAny("/ROOTFiles/myFile.root"); //or
-TFile *myFile = (TFile*)gROOT->FindObjectAny("myFile.root");
+ TFile *myFile = (TFile*)gROOT->FindObjectAny(
+ "/ROOTFiles/myFile.root");
+ //or...
+ TFile *myFile = (TFile*)gROOT->FindObjectAny("myFile.root");
```
## Tasks
@@ -230,40 +236,43 @@ above, and creates a hierarchy of tasks.
// TTask context menu, such as:
// -setting a breakpoint in one or more tasks
// -enabling/disabling one task, etc
-void tasks()
-{
-gROOT->ProcessLine(".L MyTasks.cxx+");
-
-TTask *run = new MyRun("run","Process one run");
-TTask *event = new MyEvent("event","Process one event");
-TTask *geomInit = new MyGeomInit("geomInit", "Geometry Initialisation");
-TTask *matInit = new MyMaterialInit("matInit","MaterialsInitialisation");
-TTask *tracker = new MyTracker("tracker","Tracker manager");
-TTask *tpc = new MyRecTPC("tpc","TPC Reconstruction");
-TTask *its = new MyRecITS("its","ITS Reconstruction");
-TTask *muon = new MyRecMUON("muon","MUON Reconstruction");
-TTask *phos = new MyRecPHOS("phos","PHOS Reconstruction");
-TTask *rich = new MyRecRICH("rich","RICH Reconstruction");
-TTask *trd = new MyRecTRD("trd","TRD Reconstruction");
-TTask *global = new MyRecGlobal("global","Global Reconstruction");
+void tasks() {
+ gROOT->ProcessLine(".L MyTasks.cxx+");
+
+ TTask *run = new MyRun("run","Process one run");
+ TTask *event = new MyEvent("event","Process one event");
+ TTask *geomInit = new MyGeomInit("geomInit",
+ "Geometry Initialisation");
+ TTask *matInit = new MyMaterialInit("matInit",
+ "MaterialsInitialisation");
+ TTask *tracker = new MyTracker("tracker","Tracker manager");
+ TTask *tpc = new MyRecTPC("tpc","TPC Reconstruction");
+ TTask *its = new MyRecITS("its","ITS Reconstruction");
+ TTask *muon = new MyRecMUON("muon","MUON Reconstruction");
+ TTask *phos = new MyRecPHOS("phos","PHOS Reconstruction");
+ TTask *rich = new MyRecRICH("rich","RICH Reconstruction");
+ TTask *trd = new MyRecTRD("trd","TRD Reconstruction");
+ TTask *global = new MyRecGlobal("global","Global Reconstruction");
// Create a hierarchy by adding sub tasks
-run->Add(geomInit);
-run->Add(matInit);
-run->Add(event);
-event->Add(tracker);
-event->Add(global);
-tracker->Add(tpc);
-tracker->Add(its);
-tracker->Add(muon);
-tracker->Add(phos);
-tracker->Add(rich);
-tracker->Add(trd);
+ run->Add(geomInit);
+ run->Add(matInit);
+ run->Add(event);
+ event->Add(tracker);
+ event->Add(global);
+ tracker->Add(tpc);
+ tracker->Add(its);
+ tracker->Add(muon);
+ tracker->Add(phos);
+ tracker->Add(rich);
+ tracker->Add(trd);
+
// Add the top level task
-gROOT->GetListOfTasks()->Add(run);
+ gROOT->GetListOfTasks()->Add(run);
+
// Add the task to the browser
-gROOT->GetListOfBrowsables()->Add(run);
-new TBrowser;
+ gROOT->GetListOfBrowsables()->Add(run);
+ new TBrowser;
}
```
diff --git a/docbook/users-guide/ObjectOwnership.md b/docbook/users-guide/ObjectOwnership.md
index 9850d21cd527de9237497f3e969f2aed82e9015b..2ffe59f9e64055f1a45ff8deccb2eaebedaa185a 100644
--- a/docbook/users-guide/ObjectOwnership.md
+++ b/docbook/users-guide/ObjectOwnership.md
@@ -1,21 +1,22 @@
# Object Ownership
-An object has ownership of another object if it has permission to delete
-it. Usually a collection or a parent object such as a pad holds
+An object has ownership of another object if it has permission to
+delete it. Usually a collection or a parent object such as a pad holds
ownership. To prevent memory leaks and multiple attempts to delete an
-object, you need to know which objects ROOT owns and which are owned by
-you.
+object, you need to know which objects ROOT owns and which are owned
+by you.
The following rules apply to the ROOT classes.
-- Histograms, trees, and event lists created by the user are owned by
- current directory (***`gDirectory`***). When the current directory
- is closed or deleted the objects it owns are deleted.
+- Histograms, trees, and event lists created by the user are owned
+ by current directory (***`gDirectory`***). When the current
+ directory is closed or deleted the objects it owns are deleted.
-- The `TROOT` master object (***`gROOT`***) has several collections of
- objects. Objects that are members of these collections are owned by
- ***`gROOT`*** see "Ownership by the Master TROOT Object (gROOT).
+- The `TROOT` master object (***`gROOT`***) has several collections
+ of objects. Objects that are members of these collections are
+ owned by ***`gROOT`*** see "Ownership by the Master TROOT Object
+ (gROOT).
- Objects created by another object, for example the function object
(e.g.**`TF1`**) created by the **`TH1::Fit `method is owned by the
@@ -24,51 +25,51 @@ The following rules apply to the ROOT classes.
- An object created by `DrawCopy` methods, is owned by the pad it is
drawn in.
-If an object fits none of these cases, the user has ownership. The next
-paragraphs describe each rule and user ownership in more detail.
+If an object fits none of these cases, the user has ownership. The
+next paragraphs describe each rule and user ownership in more detail.
## Ownership by Current Directory (gDirectory)
-When a histogram, tree, or event list (**`TEventList`**) is created, it
-is added to the list of objects in the current directory by default. You
-can get the list of objects in a directory and retrieve a pointer to a
-specific object with the `GetList` method. This example retrieves a
-histogram.
+When a histogram, tree, or event list (**`TEventList`**) is created,
+it is added to the list of objects in the current directory by
+default. You can get the list of objects in a directory and retrieve
+a pointer to a specific object with the `GetList` method. This example
+retrieves a histogram.
``` {.cpp}
-TH1F *h = (TH1F*)gDirectory->GetList()->FindObject("myHist");
+ TH1F *h = (TH1F*)gDirectory->GetList()->FindObject("myHist");
```
The method `TDirectory::GetList()` returns a **`TList`** of objects in
the directory. It looks in memory, and is implemented in all ROOT
-collections. You can change the directory of a histogram, tree, or event
-list with the `SetDirectory` method. Here we use a histogram for an
-example, but the same applies to trees and event lists.
+collections. You can change the directory of a histogram, tree, or
+event list with the `SetDirectory` method. Here we use a histogram for
+an example, but the same applies to trees and event lists.
``` {.cpp}
-h->SetDirectory(newDir)
+ h->SetDirectory(newDir);
```
You can also remove a histogram from a directory by using
`SetDirectory(0)`. Once a histogram is removed from the directory, it
will not be deleted when the directory is closed. It is now your
-responsibility to delete this histogram once you have finished with it.
-To change the default that automatically adds the histogram to the
+responsibility to delete this histogram once you have finished with
+it. To change the default that automatically adds the histogram to the
current directory, you can call the static function:
``` {.cpp}
-TH1::AddDirectory(kFALSE);
+ TH1::AddDirectory(kFALSE);
```
Not all histograms created here after will be added to the current
-directory. In this case, you own all histogram objects and you will need
-to delete them and clean up the references. You can still set the
+directory. In this case, you own all histogram objects and you will
+need to delete them and clean up the references. You can still set the
directory of a histogram by calling `SetDirectory` once it has been
created as described above.
-Note that, when a file goes out of scope or is closed all objects on its
-object list are deleted.
+Note that, when a file goes out of scope or is closed all objects on
+its object list are deleted.
## Ownership by the Master TROOT Object (gROOT)
@@ -78,16 +79,16 @@ objects. For example, a canvas is added to the collection of canvases
and it is owned by the canvas collection.
``` {.cpp}
-TSeqCollection* fFiles List of files (TFile)
-TSeqCollection* fMappedFiles List of memory mapped files (TMappedFile)
-TSeqCollection* fSockets List of network sockets (TSocket and TServerSocket)
-TSeqCollection* fCanvases List of canvases (TCanvas)
-TSeqCollection* fStyles List of styles (TStyle)
-TSeqCollection* fFunctions List of analytic functions(TF1, TF2, TF3)
-TSeqCollection* fTasks List of tasks (TTask)
-TSeqCollection* fColors List of colors (TColor)
-TSeqCollection* fGeometries List of geometries (?)
-TSeqCollection* fBrowsers List of browsers (TBrowser)
+TSeqCollection* fFiles List of TFile
+TSeqCollection* fMappedFiles List of TMappedFile
+TSeqCollection* fSockets List of TSocket and TServerSocket
+TSeqCollection* fCanvases List of TCanvas
+TSeqCollection* fStyles List of TStyle
+TSeqCollection* fFunctions List of TF1, TF2, TF3
+TSeqCollection* fTasks List of TTask
+TSeqCollection* fColors List of TColor
+TSeqCollection* fGeometries List of geometries
+TSeqCollection* fBrowsers List of TBrowser
TSeqCollection* fSpecials List of special objects
TSeqCollection* fCleanups List of recursiveRemove collections
```
@@ -100,10 +101,11 @@ special cases are the collections of specials and cleanups.
This collection contains objects of the following classes:
-**`TCut``G`**, **`TMultiDimFit`**, **`TPrincipal`**, **`TChains`. In
-addition it contains the *`gHtml`*** object, ***`gMinuit`*** objects,
-and the array of contours graphs (**`TGraph`**) created when calling the
-`Draw` method of a histogram with the `"CONT`, `LIST"` option.
+**`TCutG`**, **`TMultiDimFit`**, **`TPrincipal`**, **`TChains`**. In
+addition it contains the ***`gHtml`*** object, ***`gMinuit`***
+objects, and the array of contours graphs (**`TGraph`**) created when
+calling the `Draw` method of a histogram with the `"CONT`, `LIST"`
+option.
### Access to the Collection Contents
@@ -126,13 +128,14 @@ created one. For example:
myHisto->Fit("gaus")
```
-The call to Fit copies the global
-`TF1 Gaussian function and attaches the copy to the histogram. When the histogram is deleted, the copy is deleted also. `
+The call to Fit copies the global **`TF1`** Gaussian function and
+attaches the copy to the histogram. When the histogram is deleted, the
+copy is deleted also.
-`When a pad is deleted or cleared, all objects in the pad with the ``kCanDelete`
-bit set are deleted automatically. Currently the objects created by the
-`DrawCopy` methods, have the `kCanDelete` bit set and are therefore
-owned by the pad.
+When a pad is deleted or cleared, all objects in the pad with the
+`kCanDelete` bit set are deleted automatically. Currently the objects
+created by the `DrawCopy` methods, have the `kCanDelete` bit set and
+are therefore owned by the pad.
## Ownership by the User
@@ -156,35 +159,36 @@ The bits can be reset and tested with the `TObject::ResetBit` and
The ***`gROOT`*** collections (see above) own their members and will
delete them regardless of the `kCanDelete` bit. In all other
collections, when the collection `Clear` method is called (i.e.
-**`TList::Clear()),` members with the `kCanDelete` bit set, are deleted
-and removed from the collection. If the `kCanDelete` bit is not set, the
-object is only removed from the collection but not deleted.**
+**`TList::Clear())`**, members with the `kCanDelete` bit set, are
+deleted and removed from the collection. If the `kCanDelete` bit is
+not set, the object is only removed from the collection but not
+deleted.
If a collection `Delete` (`TList::Delete()`) method is called, all
objects in the collection are deleted without considering the
`kCanDelete` bit. It is important to realize that deleting the
-collection (i.e. delete `MyCollection`), DOES NOT delete the members of
-the collection.
+collection (i.e. delete `MyCollection`), DOES NOT delete the members
+of the collection.
-If the user specified `MyCollection->SetOwner()` the collection owns the
-objects and delete `MyCollection` will delete all its members.
+If the user specified `MyCollection->SetOwner()` the collection owns
+the objects and delete `MyCollection` will delete all its members.
Otherwise, you need to:
``` {.cpp}
-// delete all member objects in the collection
-MyCollection->Delete();
+ // delete all member objects in the collection
+ MyCollection->Delete();
-// and delete the collection object
-delete MyCollection;
+ // and delete the collection object
+ delete MyCollection;
```
-Note that `kCanDelete` is automatically set by the `DrawCopy` method and
-the user can set it for any object. For example, the user must manage
-all graphics primitives. If you want **`TCanvas`** to delete the
-primitive you created you have to set the `kCanDelete` bit.
+Note that `kCanDelete` is automatically set by the `DrawCopy` method
+and the user can set it for any object. For example, the user must
+manage all graphics primitives. If you want **`TCanvas`** to delete
+the primitive you created you have to set the `kCanDelete` bit.
-The `kCanDelete` bit setting is displayed with `TObject::ls()`. The last
-number is either 1 or 0 and is the `kCanDelete` bit.
+The `kCanDelete` bit setting is displayed with `TObject::ls()`. The
+last number is either 1 or 0 and is the `kCanDelete` bit.
``` {.cpp}
root[] TCanvas MyCanvas("MyCanvas")
@@ -217,8 +221,8 @@ the object and its references from all collections in the clean up
collection (***`gROOT`***`::fCleanups`). An object can be in several
collections, for example if an object is in a browser and on two
canvases. If the `kMustCleanup` bit is set, it will be removed
-automatically from the browser and both canvases when the destructor of
-the object is called.
+automatically from the browser and both canvases when the destructor
+of the object is called.
The `kMustCleanup` bit is set:
@@ -237,19 +241,19 @@ The `kMustCleanup` bit is set:
- When painting a frame for a pad, the frame's `kMustCleanup` is set
in `TPad::PaintPadFrame`
-The user can add his own collection to the collection of clean ups, to take advantage of
-the automatic garbage collection. For example:
+The user can add his own collection to the collection of clean ups, to
+take advantage of the automatic garbage collection. For example:
``` {.cpp}
-// create two list
-TList *myList1, *myList2;
+ // create two list
+ TList *myList1, *myList2;
-// add both to of clean ups
-gROOT->GetListOfCleanUps()->Add(myList1);
-gROOT->GetListOfCleanUps()->Add(myList2);
+ // add both to of clean ups
+ gROOT->GetListOfCleanUps()->Add(myList1);
+ gROOT->GetListOfCleanUps()->Add(myList2);
-// assuming myObject is in myList1 and myList2, when calling:
-delete myObject;
+ // assuming myObject is in myList1 and myList2, when calling:
+ delete myObject;
-// the object is deleted from both lists
+ // the object is deleted from both lists
```
diff --git a/gui/gui/src/TGFileBrowser.cxx b/gui/gui/src/TGFileBrowser.cxx
index 8901044dcb6929d9fda0a44269b3d3076a5d3042..ff25b25db363ba09766e65407c73e37fcb51faab 100644
--- a/gui/gui/src/TGFileBrowser.cxx
+++ b/gui/gui/src/TGFileBrowser.cxx
@@ -1292,12 +1292,32 @@ void TGFileBrowser::DoubleClicked(TGListTreeItem *item, Int_t /*btn*/)
}
if (!obj->InheritsFrom("TObjString") ||
gSystem->AccessPathName(fullpath.Data())) {
+ fBrowser->SetDrawOption(GetDrawOption());
fDblClick = kTRUE;
- obj->Browse(fBrowser);
+ if (gClient->GetMimeTypeList()->GetAction(obj->IsA()->GetName(), action)) {
+ act = action;
+ if (act.Contains("%s")) act.ReplaceAll("%s", obj->GetName());
+ else if (act.Contains("->Browse()")) obj->Browse(fBrowser);
+ else {
+ act.Prepend(obj->GetName());
+ gInterpreter->SaveGlobalsContext();
+ if (act[0] == '!') {
+ act.Remove(0, 1);
+ gSystem->Exec(act.Data());
+ } else {
+ // special case for remote object: remote process
+ if (obj->InheritsFrom("TRemoteObject"))
+ gApplication->SetBit(TApplication::kProcessRemotely);
+ gApplication->ProcessLine(act.Data());
+ }
+ }
+ }
+ else obj->Browse(fBrowser);
fDblClick = kFALSE;
fNKeys = 0;
fCnt = 0;
fListTree->ClearViewPort();
+ if (gPad) gPad->Update();
return;
}
}