<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Andy,<div class="">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 class=""><br class=""></div><div class="">My current solution: I add #undef B0 to the beginning of Rivet-2.5.4/include/Rivet/Tools/ParticleName.hh. I'm happy to hear more robust/elegant solutions, but if this runs, I can live with it.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">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 class=""></blockquote>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 class=""><br class=""></div><div class="">Best regards,</div><div class="">Stefan</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 2 May 2018, at 14:37, Andy Buckley <<a href="mailto:a.g.buckley@gmail.com" class="">a.g.buckley@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-size:large">Hi Stefan,</div><div class="gmail_default" style="font-size:large"><br class=""></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 class=""></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 class=""></div><div class="gmail_default" style="font-size:large">Andy</div><div class="gmail_default" style="font-size:large"><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 2 May 2018 at 12:54, Stefan Richter <span dir="ltr" class=""><<a href="mailto:stefan.richter@cern.ch" target="_blank" class="">stefan.richter@cern.ch</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Rivet developers,<br class=""> 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 class=""> <br class=""> Do you have an elegant solution for this? Or should I add an #undef line to the Rivet source?<br class=""> <br class=""> Thank you!<br class=""> Stefan<br class=""> <br class=""> PS: I wish C++ had a module system like Python to prevent this from happening.<br class=""> <br class=""> 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/<wbr class="">Software/local/src/Rivet-2.5.<wbr class="">4/include -I/Users/stefanrichter/<wbr class="">Software/local/src/Rivet-2.5.<wbr class="">4/include -I/opt/local/Library/<wbr class="">Frameworks/Python.framework/<wbr class="">Versions/3.6/include/python3.<wbr class="">6m -c rivet/core.cpp -o build/temp.macosx-10.13-x86_<wbr class="">64-3.6/rivet/core.o -I/Users/stefanrichter/<wbr class="">Software/local/include -O2 -Wno-sign-compare -I/Users/stefanrichter/<wbr class="">Software/local/include -I/Users/stefanrichter/<wbr class="">Software/local/include -I/Users/stefanrichter/<wbr class="">Software/local/include -I/opt/local/include<br class=""> In file included from rivet/core.cpp:456:<br class=""> In file included from /Users/stefanrichter/Software/<wbr class="">local/src/Rivet-2.5.4/include/<wbr class="">Rivet/AnalysisHandler.hh:5:<br class=""> In file included from /Users/stefanrichter/Software/<wbr class="">local/src/Rivet-2.5.4/include/<wbr class="">Rivet/Config/RivetCommon.hh:<wbr class="">20:<br class=""> /Users/stefanrichter/Software/<wbr class="">local/src/Rivet-2.5.4/include/<wbr class="">Rivet/Tools/ParticleName.hh:<wbr class="">122:24: error: expected unqualified-id<br class=""> static const PdgId B0 = 511;<br class=""> ^<br class=""> /usr/include/sys/termios.h:<wbr class="">291:12: note: expanded from macro 'B0'<br class=""> #define B0 0<br class=""> ^<br class=""> 1 error generated.<br class=""> error: command 'clang++' failed with exit status 1<br class=""> <br class=""> <br class="">______________________________<wbr class="">_________________<br class=""> Rivet mailing list<br class=""> <a href="mailto:Rivet@projects.hepforge.org" class="">Rivet@projects.hepforge.org</a><br class=""> <a href="https://www.hepforge.org/lists/listinfo/rivet" rel="noreferrer" target="_blank" class="">https://www.hepforge.org/<wbr class="">lists/listinfo/rivet</a><br class=""></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature" data-smartmail="gmail_signature">Dr Andy Buckley, Lecturer / Royal Society University Research Fellow<br class="">Particle Physics Expt Group, University of Glasgow<br class=""></div> </div> </div></blockquote></div><br class=""></div></body></html>