Adding MakeIterator() method to TObject class?

Newbie
1

Hi,

I am wondering if there is a possibility to add the following method to TObject class:

virtual TIterator * TObject::MakeIterator	(Bool_t 	dir = kIterForward	)	const { MayNotUse(""); return 0; }

The thing is that, when I develop a library, defining

class TMyObject : public TObject {...}
class TMyCollection : public TMyObject { ...}

then I cannot call

TIter next(TMyCollection*);

because TMyCollection does not inherit from TCollection.
The way of defining

class TMyCollection : public TCollection { ...}

is not good because it makes difficult to treat TMyObject and TMyCollection consistently.

2

Hi @tspark ,

I wonder why, since TCollection inherits from TObject anyway.

In any case, I do not think modifying/increasing features of TObject is something we want to do at this point, unless in case it fixes outstanding bugs.

Cheers,
Vincenzo

3

Dear Vincenzo,
Thanks for your reply.
What I meant is that, while TMyObject contains features I added on top of TObject, but TCollection does not contain those added features. There can be a few possible workarounds, but expanding TObject will resolve the issue most neatly, I guess.

4

I am wondering if there is a possibility to add the following method to TObject class:

Just adding this method would not solve the problem, would it? We would also need to change TIter::TIter to accept a TObject rather than a TCollection and then this would make things less type-safe (now any non-collection would be able to compile fine being based to a TIter but would have to fail at run-time).

Even for new ROOT code, we have migrated away from using TIter anyway and have instrument TCollection (and its derived class) so that the normal range for loop work well with them:

for(auto obj : *my_tcollection) ...
...
for (auto bcl : TRangeDynCast<TClass>(*cl->GetListOfBases())) {

and those could be applied to your case without inheriting from TCollection

5

Dear pcanal,

For the 1st paragraph: Yes, you are right, and that’s why I put MayNotUse(), but it will still be less type-safe.

For the 2nd part: I am not familiar with auto, and never heard about TRangeDynCast. I am just finding that it works smoothly, thank you very much for your suggestion!

One more question. In the example given in the head file of TCollection, they check if the auto variable bcl is null inside of the for-loop.
My question is, when can it be null? (Or, is this checking really needed?)
In my naive guess, it will be always non-null …

6

If you are asking about the example with the TRangeDynCast, the iterator does the equivalent of a C++ dynamic_cast and thus the item can be a nullptr if the element is not “deriving from” and/or “of” the specified type.

7

Many thanks for your help!