Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?

Subject: Re: [boost] [config] Request for BOOST_SYMBOL_IMPORT_VISIBLE ?
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-02-14 12:02:36

Alexander Arhipenko wrote:
>
> I agree with you that re-export requires a change to headers.
> I can't fully agree on *we have no way of knowing when
> re-export is required*.
> If you export concrete class it's for sure does not require re-export.
> If the library has an exception class that could leave
> library's boundary -> it should be re-exported.

Is there consensus of an unambiguous, categorical list of types that require visibility attributes and which of those must be marked with default visibility (to re-export them)?  So far, I think there's only limited documentation and a good deal of conjecture.

I don't think "re-export" is the right term since this only applies to types that are marked with "default" visibility when the compiler's default is set to "hidden," right?  That is, those compilers that use import/export needn't export something again to work, so this really hasn't anything to do with export.  Thus, "re-expose" would be a more accurate term.

> The ideal solution for me would be to have following default behavior:
>
> 1) regular symbols are exported as they are now (without re-export)
> 2) public exceptions are re-exported
>
> For this, boost.config should have additional macro:
> BOOST_SYMBOL_IMPORT_REEXPORT.

That name is much too verbose.  Assuming "re-export" is the accepted term, then "BOOST_SYMBOL_REEXPORT" will be sufficient.

> Consider example below on how "default" export/import could
> be implemented. (Assume library name is A).
>
> #if defined BOOST_A_BUILD_SHLIB
> # define BOOST_A_DECL                         BOOST_SYMBOL_EXPORT
> # define BOOST_A_DECL_VISIBLE        BOOST_A_DECL

This has no bearing on the resulting code, but I'd s/BOOST_A_DECL/BOOST_SYMBOL_EXPORT/ because that's what's really meant as the definition of BOOST_A_DECL_VISIBLE.

> #elif defined BOOST_A_USE_SHLIB
> # define BOOST_A_DECL                         BOOST_SYMBOL_IMPORT
> # define BOOST_A_DECL_VISIBLE        BOOST_SYMBOL_IMPORT_REEXPORT
> #endif
>
> namespace boost { namespace alib {
>
>    class BOOST_A_DECL myclass {/*...*/};
>    class BOOST_A_DECL_VISIBLE myerror {/*...*/};
>
> }}

Assuming the right types are so marked, that certainly looks easy enough.

> Consider more sophisticated example.
> A's library author could give an option to the users
> not to re-export any classes.
> If someone builds library B and links library A and
> defines BOOST_A_IMPORT_PRIVATE macro,
> no symbols will be re-exported from A library.
>
> #if defined BOOST_A_IMPORT_PRIVATE
> # define BOOST_A_IMPORT     BOOST_SYMBOL_IMPORT
> #else
> # define BOOST_A_IMPORT     BOOST_SYMBOL_IMPORT_REEXPORT
> #endif

Are there going to be enough symbols in any Boost library to make that important?  I suppose it gives some means to hide Boost as an implementation detail, but this may well be undue complication.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.