<div dir="ltr"><div class="gmail_default" style="font-size:large">Ah, I guess from the name that "termios.h" is a Mac thing? We don't explicitly request that header anywhere... I wonder what in your system libraries is pulling it in.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Andy</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 May 2018 at 13:44, Stefan Richter <span dir="ltr"><<a href="mailto:stefan.richter@cern.ch" target="_blank">stefan.richter@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space">Hi Andy,<div>the macro is defined in /usr/include/sys/termios.h. You can spot this in the compiler error message at the end of my original message. I've checked the file, it defines many B?, where ? is an integer.</div><div><br></div><div>My current solution: I add #undef B0 to the beginning of Rivet-2.5.4/include/Rivet/<wbr>Tools/ParticleName.hh. I'm happy to hear more robust/elegant solutions, but if this runs, I can live with it.</div><div><br></div><div><span class=""><blockquote type="cite">This isn't just a modularisation thing -- we already namespace these PID codes. It's more generally about inability to restrict the scope of #define and other dumb preprocessor mechanisms...<br></blockquote></span>Yes, the fact that the scope of preprocessor actions cannot be (robustly) restricted on the user code side is what I was lamenting. In other words, the fact that the compartmentalisation provided by namespaces can be broken.</div><div><br></div><div>Best regards,</div><div>Stefan</div><div><div class="h5"><div><br></div><div><div><br><blockquote type="cite"><div>On 2 May 2018, at 14:37, Andy Buckley <<a href="mailto:a.g.buckley@gmail.com" target="_blank">a.g.buckley@gmail.com</a>> wrote:</div><br class="m_8545083717035269918Apple-interchange-newline"><div><div dir="ltr"><div class="gmail_default" style="font-size:large">Hi Stefan,</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Do you know what header defines this B0 macro? It's not a problem I've ever seen. Compiler-level macros should have names prefixed by double-underscores to avoid this problem, I think, so it must be coming from a "user space" header... but which one?</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">This isn't just a modularisation thing -- we already namespace these PID codes. It's more generally about inability to restrict the scope of #define and other dumb preprocessor mechanisms...</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Andy</div><div class="gmail_default" style="font-size:large"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 2 May 2018 at 12:54, Stefan Richter <span dir="ltr"><<a href="mailto:stefan.richter@cern.ch" target="_blank">stefan.richter@cern.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Rivet developers,<br> I'm experiencing a very annoying compile-time clash because the variable B0 is #defined (to 0) in a header that gets #included in Rivet… where it clashes with Rivet's PDGID definition of the neutral B meson. See the compiler printouts below.<br> <br> Do you have an elegant solution for this? Or should I add an #undef line to the Rivet source?<br> <br> Thank you!<br> Stefan<br> <br> PS: I wish C++ had a module system like Python to prevent this from happening.<br> <br> clang++ -std=c++11 -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -pipe -Os -I/Users/stefanrichter/Softwar<wbr>e/local/src/Rivet-2.5.4/<wbr>include -I/Users/stefanrichter/Softwar<wbr>e/local/src/Rivet-2.5.4/<wbr>include -I/opt/local/Library/Framework<wbr>s/Python.framework/Versions/3.<wbr>6/include/python3.6m -c rivet/core.cpp -o build/temp.macosx-10.13-x86_64<wbr>-3.6/rivet/core.o -I/Users/stefanrichter/Softwar<wbr>e/local/include -O2 -Wno-sign-compare -I/Users/stefanrichter/Softwar<wbr>e/local/include -I/Users/stefanrichter/Softwar<wbr>e/local/include -I/Users/stefanrichter/Softwar<wbr>e/local/include -I/opt/local/include<br> In file included from rivet/core.cpp:456:<br> In file included from /Users/stefanrichter/Software/<wbr>local/src/Rivet-2.5.4/include/<wbr>Rivet/AnalysisHandler.hh:5:<br> In file included from /Users/stefanrichter/Software/<wbr>local/src/Rivet-2.5.4/include/<wbr>Rivet/Config/RivetCommon.hh:20<wbr>:<br> /Users/stefanrichter/Software/<wbr>local/src/Rivet-2.5.4/include/<wbr>Rivet/Tools/ParticleName.hh:12<wbr>2:24: error: expected unqualified-id<br> static const PdgId B0 = 511;<br> ^<br> /usr/include/sys/termios.h:291<wbr>:12: note: expanded from macro 'B0'<br> #define B0 0<br> ^<br> 1 error generated.<br> error: command 'clang++' failed with exit status 1<br> <br> <br>______________________________<wbr>_________________<br> Rivet mailing list<br> <a href="mailto:Rivet@projects.hepforge.org" target="_blank">Rivet@projects.hepforge.org</a><br> <a href="https://www.hepforge.org/lists/listinfo/rivet" rel="noreferrer" target="_blank">https://www.hepforge.org/lists<wbr>/listinfo/rivet</a><br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_8545083717035269918gmail_signature" data-smartmail="gmail_signature">Dr Andy Buckley, Lecturer / Royal Society University Research Fellow<br>Particle Physics Expt Group, University of Glasgow<br></div> </div> </div></blockquote></div><br></div></div></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Dr Andy Buckley, Lecturer / Royal Society University Research Fellow<br>Particle Physics Expt Group, University of Glasgow<br></div> </div>