<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><br></div><div>+#define _LIBCPP_TOSTRING2(x) #x</div><div>+#define _LIBCPP_TOSTRING(x) _LIBCPP_TOSTRING2(x)</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>+# 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><div class="gmail_extra">
<br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 8:49 PM, G M <span dir="ltr"><<a href="mailto:gmisocpp@gmail.com" target="_blank">gmisocpp@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div>Hello Everyone</div><div> </div><div>Attached is a patch to libcxx to remove the errors relating to the use of #warning when compiling using MS's compiler cl.exe</div><div> </div><div>It introduces a macro to __config _LIBCPP_WARNING for use with the MS compiler and updates all references of #warning to use it when compiling with the real MS compiler.</div>
<div> </div><div>The macro is compatible with clang++ and g++ and can be used there too if you understand and accept the slight incompatibilities, which I'll explain. From my investigations, if I am correct, the limitations of this macro and #warning and #pragma message are:</div>
<div> </div><div>* #warning doesn't work on any version of visual studio. In fact it means something different to MS and it's used extensively; so they will likely never standardize on the use case here as they can't IMHO.<br>
<br>* #pragma message DOES work for clang++/g++/cl, BUT not completely compatibly:</div><div> </div><div>The differences in #pragma message are:<br> <br>* For g++, it generates a note, which is logical to me on the basis that if you want a warning, you have #warning from gcc's perspective.<br>
</div><div>* For MSVC, it generates a note like gcc (or appears to) at the command line, but the message does show up in the warning lists of Visual Studio but as far as I can tell it's not really a true warning. The message doesn't include a file or line number on the command line (and that may be to too true in the IDE I forgot to check) but on the command line, it's too brief and is easy to miss if used in a raw way.</div>
<div> </div><div>* For clang++, #pragma message generates a warning not a message/note like g++/cl. This is a very practical implementation, but a little misleading given the name and isn't quite as compatible with gcc as one might expect. Given these aspects, it's arguable that clang++ should be changed to issue a note instead of warning to match gcc, but I'm not advocating that change.</div>
<div> </div><div>* clang++ is however quite verbose in it's formatting of #pragma message and #warning compared to g++. I think too verbose. It's so verbose when used as a macro in fact that I think it's undesirable. IMHO, I think in this formatting aspect, clang++ should be changed to match g++.</div>
<div> </div><div>It would be better IMHO if it was tuned to remove the macro info and show it only if there is an actual error or problem in the formulation and use in the macro. If not, I think the use of the macro should appear in indistinguishable in use as it is in g++. And only be expanded in full if there is a real error, or another option is applied to force it for debugging purposes or something. For my purpose, it's arguable that the verbosity makes it somewhat useless. clang++ is just a little too helpful here, love it as I do. That is part of the reason I don't use this macro for anything other than VS.</div>
<div> </div><div>I've reported this verbosity as a undesirable feature to Richard Smith to see if he agrees but I (and I'm sure he) would be interested in seeing other opinions on here on the subject. I hope that "someone" will "fix" it and make clang++ match g++ more here.</div>
<div> </div><div>I've tested the attached patch with clang, Visual Studio and mingw / g++.<br></div><div>Thanks for your thoughts.</div><div> </div><div> </div></div>
</blockquote></div><br></div>