Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov

Subject: Re: [boost] [TypeIndex] Peer review period for library acceptance begins, ending Thurs 21st Nov
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-15 16:58:33

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<MoreFoo &>(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/