Also, as you so succinctly wrote:
What would be Good would IMHO be
* An authoritative definition of what registers must be preserved
by function (two different sets are stated by Microsoft, natural
choice would be the smallest one, which I think is also the
latest, in order not to break code).
* An authoritative definition of what registers can be clobbered
by e.g. a trampoline function such as Liviu suggested (natural
choice would be none, then let non-conforming code, if any,
fight it out in market).
* An authoritative definition of how non-static member function's
this pointer is passed, and perhaps ditto for args total size
for variadic function.
* An authoritative definition of for which argument types the
stdcall convention requires a certain way of passing them /
returning them. This is the essential thing saying that if you
have routine with such restricted signature, you really know how
to call it at machine code level, irrespective of tool.
* And what it allows (tool-dependent) for other argument types.
and not the least, as I think you're saying above and as I've
lamented on (is that correct English?) several times in this thread,
* A *clear separation* of what's specific to Windows API stdcall
("general stdcall"), what's specific to MSVC "C", and what's
specific to MSVC "C++".
I agree. I think for that last, what we need is at least a rule to
identify function parameter types/return type that *will* follow the
documented "C" rules without any hidden parameters.
I think MS is gonna have one hell of a hard time implementing C++0x
rules for standard layout types (while your Blah struct isn't POD
under C++03 or C++0x, it is standard-layout in C++0x) wrt calling
conventions unless they totally give up on backward compatibility. But
name mangling and such have always been subject to change
between compiler versions. I suspect if we try a VC++ compiler in a
couple years, it will produce the same code as g++, no hidden
argument with an address for the return value.
Perhaps. <g>