Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Code generated by TFile::MakeProject should not rely on std namespace import #6411

Open
jblomer opened this issue Sep 22, 2020 · 4 comments
Open

Comments

@jblomer
Copy link
Contributor

jblomer commented Sep 22, 2020

Explain what you would like to see improved

As discussed in the ROOT forum: the code generated by TFile::MakeProject currently contains the following lines at the beginning

namespace std {} using namespace std;

which is necessary because the header files to not qualify std names (e.g., vector instead of std::vector).

@Wile.E.Coyote provided the following comment in the forum:

Actually, it seems to me that the origin of the problem is that the “std::” was removed at the TTree creation time (i.e. if you try “tree->Print();”, you will see that it is not there). It seems to me that this is a long-standing problem which should be fixed (i.e. “std::” should be preserved).

Optional: share how it could be improved

It would be nicer if header files did qualify names from the std namespace so that they can be easier included in other projects.

To Reproduce

Use TFile::MakeProject on a ROOT file with a non-trivial tree.

Setup

  1. Master
  2. Arch Linux
  3. Built from sources
@pcanal
Copy link
Member

pcanal commented Sep 22, 2020

Changing the onfile normalized name might not be forward compatible (old version of ROOT not being able to read new files).

@dpiparo
Copy link
Member

dpiparo commented Feb 2, 2024

Can this be closed as won't fix given the comment of @pcanal ?

@dpiparo
Copy link
Member

dpiparo commented Apr 24, 2024

I am closing the issue. Please feel free to reopen if you have an answer to the question asked above.

@dpiparo dpiparo closed this as completed May 17, 2024
@dpiparo dpiparo reopened this May 17, 2024
@ferdymercury
Copy link
Contributor

Was this issue reopened on purpose?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants