Re: [boost] [config] request for BOOST_NO_FWD_STD_DECLARATION

Subject: Re: [boost] [config] request for BOOST_NO_FWD_STD_DECLARATION
From: Howard Hinnant (howard.hinnant_at_[hidden])
Date: 2011-02-16 18:07:27

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_at_[hidden]>  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