On 15 March 2011 19:19, Benjamin Kosnik wrote: > >> Does exporting some of these symbols and vtables from the library mean >> we're less able to change them? I'm not confident all ofthe C++0x >> bits are entirely stable yet. > > Yes, it does. What are the new exports that concern you?
thread::_Impl_base was one I'd been prototyping some changes to. If we need to rework it in order for thread::id to be a trivially-copyable (and less-than-comparable) type then we might need additional virtuals in Impl_base, but as all I have are untested ideas for now it probably shouldn't hold up the changes. We could always preserve the old type and use a new one for any rework needed. > There are some things I purposely did not include. For instance, > <regex>. Some of <future> can be further optimized for the void > specializations, but I did not do that to give implementation > flexibility in the future. > >> I see you've given future_base::_Result_base a virtual destructor, is >> there a specific reason for that? > > Yes... > >> Destruction should always be via >> the virtual _M_destroy function and so 'delete' is called in the final >> overrider, where the static type and dynamic type are the same. The >> virtual destructor adds unnecessary overhead, though it's probably >> negligible. > > Yeah on negligible. I don't see the addition as a correctness issue, > right? The __future_base nested classes don't seem to be changing all > that much, but I will defer to you if you are uneasy about specific > changes. > > Doing this may allow the control of all vague symbols in <future> for > standard instantiations in the future. OK, I'm not objecting to the change as all I have is a non-specific sense of unease and the advantages outweigh my slight uneasiness :)
