On 15 Nov 2013 at 13:34, Steven Watanabe wrote:
problem because of so much preexisting usage. It's an established
idiom, and that's that: in my opinion TypeIndex has the right to use
established idioms if they are currently safe with all possible
present compiler technologies as implied by the present C++ standard.
I don't agree that this is an idiom. I know
that Boost.Move uses it, but I'm not aware of
any other Boost library that does. Boost.Move
is not nearly as problematic, because it only
uses this in the fallback for C++03. It will
eventually be phased out in C++11.
Let me clarify myself, as I've suddenly realised I was being unclear:
Let there be a DLL exporting function:
struct Foo { ... };
struct MoreFoo : Foo { ... };
MoreFoo &convert(Foo &in)
{
return static_cast(in); // upcast to more derived type
}
Let there be another DLL in which we do:
MoreFoo a;
auto b=convert(a); // legal
Foo c;
auto d=convert(c); // not legal
Where I was coming from was the case of the first DLL: there the
compiler cannot know if the inbound Foo & originally came from a
MoreFoo or not. It simply must proceed as if it did.
That's what I meant by a very common idiom - we write code like the
first DLL all the time where we cannot possibly know if we are doing
undefined behaviour, because that's on the caller, not us. The shared
library boundary makes avoiding this impossible.
If we implement C++ Modules, then it all gets much more interesting,
and that's what I was referring to about this idiom being a problem
for future C++ features.
Niall
--
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
