[root6] Address issues in TTable when interpreted by Cling #449
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It appears Cling chokes on some code in `StRoot/Table/TTable.h` while trying to
interpret it:
```
In file included from St_tpcPadConfig_TableCint dictionary payload:10:
In file included from ./.sl79_gcc485/include/tables/St_tpcPadConfig_Table.h:5:
/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-6.16.00-osnvudkiguzfhdpqgy2krbqybjbqvith/include/TTable.h:197:33: error: cannot increment value of type 'TTable::iterator::vec_iterator' (aka '__normal_iterator<long *, std::vector<long, std::allocator<long> > >')
void operator++() { ++fCurrentRow; }
^ ~~~~~~~~~~~
/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-6.16.00-osnvudkiguzfhdpqgy2krbqybjbqvith/include/TTable.h:198:46: error: cannot increment value of type 'TTable::iterator::vec_iterator' (aka '__normal_iterator<long *, std::vector<long, std::allocator<long> > >')
void operator++(int) { fCurrentRow++; }
~~~~~~~~~~~^
/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-6.16.00-osnvudkiguzfhdpqgy2krbqybjbqvith/include/TTable.h:199:33: error: cannot decrement value of type 'TTable::iterator::vec_iterator' (aka '__normal_iterator<long *, std::vector<long, std::allocator<long> > >')
void operator--() { --fCurrentRow; }
^ ~~~~~~~~~~~
/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-6.16.00-osnvudkiguzfhdpqgy2krbqybjbqvith/include/TTable.h:200:46: error: cannot decrement value of type 'TTable::iterator::vec_iterator' (aka '__normal_iterator<long *, std::vector<long, std::allocator<long> > >')
void operator--(int) { fCurrentRow--; }
~~~~~~~~~~~^
```
While the same code compiles fine by gcc 4.8.5 we can "hide" it from Cling by
moving it to the implementation file.
While interpreting the code in `Table/TTable.h` Cling complains about
unintialized member of type `std::vector<long>::iterator`:
```
LoadTable: .L /star-sw/StarDb/Geometry/tpc/tpcPadConfig.y2019.C
In file included from ./.sl79_gcc485/include/tables/St_tpcPadConfig_Table.h:5:
/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-6.16.00-osnvudkiguzfhdpqgy2krbqybjbqvith/include/TTable.h:188:10: error: constructor for 'TTable::iterator' must explicitly initialize the member 'fCurrentRow' which does not have a default constructor
iterator(): fRowSize(0), fThisTable(0) {;}
^
/opt/software/linux-scientific7-x86_64/gcc-4.8.5/root-6.16.00-osnvudkiguzfhdpqgy2krbqybjbqvith/include/TTable.h:186:24: note: member is declared here
vec_iterator fCurrentRow;
```
C++ allows to leave class members uninitilized but it is also true that it does
not make much sense to have a default constructor for an iterator. It appears to
me that `TTable::iterator()` is not used anywhere in the code therefore, it
should be safe to get rid of it.
We need to build the internal libTable in order to use the modified code
plexoos
requested review from
genevb,
klendathu2k and
nigmatkulov
as code owners
plexoos
added
the
ROOT6
veprbl
approved these changes
Nov 23, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Our ROOT6 tests indicated a problem with the ROOT's TTable class when it is interpreted by the bfc.C macro. A few fixes seem to take care of that but now we need to build and use the local code from StRoot/Table instead of the external
libTableprovided by ROOT. This is achieved by building StRoot/Table conditionally only when external dependency on ROOT >= 6 is detected.