Skip to content

Conversation

@amadio
Copy link
Member

@amadio amadio commented Aug 30, 2017

Test PR, do not merge please.

@phsft-bot
Copy link

Starting build on centos7/gcc49, mac1012/native, slc6/gcc49, slc6/gcc62, ubuntu14/native with flags -Dvc=OFF -Dimt=ON -Dccache=ON
How to customize builds

@pcanal pcanal changed the title Simplify implementation of TClass::FindClassOrBaseMethodWithId() [WIP] Simplify implementation of TClass::FindClassOrBaseMethodWithId() Aug 30, 2017
@amadio
Copy link
Member Author

amadio commented Aug 30, 2017

@pcanal This isn't really work in progress, I just wanted to test that the build would pass. Actually, if you think this commit is ok, we can merge this now, but please let me merge it myself locally, otherwise the GPG signature on the commit is lost.

@amadio amadio changed the title [WIP] Simplify implementation of TClass::FindClassOrBaseMethodWithId() Simplify implementation of TClass::FindClassOrBaseMethodWithId() Aug 30, 2017
@pcanal
Copy link
Member

pcanal commented Aug 30, 2017

but please let me merge it myself locally, otherwise the GPG signature on the commit is lost.

What do you mean? How is that different from other PR?

if you think this commit is ok

I am 'slightly' surprised it works in C++11 ...

@amadio
Copy link
Member Author

amadio commented Aug 30, 2017

The GitHub interface strips GPG signatures from the commits. I usually merge on my laptop and push, and that way it's as if I pressed merge, but I can keep the GPG signatures.

As for the commit, if you look at the date, you'll see it's from a while ago, when I was working on I/O optimizations. I was just trying to improve readability and test range for with ROOT containers. Yes, it works :-) So, I guess we should be trying to use this more than the usual while loop. What do you think?

@pcanal
Copy link
Member

pcanal commented Aug 30, 2017

but I can keep the GPG signatures.

What is the advantage/gain/importance of doing so?

@pcanal
Copy link
Member

pcanal commented Aug 30, 2017

Yes, it works :-)

Indeed, I was confusing with the C++17 features

if (init; condition) and switch (init; condition)

like

if (const auto [it, inserted] = map.insert( {"foo", bar} ); inserted)

TFunction *f = GetMethodList()->Get(declId);
if (f) return (TMethod*)f;
if (auto method = GetMethodList()->Get(declId))
return reinterpret_cast<TMethod *>(method);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

'Thanks' to the auto keyword the validity of the reinterpret_cast becomes harder to Check. (i.e. now one that to find out that GetMethodList returns a TListOfFunctions and then look up the return type of Get ... only then can one know that the cast is okay since TMethod inherits directly for the return type, TFunction).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it must be fine, since that's what the function returns. Using reinterpret_cast is better than just a C cast, as it will fail in more cases where the C cast would compile and give wrong results.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, it must be fine,

It is fine of course. My point is about code readability (i.e. the ability for the human reader to verify the code :) ).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I.e. in this case, because of the reinterpret_cast, I would use

if (TFunction *method = GetMethodList()->Get(declId))
      return reinterpret_cast<TMethod *>(method);

@amadio
Copy link
Member Author

amadio commented Aug 30, 2017

The advantage in keeping GPG signatures is that it tells people that the change came from a trusted source. We should all be doing this, but due to being complicated, I understand that others don't bother.

}
}
return 0;
for (auto item : *GetListOfBases())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One hesitation I have with this pattern is that the iterator cast is moved one level down. i.e.

while ((item = reinterpret_cast<TBaseClass *>(next()))) {
   if (auto base = item->GetClassPointer())

vs

for (auto item : *GetListOfBases())
   if (auto base = reinterpret_cast<TBaseClass *>(item)->GetClassPointer())

or more often.

for (auto item : *GetListOfBases()) {
   auto base = reinterpret_cast<TBaseClass *>(item);
   if (base->GetClassPointer())

I wonder if we can have something like

for (auto item : ContaineeIs<TBaseClass*>(GetListOfBases()))
   if (auto base = item->GetClassPointer())

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's not sidestep a 5 line commit into a lenghty discussion on code patterns. If you disagree that the code is more readable after the changes, just let me know and I'll close the PR.

@pcanal
Copy link
Member

pcanal commented Aug 30, 2017

Let's not sidestep a 5 line commit into a lenghty discussion on code patterns.

My points were triggered by your good point:

So, I guess we should be trying to use this more than the usual while loop.

where I think to be really recommended as the new pattern we should slightly improve on it.

Could you, as a subsequent PR, try to improve the collection in the direction I mentioned (assuming you agree it is 'even' better :)

Anyway

If you disagree that the code is more readable

I agree it is more readable except for the auto method which should go back to TFunction *method.

Thanks,
Philippe.

@amadio
Copy link
Member Author

amadio commented Aug 30, 2017

Ok, I will use TFunction instead of auto, then I can merge, then?

@pcanal
Copy link
Member

pcanal commented Aug 30, 2017

Ok, I will use TFunction instead of auto, then I can merge, then?

Yes. Thanks.

@amadio
Copy link
Member Author

amadio commented Aug 30, 2017

By improve the collection you mean changing all while loops to range fors?

@pcanal
Copy link
Member

pcanal commented Aug 30, 2017

By improve the collection you mean changing all while loops to range fors?

Not quite (as this might be a good thing for the code refactoring tool to do).

I mean to enable something like:

for (auto item : ContaineeIs<TBaseClass*>(GetListOfBases()))
   if (auto base = item->GetClassPointer())

@amadio
Copy link
Member Author

amadio commented Aug 30, 2017

Sure, I don't know how complicated that may be, but if it's doable, we can try in a later PR. Thanks.

@phsft-bot
Copy link

Starting build on centos7/gcc49, mac1012/native, slc6/gcc49, slc6/gcc62, ubuntu14/native with flags -Dvc=OFF -Dimt=ON -Dccache=ON
How to customize builds

return 0;
for (auto item : *GetListOfBases())
if (auto base = reinterpret_cast<TBaseClass *>(item)->GetClassPointer())
if (auto method = base->FindClassOrBaseMethodWithId(declId))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one more TFunction*. Sorry to be a pest :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, will do, no problem.

@phsft-bot
Copy link

Starting build on centos7/gcc49, mac1012/native, slc6/gcc49, slc6/gcc62, ubuntu14/native with flags -Dvc=OFF -Dimt=ON -Dccache=ON
How to customize builds

@amadio amadio merged commit b95526d into root-project:master Aug 30, 2017
@amadio amadio deleted the root-io branch August 30, 2017 15:38
@phsft-bot
Copy link

Build failed on slc6/gcc62.
See console output.

@phsft-bot
Copy link

@phsft-bot
Copy link

@phsft-bot
Copy link

@phsft-bot
Copy link

Build failed on slc6/gcc49.
See console output.

Errors:

  • ERROR: Timeout after 10 minutes
  • ERROR: Error fetching remote repo 'origin'
  • stderr: error: RPC failed; result=18, HTTP code = 200
  • ERROR: Error fetching remote repo 'origin'

Failing tests:

enirolf pushed a commit to enirolf/root that referenced this pull request Apr 23, 2025
"too" is too general and may also match the build path. I could not
find "too slow" being printed anywhere, so just check the output for
"too inaccurate".
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants