Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk