Remove "using namespace std;" from XRootD (necessary to support C++17)

[amadio]

This is necessary to avoid clashes of names from the global namespace with names from the std namespace. It was identified as a problem when trying to compile XRootD with C++17 standard and support for VOMS, which has a 'struct data' in the global namespace that clashes with std::data from C++17.

What I'm looking at for review is if using std:: everywhere is fine or if there's a preference to add using namespace std; in the .cc files. I think adding std:: explicitly is more reliable, but the patch is quite large. Once we merge this, #1929 should be fine to merge as well without problems.

[amadio]

Actually, I think I will split this into two changes. One patch to not need using namespace std; in our code, which can be merged into master without causing problems downstream, and another that just removes the using namespace std; lines from our headers, which should only be merged when we do the next major release. What do you think, @abh3?

[amadio]

Alright, the change is done. The first commit will be pushed to master, while the second has to wait for the major release.

[xrootd-dev]

I agree, that sounds good to me. Let's hope any new code doesn't sneak in that implicitly uses the std namespace.

…

On Thu, 23 Mar 2023, Guilherme Amadio wrote: Actually, I think I will split this into two changes. One patch to not need `using namespace std;` in our code, which can be merged into master without causing problems downstream, and another that just removes the `using namespace std;` lines from our headers, which should only be merged when we do the next major release. What do you think, @abh3? -- Reply to this email directly or view it on GitHub: #1933 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1

[amadio]

Ok, I've pushed the commit that changes the code not to rely on using namespace std; to master, so now we only need to add later the change that actually removes the lines with using namespace std; from our headers, which is what remains in this pull request and is actually the part that may break downstream code. This will only go in for the next major version.

[abh3]

OK, all I see is using std removals. I also see that implicit use of std was already corrected in a previous pull request. So, it looks OK. I was wondering why did we eschew using declaration notation to fix this?

[amadio]

OK, all I see is using std removals. I also see that implicit use of std was already corrected in a previous pull request. So, it looks OK. I was wondering why did we eschew using declaration notation to fix this?

This is the same pull request, but I separated the parts fixing implicit usage of std and pushed it, so all that's left here is the removal of using namespace std; from the code.

As for using declarations, in one of our meetings when we discussed this, we decided to keep using std:: in code rather than declarations for the sake of consistency. Since we cannot use declarations in our headers, rather than have a separate policy for headers and sources, we decided to go with using std:: everywhere.

[abh3]

Yes, I do remember we decided on that. I was just having second thoughts given what other projects do. For instance, in LSST common std symbols are declared in the cc file in which they are used (e.g. std::vector, std::string, etc) to shorten the code. The idea here is that these names have now become effectively baked into the compiler. So, that was all I was going after to see what you thought about it.

BTW if you are waiting for Michal to do a review you may never stop waiting. I think the rest of the month he's using up his vacation. So, you may want to remove him as a reviewer and merge this.

[amadio]

This has to wait for 6.0 to be merged, so I will close for now and keep the branch on my fork to avoid premature merging by accident. I will open a new PR when the right time arrives.