<br><br><div class="gmail_quote">Le 25 novembre 2011 04:16, Philip Ashmore <span dir="ltr"><<a href="mailto:contact@philipashmore.com">contact@philipashmore.com</a>></span> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi there.<br>
<br>
Is there a way to get clang to store/dump the include path to previous<br>
definitions/typedefs?<br>
<br>
Saying that A, defined in file B, line C was previously defined in file<br>
B, line C isn't helpful.<br>
<br>
I know, I know, "don't include the same header file twice" but I have<br>
good reasons to do so.<br>
<br>
Details:<br>
<br>
I have several projects that use header files to do the "C" equivalent<br>
of class template definitions.<br>
The "templates" are things like AVL trees, and the "classes" are<br>
instantiations of the template with #defines standing in for template<br>
arguments.<br>
<br>
This approach is currently the only way I can get multiple instances of<br>
the same template into a translation unit without name clashes - I wish<br>
there was a better way.<br>
<br>
Unfortunately this approach isn't without its problems.<br>
<br>
My next release will include the project files using "-I\${top_srcdir}"<br>
instead of "-isystem ${top_srcdir}" and this has uncovered problems now<br>
that the compiler knows the project include files are not system headers.<br>
<br>
The one I'm stumped by is typedef redefinitions caused by multiple<br>
inclusion from the same include file.<br>
<br>
I'm sure a solution to this problem would be of use to others too - I'm<br>
not the only one who uses tricks like this.<br>
<br>
Regards,<br>
Philip Ashmore<br></blockquote><div><br>Is there any special reason that you would use:<br><br>#include "mytrick.h"<br><br>Instead of a regular macro invitation with arguments:<br><br>MY_TRICK()<br><br>?<br><br>
Clang would deal with the latter very nicely, especially since Chandler worked out the macro expansion in diagnostics.<br><br>-- Matthieu <br></div></div><br>