------- Comment #22 from d dot frey at gmx dot de 2009-03-14 08:52 ------- (In reply to comment #21) > Now I think I know the conservative way we want to go for the branch: just > change shared_ptr<>::operator* to always use something with the same semantics > of std::tr1::add_reference. For mainline, we'll see if there is still > something > to tweak, also in relation to 39310...
Sounds good to me. I was trying to figure out why it seems so hard to understand what is wrong with the current code. Here's what I'm currently thinking: a) __is_abstract (and maybe others) accept incomplete types. They should IMHO reject them instead of reporting wrong results. Combined with template instantiations, the result can be really strange. I'll add an attachment which you can play with to experience some of the problems first hand :) b) some type_traits should work on incomplete types. is_const, remove_const, add_lvalue_reference are good examples. But this also means that they may not use type_traits that require complete types within their implementation. I think this is what happened initially: shared_ptr does not need T to be complete, it uses add_lvalue_reference (should be OK), which in turn uses is_function (OK?) which uses is_abstract - which is NOT OK. I've checked N2800, in 20.5.4.3/3 it clearly talks about these points. The table in N2800 is clear on is_const<T> to not require a complete type T (and not to instantiate T), and it is clear on is_abstract<T> to require a complete type (and to instantiate it). I haven't found anything similar for add_lvalue_reference<T>, as 20.5.6 (Transform traits) seems to ignore the topic. What do you think? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39405
