On Feb 16, 2011, at 5:51 PM, Christopher Jefferson wrote:
On 16 Feb 2011, at 22:12, Ion Gaztañaga wrote:
El 16/02/2011 19:40, Daniel James escribió:
On 16 February 2011 18:34, Christopher Jefferson<chris@bubblescope.net> wrote:
So, the main current problem (interprocess)
You should ask on a new thread with '[interprocess]' in the title, or post a ticket. Ion probably won't be reading this thread.
I'm not against splitting up container_fwd.hpp if that's what people want.
I've received the ticket. I have no problem to use a std predeclaration file like boost/detail/container_fwd.hpp, but shouldn't those predeclarations contain default parameters?
No, with templates you only get to declare the default parameters once, so you must not put them on. if you do, including the real std header later doesn't compile.
Right.
I would need to predeclare allocator, less, and char_traits so that I can use them as default parameters in my own interprocess predeclarations.
And can't we predeclare libc++ types in the correct namespace, use inline namespaces and avoid any header inclusion?
While I don't speak for libc++, I believe their preference is to not do this, as then if they change the names of the inline namespaces later, it would break boost. Just include the headers instead.
Of course, this shouldn't be imposed on all compilers if it leads to an unacceptable slowdown. It does lead to a massive increase in a pre-processed interprocess_fwd.hpp. Unfortunately the set of things required by interprocess is from various different headers, it wouldn't want to pull in 'container_fwd.hpp'.
I'm not sure if there is demand for a full-blown set of forward declarations for all the standard library. My preference would be a BOOST_CAN_FORWARD_DECLARE_STD macro, and pulling in the real headers in interprocess_fwd.hpp when it isn't defined.
I have no objection to boost doing this. But yes, libc++ will break such practice every time the ABI changes, which should be more often than never, and less often than every once in a while. Furthermore, it is quite possible, even likely, that a single implementation will ship with more than one ABI at a time (different inlined namespaces - version 1, version 2, etc.). If you want to use it, libc++ has the following macros: _LIBCPP_BEGIN_NAMESPACE_STD _LIBCPP_END_NAMESPACE_STD which do the inline namespace dance. Be forewarned that some symbols are /not/ versioned. I.e. they really are in namespace std. Currently that is operator new/delete, the set handler functions, and the C++03 std-defined exception classes. This set of non-versioned symbols is also subject to change. There will be no backward compatibility concerns for clients forward declaring std::items. The best way to address this issue is to bring it to the LWG. Bring performance impact measurements. -Howard