<div dir="auto">I believe that would need a sip parser to work that out, at least in the case A was not created by me.<div dir="auto"><br></div><div dir="auto">Mind you i guess the Feature guard idea would fail in the same case.</div><div dir="auto"><br></div><div dir="auto">Is there perhaps a way to mark a mapped type as local to the defining module?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 9 Apr 2017 10:24 pm, "Phil Thompson" <<a href="mailto:phil@riverbankcomputing.com">phil@riverbankcomputing.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 9 Apr 2017, at 4:05 pm, Shaheed Haque <<a href="mailto:srhaque@theiet.org">srhaque@theiet.org</a>> wrote:<br>
><br>
> A recurring problem with my SIP generator efforts is the need to deal<br>
> with duplicate SIP code. So far, I've been able to use the SIP concept<br>
> of a "feature" to deal with various manifestations of this, but I have<br>
> now hit one that has me stumped:<br>
><br>
> - Module A has a mapped type MTA (e.g. QPair<init, int>)<br>
> - Module B imports A, but also needs a mapped type for QPair<int, int>.<br>
><br>
> when the generator runs for module B, it is not aware of MTA, so it<br>
> ends up emitting MTB for its QPair<init, int>. Of course, when I run<br>
> SIP on B, MTA and MTB collide.<br>
><br>
> Is there something already in SIP I could use to say "this duplicate<br>
> is fine"? If not, would it be possible to add support for the SIP<br>
> equivalent of a define guard, along the lines "#define<br>
> feature"/"#ifdef feature"?<br>
><br>
> I realise that by generating the SIP code, I'm in a minority of SIP<br>
> users, but such a feature would also significantly simplify certain<br>
> other scenarios that affect me too.<br>
<br>
Why not fix your generator so that B knows the mapped type is defined elswhere?<br>
<br>
Phil</blockquote></div></div>