On Tue, May 14, 2013 at 2:02 PM, Aaron Ballman <span dir="ltr"><<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Tue, May 14, 2013 at 4:52 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> Yes, this looks like the direction I was suggesting, but I feel a little<br>
> uneasy about this -- it seems deeply weird for these attributes to not<br>
> affect the canonical type. To what extent do we need to support them (is<br>
> parse-but-ignore enough)? Is sizeof(int *__ptr32) 4 even on a 64-bit system,<br>
> and is sizeof(int *__ptr64) 8 even on a 32-bit system?<br>
<br>
</div>int * __ptr32 p32 = 0;<br>
int * __ptr64 p64 = 0;<br>
<br>
::printf( "%d, %d", sizeof( p32 ), sizeof( p64 ) );<br>
<br>
32-bit platform: 4, 8<br>
64-bit platform: 4, 8<br>
<br>
My plan was to get parse-but-ignore in place, and then begin to<br>
evaluate the codegen side of things.</blockquote><div><br></div><div>OK, we will (in the big blue eventually) need for these types to be canonically different, then. That would also mean that we would be able to overload on __ptr32/__ptr64-ness, but I don't think that's really a problem.</div>
<div><br></div><div>Do __sptr and __uptr get different manglings?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Also, do we actually want to have the functionality in<br>
> distributeMSTypeAttrFromDeclarator? Can these keywords go after the<br>
> declarator-id (eg int *p __sptr;)? Even if so, presumably you didn't mean to<br>
> allow "int *X::*p __ptr32 __sptr"?<br>
<br>
</div>That's a good point, they're only legal between the pointer and the<br>
identifier (if any) in a declaration.  So the distribute function is<br>
unneeded.<br>
<br>
Are there other areas I am forgetting to touch for this (aside from<br>
the obvious codegen and lower parts)?</blockquote><div><br></div><div>Since you're just representing this as type sugar with no semantic impact, I don't think there's anything else you need to change just yet. Once these attributes start having a semantic impact, there will be other places (implicit conversions, casts, initialization, overload resolution, possibly template argument deduction) that will need updates.</div>
<div><br></div><div>Another thought: does MSVC allow this kind of shenanigans:</div><div><br></div><div>template<typename T> void f(T __ptr32 *p);</div><div>template void f<int*>(int *__ptr32 *p);</div></div>