<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Sep 18, 2013 at 6:20 AM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir="ltr"><div><div>Seems fine. Howard can decide on the fine points of how to format this or macro-ify this.</div></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir="ltr"><div><div>+#define _LIBCPP_TOSTRING2(x) #x</div><div>+#define _LIBCPP_TOSTRING(x) _LIBCPP_TOSTRING2(x)</div>
<div></div></div></div></blockquote><div><div>I tried to use _LIBCPP_CONCAT but it didn't work with __LINE__, at least on VS.</div><div>I'd like to have a stringify macro that does work with __LINE__ for a possible future patch too.</div>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><div><div>+</div><div>+#ifndef _LIBCPP_MSVC</div>
<div>+# define _LIBCPP_DO_PRAGMA(x) _Pragma(#x)</div><div>+// Not supported by GCC 4.2.1. Issues a note with gcc and a warning with clang++.</div><div><br></div><div>Does libc++ support gcc 4.2.1?</div>
<div><br></div></div></div></blockquote><div>Not according to the docs page, here:</div><div><a href="http://llvm.org/docs/GettingStarted.html#broken-versions-of-gcc-and-other-tools" target="_blank">http://llvm.org/docs/GettingStarted.html#broken-versions-of-gcc-and-other-tools</a>.</div>
<div>The comment was to remind myself while I was researching. I think I should remove it.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir="ltr"><div><div></div><div>+# define _LIBCPP_WARNING(x) _LIBCPP_DO_PRAGMA(message(x))</div><div>+#else</div><div>+# define _LIBCPP_DO_PRAGMA(x) __pragma(#x)</div><div>+// Issue a note not a warning in the command line compiler diagnostic. Appears as a warning in VS.</div>
<div>+# define _LIBCPP_WARNING(x) __pragma(message(__FILE__ "(" _LIBCPP_TOSTRING(__LINE__) ") : warning note: " x))</div><div>+#endif</div></div><div><br></div><div><br></div><div>- #warning uncaught_exception not yet implemented</div>
<div>+# ifndef _LIBCPP_MSVC</div><div>+# warning uncaught_exception not yet implemented</div><div>+# else</div><div>+ _LIBCPP_WARNING("uncaught_exception not yet implemented")</div><div>+# endif</div>
<div><br></div><div>Presumably you don't wish to use _LIBCPP_WARNING because it will print macro backtraces with clang, and that is undesirable? I'd like to eliminate the #ifdef clutter if possible.</div></div></blockquote>
<div> </div><div>Correct. Yes I wasn't happy about the #ifdef clutter either. I asked Howard about this originally and his preference was (if I recall correctly) that he was open to a macro if it would warn everywhere, certainly, gcc and clang, but I couldn't achieve that goal. I was also concerned myself about other systems I can't test with, I felt they would more likely support #warning than some kind of fancy _Pramga, so I started feeling the safe ugly option might be better, and then when I saw the macro verbosity clang spewed, that sealed the choice to go #ifdef ugly. My notes explain that in detail in my prior message.</div>
<div> </div><div>If anyone can fix that verbosity and if people decide they are ok that we just note rather than warn, I'm happy to revert the #ifdef to use the macro. But that still leaves us open to systems that don't support _pragma message but do support #warning. I don't know that such systems exist that we support. This is a time for anyone to speak out.I'm assuming that club is none.</div>
<div> </div><div>I'm reading things currently like this: 1) my patch is ugly as necessary but otherwise good to go subject to removing the gcc 4.2 comment to avoid distraction. 2) If someone can solve the clang++ macro verbosity problem and people agree that a gcc note rather than a warning is acceptable to us, we can use the macro. But 3) If clang is also changed to be totally compatible with gcc and is changed to note too, then people have to agree a note is acceptable on clang too, but if that happens we can use the macro everywhere and remove the #ifdef ugliness completely.</div>
<div> </div><div>The only caveat then left would be if libcxx uses a #warning somewhere and <__config> isn't included implicitly or explicitly. I'm not aware of anywhere that happens and I assume it would be a bug, so hopefully that isn't an issue.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div><div><div class="gmail_extra">
<br></div></div></div></blockquote></div></div></div>